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 3290BC28B2F for ; Sun, 9 Mar 2025 15:03:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 61CCD280002; Sun, 9 Mar 2025 11:03:20 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5CE19280001; Sun, 9 Mar 2025 11:03:20 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 46D98280002; Sun, 9 Mar 2025 11:03:20 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 29281280001 for ; Sun, 9 Mar 2025 11:03:20 -0400 (EDT) Received: from smtpin12.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id C73D4140163 for ; Sun, 9 Mar 2025 15:03:20 +0000 (UTC) X-FDA: 83202330960.12.F51A0DC Received: from mail-ej1-f48.google.com (mail-ej1-f48.google.com [209.85.218.48]) by imf18.hostedemail.com (Postfix) with ESMTP id CB1341C0011 for ; Sun, 9 Mar 2025 15:03:18 +0000 (UTC) Authentication-Results: imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Z1HYJHqg; spf=pass (imf18.hostedemail.com: domain of amir73il@gmail.com designates 209.85.218.48 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=1741532598; 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=58BuOiwDzRUGRvcQUrzx2ytYjSYfIocMT0CLsdKSDUs=; b=BB2QNs+fnpQ2X8rVKQmVfnwXidqYWN73isq1kL5s8uRaWTya3Aeh4gH3QCF1WncF/5Oim1 9nd4VLX0y2soQYPKNCYWYaUksXHo6a015mrggzXzejUVTi7z1kjpi2cjAvmmlDUAW4gM2W COmFEje/YFjbhJZDkPchZLCtJa7v54k= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741532598; a=rsa-sha256; cv=none; b=jRvmhcLEE8gmUUDXiaT+jb1UxCsUeRm+3VgJIx6SCjtwfe+gmjFyZT/6fFRd2IOZJDmtth 9pPOYKdXbKzKthgRTc6fW/SlNAX0E242TSll9iRNhOwLHEDdRXF44BNUBk0bIffMU46X6F TyFzupEtV3RaK/ZT9q4M5BVVCkoQqIM= ARC-Authentication-Results: i=1; imf18.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=Z1HYJHqg; spf=pass (imf18.hostedemail.com: domain of amir73il@gmail.com designates 209.85.218.48 as permitted sender) smtp.mailfrom=amir73il@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-ej1-f48.google.com with SMTP id a640c23a62f3a-ac2963dc379so39775466b.2 for ; Sun, 09 Mar 2025 08:03:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1741532597; x=1742137397; 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=58BuOiwDzRUGRvcQUrzx2ytYjSYfIocMT0CLsdKSDUs=; b=Z1HYJHqg+msTmbZFfcJxYAfLM4LX8mANhxIJNzDzZE2u2lSHmIq13uCsr6yXAQnhSQ 3UXsCNb5wbMGGgistr3i6s/xnWFYLelgBRqlsMjVPlSskxaO0MmsR4xAUzocvxJFgje+ 7gsjwr3GpDweIjx2LEvT0BAIKTVN5/VPAke2wDLfM/Lunvgft0FM8djXytThWkf0I0HM j4hksJuJOICGgHIRR2W05Z+wiXlbFxR0lZg+Sd+y0ZopXKop1MkHaxp3zZsIBPSAKTf4 u6MbkzJ/pYnMsCr6MAdBfB8Y2kPr02M5R5LSOoQwNKBxyZ7Y2p+Qv9BVBzRg7I/1Vm37 0nyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741532597; x=1742137397; 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=58BuOiwDzRUGRvcQUrzx2ytYjSYfIocMT0CLsdKSDUs=; b=Yw2M6YqTtm/JoXUeH4pyho1XEFTRpCqxfYsIpLou8brLzIPjGg28qtffYOIYwaPy4m 0nrpOjqUixRymhS9XGQfk+z62Spa9L5xwqqaISft20g86gb1ROILgoCLADhH0PzSWBY+ WCLH+IzOxWBu7ao3qW0fK4Q/3WpQzPD2uOYc7i31IveEUxqoKDC+SjAdMLbRiRRa8MXW 0FFNvkdelqvWrKzsWXEqo62cSh02VbqqCFZuZSynz5Z5OAQXIhAEN324zoDrQJ4cagL4 G6hSKvH7GTZlylta0qn73nULOug5+y3YH9cQYymGHdOgRMPRKj/sfnkgwW0p5sCsycVi LMhg== X-Forwarded-Encrypted: i=1; AJvYcCXff1aN5GXQq2iO+1lnrw7NcJ5pM6jbdigX0HieptblG9vjKkNc3t66VEFzzKXj3J6IbMM8jNLlLA==@kvack.org X-Gm-Message-State: AOJu0YxuUpANNrRW9e3BfLiLz8nhwgqAQpNaFIbtmJ+pV+59gO6hUa4E 062R3ScEJ2DNCvEeNbzOl0lNy7uKypN/wGFfgmm0Csz08SQ5pjFQEynB44dnx5AZp48FWlRR9S9 20ZnFR2GeeomN2IDM1bbgUTkNmIU= X-Gm-Gg: ASbGncuGPxaNo7hKsVbyDv4/Ff6SvkhlSByPxUczRUK/EpwXZg4hv5yBTt+daTcXeEc su9TvD5pltoxkUiyiNoG6GVP1pbNE0/nZRQARKQARJ+nKfCx45kB8QV6KRnYTThna4LFL6xnidC POUXbunhrKCYxLAHlLTUmjf/+bVY6aCMY9hNKb X-Google-Smtp-Source: AGHT+IFb2qhYD4KxAUVmi6g2SZVlvZPtybJRL1STfVK1ZpiqkHozo0amrZs9S2vnzJEtlQa5w6C1nXB65Z0hsFWrgQQ= X-Received: by 2002:a05:6402:27cc:b0:5e6:44d8:eced with SMTP id 4fb4d7f45d1cf-5e644d8eebemr10665923a12.12.1741532596723; Sun, 09 Mar 2025 08:03:16 -0700 (PDT) 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> <20250307154614.GA59451@perftesting> In-Reply-To: From: Amir Goldstein Date: Sun, 9 Mar 2025 16:03:05 +0100 X-Gm-Features: AQ5f1JqU_hFa6mx0e2QH--uNiPNV68Z4RfuRNv2syz89NhWmdZ9BT6qBIbG0zWU 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-Rspamd-Server: rspam12 X-Rspam-User: X-Rspamd-Queue-Id: CB1341C0011 X-Stat-Signature: sidmkw9euapyrxnx6hmho8descdbf7zi X-HE-Tag: 1741532598-662221 X-HE-Meta: U2FsdGVkX1/t9miZo9Ri2brUsgz9PZnJzoeQPsVYVSi5ax5moAVvsVMNCEJRZ5CEcfFiwTcX8otYJzEPNhHhDIzmk/Y/Wx/1PUpVQiz4K7Cq4cbONUxzbeSHvfRgrHM3NVs4PBNi5ZHE0m8FhHB0XO187ELtNA16IHGwERh7sv+bOz9jrBVMPzIRD+XIe16RFD+WFbQPviGqyM59G1oNV+JPK4ymxPlxv3e7gULhR/CpUNueJLtGnggCczxU8BDdUN3zze7zdE5BiYmMf5DMGAGSDrrIoIv/zabE1s3qAkbAWu0NJijzWUmErBtwlrePdFUC/6od/d7IMYbrgmRAOQnMO02dgDEOJ/AaPYa09wMggN/jFDdg1B68CWrsHJtKXlihAaeI2NRfgp0hOLBMLv82E2gM9bMpkWRod3vlsgYk41VEnp/0xnWdVlcK6ynU1s+zzRjm2wl1lwqE+fpbOhsTTQjOtiQubhEjy+QtfpRZ+SWcvT2r/iZJsjB4LvhEz18g7taA1DgtZG8LSgQai21BgGZ3zbj6i+dJRKsVN/atWjMBrxxqgq0ixQgIS/mqc+gGf9uEAR+yNzn0vtUcstSGhoaKxJKbzUr8yP93LgL5k8DzbztymgUAOQ9ApOEU3s1i86jLTJhDtGdhPAcZlr0ePgrjTHzLaodDo5Y8TAHghuDoDvE+tbV+9aJsE1oZde0m0q8X9U/N9EohgvCXhgK5x++d08gyrJslHyqkFc62KLibC/5VPnqOc4l4Yptl4D0R1KYZMZSm3b0IDJZXUyrXmKWFkdTW2fClxewF4eXlVSyeOvi2IuBkW31T6MrmZCcViL0f8/o7T7gK20HuhCtY9ZM1mN787I+woZ+hAaJBIwEb1x5SdLIAnUeaBZKqu1D5FeOt6SfSsICTZonS7hprhC9k3Rcd2y2M/bMKfJ6sGpdDvwsoPx/m2jkXd17AOm0ZDjIrZCDH2+Pn7bK 79KiIWgw MxthCSZe6IEVmMTOhGvGd80HyxT6CD3kjUP1UioPhg2xIxBjmK48pC5e2fBucd/l5twR7BMbmmQaf2UwtWo3uYpzOhdwLjwcykXERifA3B3QD55r9YOxKAN3cj6S3SIs7NChz3JEVm6zL2IETU+YVI6GgwzVQYUsVxKc1S8j5EUBfVxyz9AeGU6c8noVZmYlw8ISZLAQtHUhOnxSrzEMQfkOCs8jWCe7ou8EvLSMNAsJbGVvqI+NA25Bbr49yRM/2xk19bmCK4lccY9yQjMT86doH1I0dJOoUgPvnPQzuU5Ge+/Dky93DNiRtxJ8g8H+c8bE6Yurl2KTaS6h2ds51agSu9p41yj6nacwfTdvbaokkGjUIvyQiPuNU5gCkYpv88cczlFxIEOLNAAbE4QBXlc/ktSHCHpq9Uc1prP7piEmCdO9nAqbO6H3tzgOOH4xDJa0eAGEMufElZjxmg9V+QHENpbCMh0u+L7S2aPli8fabdg8y7aZIgLdhGiWUEPawXVAjsTFKgytSQicyP9+doCpPIZpQI7vqsOSwCaXUbNdKPtxeuNtwqkw5EAtZKBJTGPq8skWXEkW3farl0oFJHeZMw7gMM7IkKgAwM0qo4kewG2Y= 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 Sun, Mar 9, 2025 at 1:09=E2=80=AFPM Amir Goldstein = wrote: > > On Fri, Mar 7, 2025 at 6:45=E2=80=AFPM Amir Goldstein wrote: > > > > On Fri, Mar 7, 2025 at 5:07=E2=80=AFPM Amir Goldstein wrote: > > > > > > On Fri, Mar 7, 2025 at 4:46=E2=80=AFPM Josef Bacik wrote: > > > > > > > > On Tue, Mar 04, 2025 at 10:13:39PM +0100, Amir Goldstein wrote: > > > > > On Tue, Mar 4, 2025 at 9:37=E2=80=AFPM Josef Bacik wrote: > > > > > > > > > > > > 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 wr= ote: > > > > > > > > > On Tue, Mar 4, 2025 at 12:06=E2=80=AFPM Jan Kara wrote: > > > > > > > > > > > > > > > > > > > > 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 fsnotify_file_area_perm+0x20c/0x25c include/linux/fsnotify.h:145 > > > > > > > > > > > Modules linked in: > > > > > > > > > > > CPU: 1 UID: 0 PID: 6440 Comm: syz-executor370 Not tai= nted 6.14.0-rc4-syzkaller-ge056da87c780 #0 > > > > > > > > > > > Hardware name: Google Google Compute Engine/Google Co= mpute Engine, BIOS Google 12/27/2024 > > > > > > > > > > > pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS= BTYPE=3D--) > > > > > > > > > > > pc : fsnotify_file_area_perm+0x20c/0x25c include/linu= x/fsnotify.h:145 > > > > > > > > > > > lr : fsnotify_file_area_perm+0x20c/0x25c include/linu= x/fsnotify.h:145 > > > > > > > > > > > sp : ffff8000a42569d0 > > > > > > > > > > > x29: ffff8000a42569d0 x28: ffff0000dcec1b48 x27: ffff= 0000d68a1708 > > > > > > > > > > > x26: ffff0000d68a16c0 x25: dfff800000000000 x24: 0000= 000000008000 > > > > > > > > > > > x23: 0000000000000001 x22: ffff8000a4256b00 x21: 0000= 000000001000 > > > > > > > > > > > x20: 0000000000000010 x19: ffff0000d68a16c0 x18: ffff= 8000a42566e0 > > > > > > > > > > > x17: 000000000000e388 x16: ffff800080466c24 x15: 0000= 000000000001 > > > > > > > > > > > x14: 1fffe0001b31513c x13: 0000000000000000 x12: 0000= 000000000000 > > > > > > > > > > > x11: 0000000000000001 x10: 0000000000ff0100 x9 : 0000= 000000000000 > > > > > > > > > > > x8 : ffff0000c6d98000 x7 : 0000000000000000 x6 : 0000= 000000000000 > > > > > > > > > > > x5 : 0000000000000020 x4 : 0000000000000000 x3 : 0000= 000000001000 > > > > > > > > > > > x2 : ffff8000a4256b00 x1 : 0000000000000001 x0 : 0000= 000000000000 > > > > > > > > > > > Call trace: > > > > > > > > > > > fsnotify_file_area_perm+0x20c/0x25c include/linux/fs= notify.h:145 (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/ent= ry-common.c:510 > > > > > > > > > > > el1h_64_sync+0x6c/0x70 arch/arm64/kernel/entry.S:595 > > > > > > > > > > > __uaccess_mask_ptr arch/arm64/include/asm/uaccess.h:= 169 [inline] (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/buffe= red-io.c:1039 > > > > > > > > > > > xfs_file_buffered_write+0x2dc/0xac8 fs/xfs/xfs_file.= c:792 > > > > > > > > > > > xfs_file_write_iter+0x2c4/0x6ac fs/xfs/xfs_file.c:88= 1 > > > > > > > > > > > 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 buffer= ed write whose > > > > > > > > > > buffer was mmapped file on a filesystem with an HSM mar= k. Now the prefaulting > > > > > > > > > > of the buffer happens already (quite deep) under the fi= lesystem freeze > > > > > > > > > > protection (obtained in vfs_write()) which breaks assum= ptions of HSM code > > > > > > > > > > and introduces potential deadlock of HSM handler in use= rspace with filesystem > > > > > > > > > > freezing. So we need to think how to deal with this cas= e... > > > > > > > > > > > > > > > > > > Ouch. It's like the splice mess all over again. > > > > > > > > > Except we do not really care to make this use case work w= ith HSM > > > > > > > > > in the sense that we do not care to have to fill in the m= maped file content > > > > > > > > > in this corner case - we just need to let HSM fail the ac= cess if content is > > > > > > > > > not available. > > > > > > > > > > > > > > > > > > If you remember, in one of my very early version of pre-c= ontent events, > > > > > > > > > the pre-content event (or maybe it was FAN_ACCESS_PERM it= self) > > > > > > > > > carried a flag (I think it was called FAN_PRE_VFS) to com= municate to > > > > > > > > > HSM service if it was safe to write to fs in the context = of event handling. > > > > > > > > > > > > > > > > > > At the moment, I cannot think of any elegant way out of t= his use case > > > > > > > > > except annotating the event from fault_in_readable() as "= unsafe-for-write". > > > > > > > > > This will relax the debugging code assertion and notify t= he HSM service > > > > > > > > > (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 communica= te > > > > > > > > > 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 fsfreeze > > > > > > > > protection? > > > > > > > > > > > > > > Not at the moment. > > > > > > > At the moment, file_write_not_started() is not a reliable che= ck > > > > > > > (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 soluti= on 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 conside= ring 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 h= ow to > > > > > propagate the fact that faults initiated from fault_in_readable()= . > > > > > Do you guys have any ideas for a simple solution? > > > > > > > > Sorry I've been elbow deep in helping getting our machine replaceme= nts working > > > > faster. > > > > > > > > I've been thnking about this, it's not like we can carry context fr= om the reason > > > > we are faulting in, at least not simply, so I think the best thing = to do is > > > > either > > > > > > > > 1) Emit a precontent event at mmap() time for the whole file, since= really all I > > > > care about is faulting at exec time, and then we can just skip the = precontent > > > > event if we're not exec. > > > > > > Sorry, not that familiar with exec code. Do you mean to issue pre-con= tent > > > for page fault only if memory is mapped executable or is there anothe= r way > > > of knowing that we are in exec context? > > > > > > If the former, then syzbot will catch up with us and write a buffer w= hich is > > > mapped readable and exec. > > > > > Oh, I was being silly. > You meant to call the hook from page fault only for FMODE_EXEC. > This makes sense to me. I will try to write it up. > Let'e see if that works: #syz test: https://github.com/amir73il/linux fsnotify-mmap So far only compile and sanity tested. Thanks, Amir.