From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id A7C23C021B8 for ; Tue, 4 Mar 2025 21:13:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3E5166B0089; Tue, 4 Mar 2025 16:13:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 396046B008A; Tue, 4 Mar 2025 16:13:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 25D5E280001; Tue, 4 Mar 2025 16:13:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 03B8B6B0089 for ; Tue, 4 Mar 2025 16:13:54 -0500 (EST) Received: from smtpin30.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 9E41CC0641 for ; Tue, 4 Mar 2025 21:13:54 +0000 (UTC) X-FDA: 83185120788.30.12E9FD9 Received: from mail-ej1-f43.google.com (mail-ej1-f43.google.com [209.85.218.43]) by imf09.hostedemail.com (Postfix) with ESMTP id A05DB14000B for ; Tue, 4 Mar 2025 21:13:52 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=i+9r3HkH; spf=pass (imf09.hostedemail.com: domain of amir73il@gmail.com designates 209.85.218.43 as permitted sender) smtp.mailfrom=amir73il@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741122832; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=7J8YOwIEEVHyNCl0YcJAroXcURAnRLfse6R4+fdppn4=; b=rKYkpgOvppPH0DE63UsYwdzC5PfFd9zrVgcTEDBervA2ud9gFphXL9rZjtPRY2xsGfxJAi kjK/s55gBq0Ye4I3y0D0qnLWbmpvjNOq30xfRMFhtSS3ksXlVgDAIPbiczIcqW/hJzXUq7 fmFbJuQGAmyWBj4ZbKjO0qrP+IdSkhY= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=i+9r3HkH; spf=pass (imf09.hostedemail.com: domain of amir73il@gmail.com designates 209.85.218.43 as permitted sender) smtp.mailfrom=amir73il@gmail.com; dmarc=pass (policy=none) header.from=gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741122832; a=rsa-sha256; cv=none; b=5VGzoJfGTUiSZnOmHRdiOY6wXWJj44jYIYCkA/08X7jFsqdv7NtibhgtopiN0JVJ9qxNV2 v55IVF2kPjkjzmVvnOMpErNaZyPBaWYqT1SJQRF9c+li20XO8ClPvdK7HYOP7Qx+Qypq4c 5yp40sA5B0TTR+HZuUQ/14urCeSQUFc= Received: by mail-ej1-f43.google.com with SMTP id a640c23a62f3a-aaeec07b705so942120166b.2 for ; Tue, 04 Mar 2025 13:13:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741122831; x=1741727631; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=7J8YOwIEEVHyNCl0YcJAroXcURAnRLfse6R4+fdppn4=; b=i+9r3HkH6P244T0uMZaQBNDYwv8yIwxhOTDIJK4hkxXV8CnwXu/WJlGbCW5wvLb5sL HovpGG375PBvHIIrjeis4Fu1vkr5ucSaxR44Iu+Lu3GjiYyCiMDkqLtC1FkVtYlzsAKo o59G5W8mVySC/FfdExSFNfdE/GOjrOZwiN3xgdsBM97Wexny4QH5meQ/UmOAOYh/pBL8 O1i+n+OBMKtfUf4tpwwjDpLDdaXoYEOSHlbL5g7UC2eTig6eYB0jXoQIT0F49GLof6fQ msVwiyMCjifF8SbmYCw/gOfDsDt4GHjqPUSFaNaQtcsIvake6o/p7YfMzfbQiA6xuj4Z Rjig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741122831; x=1741727631; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=7J8YOwIEEVHyNCl0YcJAroXcURAnRLfse6R4+fdppn4=; b=MCJbqRgtQ60ceo53lMUR1HRpUJHWTZW0UegiDREXPvA29G4cE6d3nqPLdtApyoSrkY SR8kl5jjBO2QOfDsFIiKqH4HuNHvNL/erce5P+O67p0WGX2Ea30qVrKJBW7pwaIMTxqM yc0whAasYp9K5mTXwjcsfhwpNwQKHba+5jq73//6ejXN+IQKKg7mNDjGN+/31Dt6hjMY QZLyIZUfUY7hbT7SR4MAY29JbuFHmF+lP6/Y7nVSFonTAm4KlybnTO/jOxHTVr7fLSMt lc6B+jY4ts42zDsauyWVUc3B8M86z7Fr71yTybuz4DGB8XxB+A0s3OXgG1GbEKqigBd8 U1nw== X-Forwarded-Encrypted: i=1; AJvYcCUSG8F9S2EjVrgg8q037LnQK51wAV/wS8e6jvfdZEZzMCM9sb6rBJjNUXi8VQQlyK7N6cTXGzijcQ==@kvack.org X-Gm-Message-State: AOJu0Yyou9B1eq/mbUBfnwo7Y8sopgNCqQ2hr84eQPwovXMuNBjkyeEY p3cnDAKo+UbVzWhMaPJt4rkKWkxBXlgjzH/jN+vHBe7U3BaHeCGmhrxzefuf8S+SbZziE3Jh0wj NszxeUTZBpdKTHxGUbYjCsRPDMrI= X-Gm-Gg: ASbGncvZCf3/iwi4tz2wRImuGQpdmgy/XaP6UEAGh6PQuFdIOtXaAXG9RH+zKscQgls PB9Vfky348ilQ/3oQzWeAvVk9SBghvp+vTVBvZ3Rn9BJmA51LHPa9e5XVnPe4flj5KsnpcZn44K 7pMEK9EegWLEzZCWtqR+BIr3628w== X-Google-Smtp-Source: AGHT+IFZrWlJPjDY/K1dKn6KwlpO6FY0o5jmsajcaXfdxae8w/3rlNFD6nvU8jAFvHJ57tKEXe9DLGo3vFHWtTW1S+E= X-Received: by 2002:a17:907:7f8a:b0:ac1:ec42:6cb6 with SMTP id a640c23a62f3a-ac20db006a5mr74629566b.52.1741122830557; Tue, 04 Mar 2025 13:13:50 -0800 (PST) MIME-Version: 1.0 References: <67a487f7.050a0220.19061f.05fc.GAE@google.com> <67c4881e.050a0220.1dee4d.0054.GAE@google.com> <7ehxrhbvehlrjwvrduoxsao5k3x4aw275patsb3krkwuq573yv@o2hskrfawbnc> <20250304161509.GA4047943@perftesting> <20250304203657.GA4063187@perftesting> In-Reply-To: <20250304203657.GA4063187@perftesting> From: Amir Goldstein Date: Tue, 4 Mar 2025 22:13:39 +0100 X-Gm-Features: AQ5f1JqNtzknjQuSpiU1bx2jheCURHcVXVhGUHYQJGqWgiCdDvdg1aIGdH7j2m0 Message-ID: Subject: Re: [syzbot] [xfs?] WARNING in fsnotify_file_area_perm To: Josef Bacik Cc: Jan Kara , syzbot , akpm@linux-foundation.org, axboe@kernel.dk, brauner@kernel.org, cem@kernel.org, chandan.babu@oracle.com, djwong@kernel.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-xfs@vger.kernel.org, syzkaller-bugs@googlegroups.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Stat-Signature: u7de8p7n6kb66cb759mw7fqpaxuh63yf X-Rspamd-Server: rspam11 X-Rspamd-Queue-Id: A05DB14000B X-Rspam-User: X-HE-Tag: 1741122832-74865 X-HE-Meta: U2FsdGVkX18vauN2liZJyx2lEc0EbuBd/ZMiLutLOm8tksGxEQ7TXcpUakIdqXu0CS5EXZULXyVeobY1Mshd1SW64z2S0DD32aQj8e9nH/sQ0QNRI9cUjOi+wMfDDpu4LBEhqjZw4C3c4z7IgZy/nXDD6/0LtVCiRWF5b5YBfVMFPxRI4EQWeDZmowOK6G6nF5iOiKSRHveqDfitdpf/uCE6qoseia1NsZelAM/TdzRWVSmOLUtYS/TWeA/aLDA34qIKHUc1bXRHFYqNFqDHqk3Lye9QPcHIiR9UiXrAbIhzsEgEXlW/vA33KehjzPXzNqCrQzq2BXKMyExLYYI8BuQAio5ysQn4LADk9lg0iB/UXIlyUqfxDFcXRIwIVZfHLuWD6/enssffWWLir/x3JHfpZSayojGZv0e005dleyJPHkXkNXq3aA68HQ+HhJINEkDgnR2DYIJBO5j0YeIG3hm7G6hhdg6+iaIz776+u6X49WF+O1YnXtl49KiIoYn8GiQ8+HjoskLGkg/lYpWLp8Ux7vC7iDieR3DBpirjMyhGkilVKThM2TUXb0dPCubgIuYqqO93oQfohYS2zgJL2Yydv3p3Te+b+uGLUMoyicrwEhJMBLkOUR879UFs+Fp77Yieovs2sRg+FZwFm3oZnth/GlOSABSFbU4+QzGhebiftvcSgAn3rANqRd9fiBXqBTd9/GGM7px8bz6jLOkxipF1XVEIxMpZRWHNI+e46Yqt3Wqujaemv4WYfaZsDNkdqJQMCafA0Y1kccZFJYznUbyxC/Xz89cw6aByxT8ibo+uzWc4ZAZN0OaUUNK6JgnBLDNcHyY+vx/e3z65WVZii8K60uNKedyys2udcD7VnkZgkZ+6G7rHllPKvU86m05DNrkE0jYIu7cHhzoOvAO4aw6DigAH0a/27h5LPdqXlM4on2+YkCVo7rie4FQS8P7kAUPHPx5tV08Br1F+tl2 +WrIgGk4 O9yGuSipsvb8GHoIkRRv8IyqxaKDCSS9snkfFh/jTNLmoQ6QclugGVE1+4Nd5NHgRmacvxck93VzAjd/DDtAERw/49vfwqjzGT2WCQIdCN37ZFlHdM8zaJBjB9twYOaOXfQsOLLny5Rj3WvfkdJyq/rFDaVZGtz+4Y+K5jDauwzqBmiI/w4asAh5jzOXt+QaduQxMP2SWQFb97sUG8J+f5dpJtZPvsseAPbUMI2PE82nnez55jGoVxzmZmB8cRIyD7a1mB7ZQ8DqvgEtRm/IOrSelmhAm+uUZQJDd7lxNFbWs7Ys8MnkhGb7An7xUzVFV/jSjT/DkxWLx/4NPD0Xo5s8qELvr2lpEvikEAWbnPKNJOeAN63NdZDq9zRb0AoQP5JiwmvOTLBVB5Imjcwild0kmRrZc9zAodtP4lNj/9b6KD5pj9WOidaYRQGPWpEKgHnyhWBR4dDDWG/BKv8rsfcBd9ZjTIQrrdCq2zSLE8JmDZ1lsNGopMrGZWLBdJHKQVoUWPh23U0PRdA12Y1l+Y+POatFG6+o7w+XTRI5OcOA2foJxLssx5rk0l4YecX4DBWFb X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On Tue, Mar 4, 2025 at 9:37=E2=80=AFPM Josef Bacik w= rote: > > On Tue, Mar 04, 2025 at 09:27:20PM +0100, Amir Goldstein wrote: > > On Tue, Mar 4, 2025 at 5:15=E2=80=AFPM Josef Bacik wrote: > > > > > > On Tue, Mar 04, 2025 at 04:09:16PM +0100, Amir Goldstein wrote: > > > > On Tue, Mar 4, 2025 at 12:06=E2=80=AFPM Jan Kara wro= te: > > > > > > > > > > Josef, Amir, > > > > > > > > > > this is indeed an interesting case: > > > > > > > > > > On Sun 02-03-25 08:32:30, syzbot wrote: > > > > > > syzbot has found a reproducer for the following issue on: > > > > > ... > > > > > > ------------[ cut here ]------------ > > > > > > WARNING: CPU: 1 PID: 6440 at ./include/linux/fsnotify.h:145 fsn= otify_file_area_perm+0x20c/0x25c include/linux/fsnotify.h:145 > > > > > > Modules linked in: > > > > > > CPU: 1 UID: 0 PID: 6440 Comm: syz-executor370 Not tainted 6.14.= 0-rc4-syzkaller-ge056da87c780 #0 > > > > > > Hardware name: Google Google Compute Engine/Google Compute Engi= ne, BIOS Google 12/27/2024 > > > > > > pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=3D-= -) > > > > > > pc : fsnotify_file_area_perm+0x20c/0x25c include/linux/fsnotify= .h:145 > > > > > > lr : fsnotify_file_area_perm+0x20c/0x25c include/linux/fsnotify= .h:145 > > > > > > sp : ffff8000a42569d0 > > > > > > x29: ffff8000a42569d0 x28: ffff0000dcec1b48 x27: ffff0000d68a17= 08 > > > > > > x26: ffff0000d68a16c0 x25: dfff800000000000 x24: 00000000000080= 00 > > > > > > x23: 0000000000000001 x22: ffff8000a4256b00 x21: 00000000000010= 00 > > > > > > x20: 0000000000000010 x19: ffff0000d68a16c0 x18: ffff8000a42566= e0 > > > > > > x17: 000000000000e388 x16: ffff800080466c24 x15: 00000000000000= 01 > > > > > > x14: 1fffe0001b31513c x13: 0000000000000000 x12: 00000000000000= 00 > > > > > > x11: 0000000000000001 x10: 0000000000ff0100 x9 : 00000000000000= 00 > > > > > > x8 : ffff0000c6d98000 x7 : 0000000000000000 x6 : 00000000000000= 00 > > > > > > x5 : 0000000000000020 x4 : 0000000000000000 x3 : 00000000000010= 00 > > > > > > x2 : ffff8000a4256b00 x1 : 0000000000000001 x0 : 00000000000000= 00 > > > > > > Call trace: > > > > > > fsnotify_file_area_perm+0x20c/0x25c include/linux/fsnotify.h:1= 45 (P) > > > > > > filemap_fault+0x12b0/0x1518 mm/filemap.c:3509 > > > > > > xfs_filemap_fault+0xc4/0x194 fs/xfs/xfs_file.c:1543 > > > > > > __do_fault+0xf8/0x498 mm/memory.c:4988 > > > > > > do_read_fault mm/memory.c:5403 [inline] > > > > > > do_fault mm/memory.c:5537 [inline] > > > > > > do_pte_missing mm/memory.c:4058 [inline] > > > > > > handle_pte_fault+0x3504/0x57b0 mm/memory.c:5900 > > > > > > __handle_mm_fault mm/memory.c:6043 [inline] > > > > > > handle_mm_fault+0xfa8/0x188c mm/memory.c:6212 > > > > > > do_page_fault+0x570/0x10a8 arch/arm64/mm/fault.c:690 > > > > > > do_translation_fault+0xc4/0x114 arch/arm64/mm/fault.c:783 > > > > > > do_mem_abort+0x74/0x200 arch/arm64/mm/fault.c:919 > > > > > > el1_abort+0x3c/0x5c arch/arm64/kernel/entry-common.c:432 > > > > > > el1h_64_sync_handler+0x60/0xcc arch/arm64/kernel/entry-common.= c:510 > > > > > > el1h_64_sync+0x6c/0x70 arch/arm64/kernel/entry.S:595 > > > > > > __uaccess_mask_ptr arch/arm64/include/asm/uaccess.h:169 [inlin= e] (P) > > > > > > fault_in_readable+0x168/0x310 mm/gup.c:2234 (P) > > > > > > fault_in_iov_iter_readable+0x1dc/0x22c lib/iov_iter.c:94 > > > > > > iomap_write_iter fs/iomap/buffered-io.c:950 [inline] > > > > > > iomap_file_buffered_write+0x490/0xd54 fs/iomap/buffered-io.c:1= 039 > > > > > > xfs_file_buffered_write+0x2dc/0xac8 fs/xfs/xfs_file.c:792 > > > > > > xfs_file_write_iter+0x2c4/0x6ac fs/xfs/xfs_file.c:881 > > > > > > new_sync_write fs/read_write.c:586 [inline] > > > > > > vfs_write+0x704/0xa9c fs/read_write.c:679 > > > > > > > > > > The backtrace actually explains it all. We had a buffered write w= hose > > > > > buffer was mmapped file on a filesystem with an HSM mark. Now the= prefaulting > > > > > of the buffer happens already (quite deep) under the filesystem f= reeze > > > > > protection (obtained in vfs_write()) which breaks assumptions of = HSM code > > > > > and introduces potential deadlock of HSM handler in userspace wit= h filesystem > > > > > freezing. So we need to think how to deal with this case... > > > > > > > > Ouch. It's like the splice mess all over again. > > > > Except we do not really care to make this use case work with HSM > > > > in the sense that we do not care to have to fill in the mmaped file= content > > > > in this corner case - we just need to let HSM fail the access if co= ntent is > > > > not available. > > > > > > > > If you remember, in one of my very early version of pre-content eve= nts, > > > > the pre-content event (or maybe it was FAN_ACCESS_PERM itself) > > > > carried a flag (I think it was called FAN_PRE_VFS) to communicate t= o > > > > HSM service if it was safe to write to fs in the context of event h= andling. > > > > > > > > At the moment, I cannot think of any elegant way out of this use ca= se > > > > except annotating the event from fault_in_readable() as "unsafe-for= -write". > > > > This will relax the debugging code assertion and notify the HSM ser= vice > > > > (via an event flag) that it can ALLOW/DENY, but it cannot fill the = file. > > > > Maybe we can reuse the FAN_ACCESS_PERM event to communicate > > > > this case to HSM service. > > > > > > > > WDYT? > > > > > > I think that mmap was a mistake. > > > > What do you mean? > > Isn't the fault hook required for your large executables use case? > > I mean the mmap syscall was a mistake ;). > ah :) > > > > > > > > Is there a way to tell if we're currently in a path that is under fsf= reeze > > > protection? > > > > Not at the moment. > > At the moment, file_write_not_started() is not a reliable check > > (has false positives) without CONFIG_LOCKDEP. > > One very ugly solution is to require CONFIG_LOCKDEP for pre-content events. > > > Just denying this case would be a simpler short term solution while > > > we come up with a long term solution. I think your solution is fine, = but I'd be > > > just as happy with a simpler "this isn't allowed" solution. Thanks, > > > > Yeh, I don't mind that, but it's a bit of an overkill considering that > > file with no content may in fact be rare. > > Agreed, I'm fine with your solution. Well, my "solution" was quite hand-wavy - it did not really say how to propagate the fact that faults initiated from fault_in_readable(). Do you guys have any ideas for a simple solution? Thanks, Amir.