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 480FDC0218F for ; Sun, 2 Feb 2025 10:04:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5F38F6B007B; Sun, 2 Feb 2025 05:04:12 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 57C1D6B0083; Sun, 2 Feb 2025 05:04:12 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 443D16B0085; Sun, 2 Feb 2025 05:04:12 -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 1A98A6B007B for ; Sun, 2 Feb 2025 05:04:12 -0500 (EST) Received: from smtpin01.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 71883A1FE9 for ; Sun, 2 Feb 2025 10:04:11 +0000 (UTC) X-FDA: 83074569102.01.03F2B3B Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf13.hostedemail.com (Postfix) with ESMTP id C32D920008 for ; Sun, 2 Feb 2025 10:04:09 +0000 (UTC) Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=b6POX4H5; spf=pass (imf13.hostedemail.com: domain of brauner@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=brauner@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738490649; 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=CXb0jvloYuHdXlVhaT28JYYi7J1dCK/dvxtc5vajEoE=; b=R34wSTFZV1nsQ7IjVxPD88p4JLMwOn+hflA6vLiK+axV5tmlHI+MyH7SrScaqO57v6T+si fP6nP8R6ocQDY/M/1qjxQSZQSViwdXGCOnYEmcWz1yZg80gEZpsJ9iPC74Ja9ft5+ysR5P VSfnR8EJ1VYuJuOP7djJOPIxfRS9C1s= ARC-Authentication-Results: i=1; imf13.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=b6POX4H5; spf=pass (imf13.hostedemail.com: domain of brauner@kernel.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=brauner@kernel.org; dmarc=pass (policy=quarantine) header.from=kernel.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738490649; a=rsa-sha256; cv=none; b=3n/AXDS2TNofcUM30kwy4LdsIcrr2wRSWgEDNidAn1uYYAXwKYLosHJI5YqWtX0RmWFg7R 0bJG/8hkJz4FnRfe80Dmvk7qaGbRiRCic29iKuRJnJX8NKdlKwVcCNA35zs4PKskWtCr3f 9k3jLd1t44YaIMg9VlRknYIxUQyGjnE= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id 75A49A40235; Sun, 2 Feb 2025 10:02:22 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E9657C4CED1; Sun, 2 Feb 2025 10:04:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1738490648; bh=5A0/mbYhYVhz+EAh4niEYVaHaPaMDyo4YCYJ4LKkzsY=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=b6POX4H5oxeJIP0Oz3wl/tMuUNjNfGnUuDdqDOX1gC1yVkwxrKGivBkXucI1X36Ea Dfik1aAcAskf/w2yBbjZ4QXR2CMyDkfFk3zMUbG1tTr3ROMKVhUHNpLZyFj+1UEpJO C206/Hnp3kknPUP1GKRO6WenGKK9hdleRoXn5IODEeg6Vh9e8gmUB1LLtTlS/vAYfB 2rG2GkzCmNthh+KQEY0wnqAJKX4UW60NM4mccxYxG7DEfjQYe3FDa201J4Wp0MnKxQ lrFDHmAWFaBkwIuyKk5cU52dTJLaIj2vX0saJXFhrbJg+FVEaoiUCxT0a+KNFSZ70f 5KeIzRwMl++4g== Date: Sun, 2 Feb 2025 11:04:02 +0100 From: Christian Brauner To: Amir Goldstein Cc: Linus Torvalds , Peter Xu , Alex Williamson , Josef Bacik , kernel-team@fb.com, linux-fsdevel@vger.kernel.org, jack@suse.cz, 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: <20250202-abbauen-meerrettich-912513202ce4@brauner> References: <9035b82cff08a3801cef3d06bbf2778b2e5a4dba.1731684329.git.josef@toxicpanda.com> <20250131121703.1e4d00a7.alex.williamson@redhat.com> <20250201-legehennen-klopfen-2ab140dc0422@brauner> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: C32D920008 X-Stat-Signature: t1ru4pn9yafom76m93is8bb8eq5hrsk8 X-Rspam-User: X-HE-Tag: 1738490649-550550 X-HE-Meta: U2FsdGVkX1+35hsW7ZNpps3inqYId32QNjNr87+ZAvbXMp5tI2iY4cYd0V2cDCJhh+EzgnDDBVfbg0pX20R6GrrZIZIQnv+5lKp85QYfDYdpd3xOk5I3P1zI9PovdgttznpSOKA3wNc2YC6kuVplq+6kwOOP5UYFqtOmbteVsq9sm2Lne4SL82Mh0+7wcuqRaqcf27ysCODcgHBC3b1Ub0ZpWB84RoKjQTghV1WFW9DUS16QSbDw0+JK4//KmXG2C9t0N1nU+H/6ByyTipW2163YOXcjl0aYqc5974gWbhpyU5d93FzwFCnNSZkHE2c5Glh8cZ2Jj3tHYhkQ6wTMZLv+qfErEl7qzRxTmTzQsgWiHfZqneczokVV7RGn9oRBAQW0DQ9lLHiOGjU/hWskfAG77HFQ8lhTQ7dlFN469uftVK/CRXiINSTm1v56O6kjRyUzAu239/hv6vQ1Rj6smjnoR16hNK2PjhD9qWUkWJDOKWHXbfRH2Ju5tpDJsOK9Q3f6MCuwS7Z+yRUUDNJalsPQl/9H6ZijukrVutQK55JLiuhAtgxp2W7bLmAcBVrJ3DxXMI5Kqxarwg4cUs2gT8CU/Q3dxLspqcIkkI9Zw16eaFUbcqpDDaX5m0jkOs8dWk0QFgK8BhhnosDW8dkgNcUefqOohkw/8j30m6yTGtmk0ZDYCKf+FHgEJ27KFM4PkNZI2YQxHpAOt/Z50Y73QwQbmaqvQD/+5ipek6K5YsD8eq7PfsGeAXnS8GlwfSlaFJWRsxMnhRdPA3hP4Q/bJXKihvXqmk/rsczRXe+FWFkcxknCkyKgXgG67uIViwb2lDUanjLeHXiMr+8F9OaI92oSKdYHeF+lN+qYJUF73kIqduPRlWF7SLlSJoVYOh5iyMebLgIg00BBiOTpxIaj8Vcxf7eyXJdL9FBfqNcicXfp3OWKmAfRRBYvwptl5dO6EAG/HJMlCGQUXy8rtsC J6fly4tG I8HB10hpDxzlYoehQ+4lxZLCx+gS11pgnY7hA9+VXKfDzZOLMtz7qg7SXt/yAivcSoV/vM5cpTFPz+VOurW2Wd9FrDZo5ZM9krmbBlwRd7Eu66QzgB44inMNixh/NvrmBiGJNhdX+4oPmta93c+8JjUnI2XVTdhregAy6ZIGbnLQ9V1mBi7G1jRJbVhtkT7cwnVcFOrbNp7u4vYw6FShK311GS6sWp+O67SaQTjfQd7vbL+IdWa9Gnhf2REM2lwfURBTWvXAm3QUTNijPrqm76brfOAJ8Tt2ksa0EvpbjSiis4Wvd9RLQswUdvI49OwI4x3Ujq+GlXPf9Y/DkK0Q9CIUD3J/rD3MDbdQI+merbH//deJMbNGJh5OudH32toyxbokq1Ur3C5zXWZtXq4odU18qoZSnuVo19HAdpeUP+yBO0C4LWaBh1SpAr+CsDOAI1DHf 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, Feb 02, 2025 at 08:46:21AM +0100, Amir Goldstein wrote: > On Sun, Feb 2, 2025 at 1:58 AM Linus Torvalds > wrote: > > > > On Sat, 1 Feb 2025 at 06:38, Christian Brauner wrote: > > > > > > Ok, but those "device fds" aren't really device fds in the sense 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 (accidently?) > > > qualify for content watches afaict. So at least that should probably get > > > FMODE_NONOTIFY. > > > > 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 really > > have access to them to _set_ the content watch from outside anyway.. > > > > In fact, maybe do it in alloc_file_pseudo()? > > > > 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. Ok, that might be true. But I would assume that most users of alloc_file_pseudo() or the anonymous inode infrastructure will not care 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 have broken fanotify support for e.g., nsfs already. So make the subsystems think about whether they actually want to support it. 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 = alloc_file_pseudo(inode, dma_buf_mnt, "dmabuf", drivers/misc/cxl/api.c: file = alloc_file_pseudo(inode, cxl_vfs_mount, name, drivers/scsi/cxlflash/ocxl_hw.c: file = alloc_file_pseudo(inode, ocxlflash_vfs_mount, name, fs/anon_inodes.c: file = alloc_file_pseudo(inode, anon_inode_mnt, name, fs/hugetlbfs/inode.c: file = alloc_file_pseudo(inode, mnt, name, O_RDWR, kernel/bpf/token.c: file = alloc_file_pseudo(inode, path.mnt, BPF_TOKEN_INODE_NAME, O_RDWR, &bpf_token_fops); mm/secretmem.c: file = alloc_file_pseudo(inode, secretmem_mnt, "secretmem", block/bdev.c: bdev_file = alloc_file_pseudo_noaccount(BD_INODE(bdev), drivers/tty/pty.c: static int ptmx_open(struct inode *inode, struct file *filp) // Suspects for ~FMODE_NONOTIFY fs/aio.c: file = alloc_file_pseudo(inode, aio_mnt, "[aio]", fs/pipe.c: f = alloc_file_pseudo(inode, pipe_mnt, "", mm/shmem.c: res = alloc_file_pseudo(inode, mnt, name, O_RDWR, // Unsure: fs/nfs/nfs4file.c: filep = alloc_file_pseudo(r_ino, ss_mnt, read_name, O_RDONLY, net/socket.c: file = alloc_file_pseudo(SOCK_INODE(sock), sock_mnt, dname, > > and the no-pre-content is a flag combination (to save FMODE_ flags) > which makes things a bit messy. > > We could try to initialize f_mode to FMODE_NONOTIFY_PERM > for anon_inode, which opts out of both permission and pre-content > events and leaves the legacy inotify workloads unaffected. > > But, then code like this will not do the right thing: > > /* We refuse fsnotify events on ptmx, since it's a shared resource */ > filp->f_mode |= FMODE_NONOTIFY; > > We will need to convert all those to use a helper. > I am traveling today so will be able to look closer tomorrow. > > Jan, > > What do you think? > > Amir.