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 B4EA4C02192 for ; Mon, 3 Feb 2025 21:41:45 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 072C16B0082; Mon, 3 Feb 2025 16:41:45 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 022096B0083; Mon, 3 Feb 2025 16:41:44 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E04DC6B0085; Mon, 3 Feb 2025 16:41:44 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id C398E6B0082 for ; Mon, 3 Feb 2025 16:41:44 -0500 (EST) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 5898A14050E for ; Mon, 3 Feb 2025 21:41:44 +0000 (UTC) X-FDA: 83079955728.18.A26AB49 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf22.hostedemail.com (Postfix) with ESMTP id E4ED4C0002 for ; Mon, 3 Feb 2025 21:41:41 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=N6dvVhdI; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf22.hostedemail.com: domain of alex.williamson@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=alex.williamson@redhat.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738618902; a=rsa-sha256; cv=none; b=7he66TJ0ZEjAUgQkMeZWANTZR+XSyvKX+B6Rz16MV7C5r4uDOsZisUG429SiaD9YeUGUIK 8fINYZDkfGIYbN2/60CyeAg2ldJlTQ+6cTP6bDaYYvx/B6jx933g0clZCSFZw9mbRxFB/D lIm33Waid6gTLeUSQAP0kRyu+xncwzQ= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=N6dvVhdI; dmarc=pass (policy=none) header.from=redhat.com; spf=pass (imf22.hostedemail.com: domain of alex.williamson@redhat.com designates 170.10.133.124 as permitted sender) smtp.mailfrom=alex.williamson@redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738618902; 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=DtfKAhRWMEDek6jE2SHDYdar7e2jFQm9JpO8U5U9nAg=; b=4vQ9WqW0kqjLrxJEK7RHuYaLf8vRMCJ+A4dE8ctMZjCnF67UGIXsS9ZGNbbolaezTWVAYW GjF/xFDewp6qV1XVT4Nzy3pTSfPIucm/6jdEhjEv219Nj8zFxBknApz4gRM7Dgw/qNUDTT rGdTr60I/2xuN7G0bcqqqO8bPUeoxSs= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1738618901; h=from:from: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; bh=DtfKAhRWMEDek6jE2SHDYdar7e2jFQm9JpO8U5U9nAg=; b=N6dvVhdIVpVdipwK/0b86mGHrYzoMc58bQhkx093lVZVa6Zk3AcsRkmjqZ1nGoA/SeSBxs YaC2sB2Fo8TwzrxtFzOxpEAqduaVpQQOGmPEP97K8AM6qeVELd9WkCr3WIPhrnV8Z7RIy2 mcMFlvjLWNpPZDBxfsBc4hcJ0FDxtHw= Received: from mail-io1-f70.google.com (mail-io1-f70.google.com [209.85.166.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-214-1PIXZE3-NC-u27TIb7q1JQ-1; Mon, 03 Feb 2025 16:41:40 -0500 X-MC-Unique: 1PIXZE3-NC-u27TIb7q1JQ-1 X-Mimecast-MFC-AGG-ID: 1PIXZE3-NC-u27TIb7q1JQ Received: by mail-io1-f70.google.com with SMTP id ca18e2360f4ac-844ebc11477so25922939f.3 for ; Mon, 03 Feb 2025 13:41:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738618899; x=1739223699; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=fedZlQnodJAwktFWZrs8j+jy0xji0943zmwbFDXd7UQ=; b=WzNWlvKrvlFKWOnpu1Ec3DDJvYZLEwuh/YT9vAhp4NW0i8f95FCJPyqAonYHZhf7jv XPRX6YYSC6iPpUKwktSnEIOLtB0XaiDQR7XfCTbhMjNbM2dX01y5yCUtT3w+fBvKEK0+ 9f+4bBYm2Efsn3K3I6anmG6ikLv4GVYOwz3xfT2l0O1d9R53gE1NQbZzqWFN3m6KXPx/ kxiiTfo3/hxeudwLfvobjdZoLfo8S6kKjukdnVY1+jFmsC8xp9S9Tac9pKe/8iqhFUYK iks8ZuoaVDxyy11eEGO+ITwwZKyyxITObqNGo6ue54LvQgetseU66fYhU+RB+PhNyVNi S5Hg== X-Forwarded-Encrypted: i=1; AJvYcCXQ5Nlsqb1Xk4c0yMBknzhq5VgXk5EeyN9+UVUZ5x6UP1qY9nEucadn4peBx4vHsmyQx1utSP5JUw==@kvack.org X-Gm-Message-State: AOJu0Yzm4Ufd/YF57989UjEMB+dWhkvqIZrWboBmIci8BawjsbSALogW QR+yrLTbVjsOC+vLCnstTchHncezb8RQ1kWFr/CM4QaGG0WaZZA4CE71gJ1Yj0ncNWducrPI0IX gHqOGItk/FbH0V+QaPdEw0jzuomd6s4HjZnMwpb8zTFKxMdKA X-Gm-Gg: ASbGncvFsKDQWvCsXkyobu/EWJmIrbO9VxkHdUWYKVQ3B4dJ4/v+YlmvZ0CzUM1iOrC 56CjgX44NJjYFbT90hts9Bz8N6aJU+D75ZMMjyhceO0tg5GpeKVIdwkyOKtFkXdvANPVxTz0ZmY xldGAdFpEUk9Q/la6zJcMjaA3nf+RweNFYZIh4PoGe7nwVCExu6E5MB5MqdKOvj4t7/itqtdFwU rZXEpGD4+Y6fG13ll8UGdnxCtowwrzcLMrWq3s4su59L0PPHovr6F1rn70W8xrTFVnNFMvmRr96 rcHr7JKP X-Received: by 2002:a05:6602:6082:b0:84a:51e2:9f79 with SMTP id ca18e2360f4ac-854dd94f875mr40833439f.2.1738618899425; Mon, 03 Feb 2025 13:41:39 -0800 (PST) X-Google-Smtp-Source: AGHT+IHYIf7YEdjPvXGZacVgVVZyr+JMryxDDsVGKfxamFm+EdtMLtHIq0nEP3iBHBmyVlkBf0g9sw== X-Received: by 2002:a05:6602:6082:b0:84a:51e2:9f79 with SMTP id ca18e2360f4ac-854dd94f875mr40831539f.2.1738618898981; Mon, 03 Feb 2025 13:41:38 -0800 (PST) Received: from redhat.com ([38.15.36.11]) by smtp.gmail.com with ESMTPSA id 8926c6da1cb9f-4ec7469ef2dsm2425558173.97.2025.02.03.13.41.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Feb 2025 13:41:38 -0800 (PST) Date: Mon, 3 Feb 2025 14:41:35 -0700 From: Alex Williamson To: Amir Goldstein Cc: Jan Kara , Christian Brauner , Linus Torvalds , Peter Xu , Josef Bacik , kernel-team@fb.com, linux-fsdevel@vger.kernel.org, viro@zeniv.linux.org.uk, linux-xfs@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-mm@kvack.org, linux-ext4@vger.kernel.org, "linux-kernel@vger.kernel.org" , "kvm@vger.kernel.org" Subject: Re: [REGRESSION] Re: [PATCH v8 15/19] mm: don't allow huge faults for files with pre content watches Message-ID: <20250203144135.1caef6c3.alex.williamson@redhat.com> In-Reply-To: References: <9035b82cff08a3801cef3d06bbf2778b2e5a4dba.1731684329.git.josef@toxicpanda.com> <20250131121703.1e4d00a7.alex.williamson@redhat.com> <20250201-legehennen-klopfen-2ab140dc0422@brauner> <20250202-abbauen-meerrettich-912513202ce4@brauner> X-Mailer: Claws Mail 4.3.0 (GTK 3.24.43; x86_64-redhat-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: -CxDpw8Bm8xLAByUp5rY1zu9zfZzvAVADFvMuXXYetU_1738618899 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: E4ED4C0002 X-Stat-Signature: bi3skg9t3xdthkydow8fzxqxot1g6k8b X-Rspam-User: X-HE-Tag: 1738618901-96129 X-HE-Meta: U2FsdGVkX19PkL1F6LaIf18fUp9EGpixVO0N3946QZVa+pC4/v59RUUFsGfgKX5YVO23SvGQCpNNbHnvwhaeKbL+2bwcMr4/UJWssSnFpL38OyYd6SRD7wmGL4VUDzwJfMjCnojHrd3eWJuixzXmIDSlBHfiOgm/dS5GM7km9tN0v1K59SpcQExSoL4ZXzOeD2Hh94TV3V4T210VyNdArSO54CRDS0SiNdeNWhybzQ4mw0Po/5YyWOlc6Czv6cdnu6OlsDqArAu8Z4vKE7BT6YC88Pxw/vvtssWFpAkzFyGEAG+3SJYjpEfq0Z8NCYTlFUMJDtcjWbDvfd2M2zknhhu1dToKJFrNUNbcy5TzgsG69i7ENE5kKiqZ7p8o7/8Xm3kZuQhC9yOhlO/TOmLTK4QvRXdG0SylMXW8s+QyfOeeON6i0pPLMJldfNcUA6nDg6CQX2mRYssrI65x3iKwVcQyULinN6tZo7rHXpPxkjdqVDGBZ66cXZaxT4Mjabj1NJmI2dvgKW9mZE6IJuBj1Y6cAzspPQDy3KvoeTjzGz9nbwAarVr3K4fmsEwOVvoepb9CEU9zs9dIfZfeFe86qBpwHnLb4kHvXl3Cf6f7O8Ql20K0pjVW46YtozsUOg3w3Hu9h11TArN9acgjm6AmzQEEY1jTBqfO5Gu7E1vOgGVs04nKyfzrM9pla+yG+eHR6Ei/bWIznujEXeZC6Asd4duiGNI47zuIzwBafX4IIsIU4GWZ/9xr/0kG97eHIe5lDqKr23HloX4tTTF3c+6yGuBUOkC9mPBWy/rsfPg1vBwoPoV5DrjN2G10j8uH2wr+Vngy1ECQBOxM2kzESId8ZMD4WoqwmIOoTMoLTKCi5L1u9HVFDBaAsWqKIKL123pJxkQvbCJgNhrwUUENA6o8NO4rTGibtXDDOQ+Nf9KULqA1i5IWtHdkK7tgNgEI4u2gCsK5K0rNUlbNq+4cdP2 agKNYneY O55XMQvcKq7H9EQNKWkfWnkOUknarM/caE7AO6L1nJWsJJJ8V7I+HnQ/PWvmchwJmxeCpONQvy0wKtTxjZy8Yv7bqsmMzQWMBE3TUuc5gE5UmqNiJzlGnz7UkywtGjM4IRxUipXGF+wSH4t31Iu4eI/5cJPPDj/RLH11Y2i9rZoBI13Riu5x2HzSi/V23MJnj2uL7UPqqP7LJuc8CfkOvxEiFVdjPQd5X2QqBgoQ7n6S7pJTFmyrVUIp/KDhFDdHMODkHlb8xlpuJFQzy0HM3E1PW2n0EdM4rx9ADCJ36eyaMdksPbPQW4jfhS7jhmDH8kbpVlX34W0L2kUEOQyiJLxBg7ds9SfTIf5LpANH4NsPqhSwUtwangUo61nRyZWI+JlYA6FZqXhiu0y4Sx6J2U/gym3qHrfq4qha3Nod8nW5PwA6+Wuo5Aojcgzn+ykQ6+Z2G4nD4BdMnR3iSlBnXccLgkDNiuxJwhpde0olFIPY6IvUH7N3FdyqWoVvxFAIdj5R2UOHWhe56yDTnasVDk0oX4w== 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 Mon, 3 Feb 2025 21:39:27 +0100 Amir Goldstein wrote: > On Mon, Feb 3, 2025 at 1:41=E2=80=AFPM Jan Kara wrote: > > > > On Sun 02-02-25 11:04:02, Christian Brauner wrote: =20 > > > On Sun, Feb 02, 2025 at 08:46:21AM +0100, Amir Goldstein wrote: =20 > > > > On Sun, Feb 2, 2025 at 1:58=E2=80=AFAM Linus Torvalds > > > > wrote: =20 > > > > > > > > > > On Sat, 1 Feb 2025 at 06:38, Christian Brauner wrote: =20 > > > > > > > > > > > > Ok, but those "device fds" aren't really device fds in the sens= e that > > > > > > they are character fds. They are regular files afaict from: > > > > > > > > > > > > vfio_device_open_file(struct vfio_device *device) > > > > > > > > > > > > (Well, it's actually worse as anon_inode_getfile() files don't = have any > > > > > > mode at all but that's beside the point.)? > > > > > > > > > > > > In any case, I think you're right that such files would (accide= ntly?) > > > > > > qualify for content watches afaict. So at least that should pro= bably get > > > > > > FMODE_NONOTIFY. =20 > > > > > > > > > > Hmm. Can we just make all anon_inodes do that? I don't think you = can > > > > > sanely have pre-content watches on anon-inodes, since you can't r= eally > > > > > have access to them to _set_ the content watch from outside anywa= y.. > > > > > > > > > > In fact, maybe do it in alloc_file_pseudo()? > > > > > =20 > > > > > > > > The problem is that we cannot set FMODE_NONOTIFY - > > > > we tried that once but it regressed some workloads watching > > > > write on pipe fd or something. =20 > > > > > > Ok, that might be true. But I would assume that most users of > > > alloc_file_pseudo() or the anonymous inode infrastructure will not ca= re > > > about fanotify events. I would not go for a separate helper. It'd be > > > nice to keep the number of file allocation functions low. > > > > > > I'd rather have the subsystems that want it explicitly opt-in to > > > fanotify watches, i.e., remove FMODE_NONOTIFY. Because right now we h= ave > > > broken fanotify support for e.g., nsfs already. So make the subsystem= s > > > think about whether they actually want to support it. =20 > > > > Agreed, that would be a saner default. > > =20 > > > I would disqualify all anonymous inodes and see what actually does > > > break. I naively suspect that almost no one uses anonymous inodes + > > > fanotify. I'd be very surprised. > > > > > > I'm currently traveling (see you later btw) but from a very cursory > > > reading I would naively suspect the following: > > > > > > // Suspects for FMODE_NONOTIFY > > > drivers/dma-buf/dma-buf.c: file =3D alloc_file_pseudo(inode, dma= _buf_mnt, "dmabuf", > > > drivers/misc/cxl/api.c: file =3D alloc_file_pseudo(inode, cxl_vfs_mou= nt, name, > > > drivers/scsi/cxlflash/ocxl_hw.c: file =3D alloc_file_pseudo(in= ode, ocxlflash_vfs_mount, name, > > > fs/anon_inodes.c: file =3D alloc_file_pseudo(inode, anon_inode_= mnt, name, > > > fs/hugetlbfs/inode.c: file =3D alloc_file_pseudo(inode, mnt= , name, O_RDWR, > > > kernel/bpf/token.c: file =3D alloc_file_pseudo(inode, path.mnt, B= PF_TOKEN_INODE_NAME, O_RDWR, &bpf_token_fops); > > > mm/secretmem.c: file =3D alloc_file_pseudo(inode, secretmem_mnt, "sec= retmem", > > > block/bdev.c: bdev_file =3D alloc_file_pseudo_noaccount(BD_INODE(bd= ev), > > > drivers/tty/pty.c: static int ptmx_open(struct inode *inode, struct f= ile *filp) > > > > > > // Suspects for ~FMODE_NONOTIFY > > > fs/aio.c: file =3D alloc_file_pseudo(inode, aio_mnt, "[aio]", = =20 > > > > This is just a helper file for managing aio context so I don't think an= y > > notification makes sense there (events are not well defined). So I'd sa= y > > FMODE_NONOTIFY here as well. > > =20 > > > fs/pipe.c: f =3D alloc_file_pseudo(inode, pipe_mnt, "", > > > mm/shmem.c: res =3D alloc_file_pseudo(inode, mnt, name, O= _RDWR, =20 > > > > This is actually used for stuff like IPC SEM where notification doesn't > > make sense. It's also used when mmapping /dev/zero but that struct file > > isn't easily accessible to userspace so overall I'd say this should be > > FMODE_NONOTIFY as well. =20 >=20 > I think there is another code path that the audit missed for getting thes= e > pseudo files not via alloc_file_pseudo(): > ipc/shm.c: file =3D alloc_file_clone(base, f_flags, >=20 > which does not copy f_mode as far as I can tell. >=20 > > =20 > > > // Unsure: > > > fs/nfs/nfs4file.c: filep =3D alloc_file_pseudo(r_ino, ss_mnt, re= ad_name, O_RDONLY, =20 > > > > AFAICS this struct file is for copy offload and doesn't leave the kerne= l. > > Hence FMODE_NONOTIFY should be fine. > > =20 > > > net/socket.c: file =3D alloc_file_pseudo(SOCK_INODE(sock), sock_mnt= , dname, =20 > > > > In this case I think we need to be careful. It's a similar case as pipe= s so > > probably we should use ~FMODE_NONOTIFY here from pure caution. > > =20 >=20 > I tried this approach with patch: > "fsnotify: disable notification by default for all pseudo files" >=20 > But I also added another patch: > "fsnotify: disable pre-content and permission events by default" >=20 > So that code paths that we missed such as alloc_file_clone() > will not have pre-content events enabled. >=20 > Alex, >=20 > Can you please try this branch: >=20 > https://github.com/amir73il/linux/commits/fsnotify-fixes/ >=20 > and verify that it fixes your issue. >=20 > The branch contains one prep patch: > "fsnotify: use accessor to set FMODE_NONOTIFY_*" > and two independent Fixes patches. >=20 > Assuming that it fixes your issue, can you please test each of the > Fixes patches individually, because every one of them should be fixing > the issue independently and every one of them could break something, > so we may end up reverting it later on. Test #1: fsnotify: disable pre-content and permission events by default fsnotify: disable notification by default for all pseudo files fsnotify: use accessor to set FMODE_NONOTIFY_* Result: Pass, vfio-pci huge_fault observed Test #2: fsnotify: disable notification by default for all pseudo files fsnotify: use accessor to set FMODE_NONOTIFY_* Result: Pass, vfio-pci huge_fault observed Test #3: fsnotify: disable pre-content and permission events by default fsnotify: use accessor to set FMODE_NONOTIFY_* Result: Pass, vfio-pci huge_fault observed Test #4 (control): fsnotify: use accessor to set FMODE_NONOTIFY_* Result: Fail, no vfio-pci huge_fault observed For any combination of the Fixes patches: Tested-by: Alex Williamson Thanks! Alex