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 3D8BDC02192 for ; Mon, 3 Feb 2025 12:49:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A7F31280002; Mon, 3 Feb 2025 07:49:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A2EFA280001; Mon, 3 Feb 2025 07:49:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8F6B2280002; Mon, 3 Feb 2025 07:49:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 7059E280001 for ; Mon, 3 Feb 2025 07:49:22 -0500 (EST) Received: from smtpin20.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id EAF88162739 for ; Mon, 3 Feb 2025 12:41:57 +0000 (UTC) X-FDA: 83078595474.20.1836E21 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf19.hostedemail.com (Postfix) with ESMTP id 699861A000D for ; Mon, 3 Feb 2025 12:41:55 +0000 (UTC) Authentication-Results: imf19.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=NAjCFwx7; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="IwoVcn/E"; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=Qz20zXWG; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=w9Dk0qYu; dmarc=none; spf=pass (imf19.hostedemail.com: domain of jack@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=jack@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1738586515; a=rsa-sha256; cv=none; b=bZL7ULQbQxCGQDu6VCRQKj71r+Lh09MzPlluSfynnF1nWzXrH0OvZ2j4f4ja272xGkSUj5 S3qJIjJ/j3BaCsTWIW68CjGPKJ/W1ibABQxKaAFh+Oww9ojhyUCRprf69E0ksFogyHDtwS ShEH/F2OfBos9e0P89CJrMQeyDCjE+Y= ARC-Authentication-Results: i=1; imf19.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=NAjCFwx7; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b="IwoVcn/E"; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=Qz20zXWG; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=w9Dk0qYu; dmarc=none; spf=pass (imf19.hostedemail.com: domain of jack@suse.cz designates 195.135.223.130 as permitted sender) smtp.mailfrom=jack@suse.cz ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1738586515; 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=LJWjAyc38HgmMq7RG5PMlvFu0+nk7azvrMUFHWZiO7E=; b=ehNNRmCTVpyWPF92xTXxZ73w3DlwPQ7EvUQ90FLfNEohMlTJ+q3fa60WDc72qHwXrhIaRs a14ZR66jXSX+tizoVBeAKI4GSch7wrNc/LScF+JGV/LT/NmslBUtCmz96duyrziz5MIUs3 OTpsjaNohyFfv4HWH7z/JipdT6NfvdI= Received: from imap1.dmz-prg2.suse.org (imap1.dmz-prg2.suse.org [IPv6:2a07:de40:b281:104:10:150:64:97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 8CE3D21164; Mon, 3 Feb 2025 12:41:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1738586509; h=from:from:reply-to: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=LJWjAyc38HgmMq7RG5PMlvFu0+nk7azvrMUFHWZiO7E=; b=NAjCFwx77MhrjumkrQSkgqr644JSzmfBTwNJz+HfFhQzApp/0kXZ7w+dyXIDXe5TqgoA3n Ir+14AAQ0j09IfzBwbrUgzuv5/Qg0Vc/Fr36ttXNgyAU6MxOhdeBoO9oibmK5kxUPs2x5P PilwBNXj+BVnKS2cX+2C31fWfNElH3k= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1738586509; h=from:from:reply-to: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=LJWjAyc38HgmMq7RG5PMlvFu0+nk7azvrMUFHWZiO7E=; b=IwoVcn/ENnXitQ/oz5HqHn7NhLsERCl+5oGrOyOSiwk7Zc43g66hTmRUE/ADIMSD9L3pSv o6Zc7MM/ERGL7WBw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1738586505; h=from:from:reply-to: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=LJWjAyc38HgmMq7RG5PMlvFu0+nk7azvrMUFHWZiO7E=; b=Qz20zXWG/jrWaw6ARmvtRiISjA3T7XBikeog7A91unNXyPHqCR/+lUQ+Wgv74cm08ZjSH8 fFe2lTQWyj+AtDILBrIxUEHbJojee5UDowgSsKVC/7FXOwYqjNy7nER/HYzw5ZSk9Bnh/q gtKupnjRIAwMdlDN0Won2MwMY+vvOfU= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1738586505; h=from:from:reply-to: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=LJWjAyc38HgmMq7RG5PMlvFu0+nk7azvrMUFHWZiO7E=; b=w9Dk0qYuqnOaeeXtGnx9wC58jQXmqaDZ37q9PG1Qk0nZzLJJMQVptS1CzAOgndg1zOCywT LHcIPAEppTyK2iDw== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id 7A32F13795; Mon, 3 Feb 2025 12:41:45 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id VnvJHYm5oGclIAAAD6G6ig (envelope-from ); Mon, 03 Feb 2025 12:41:45 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id 211EBA28E5; Mon, 3 Feb 2025 13:41:45 +0100 (CET) Date: Mon, 3 Feb 2025 13:41:45 +0100 From: Jan Kara To: Christian Brauner Cc: Amir Goldstein , 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: References: <9035b82cff08a3801cef3d06bbf2778b2e5a4dba.1731684329.git.josef@toxicpanda.com> <20250131121703.1e4d00a7.alex.williamson@redhat.com> <20250201-legehennen-klopfen-2ab140dc0422@brauner> <20250202-abbauen-meerrettich-912513202ce4@brauner> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20250202-abbauen-meerrettich-912513202ce4@brauner> X-Rspamd-Action: no action X-Rspam-User: X-Rspamd-Queue-Id: 699861A000D X-Rspamd-Server: rspam10 X-Stat-Signature: 3447qyqo5puqyupmcghbyuzgcdq61ih7 X-HE-Tag: 1738586515-75953 X-HE-Meta: U2FsdGVkX186ByNTPQi+9MyY39nqJfN/h4+qjV5sKyvON7Sc5LlVaw4d1gE5N4kocsHKDTiRx07KUS7gNe2ALAo8kWmYwmaRxB+6VnBOU/8QkP6QwhjUpQBxG+QaLwgDcPbqTotKmBEZkbvq2vIDo79x9FgJkp7TqSavCGBc6SpBazrSU3OfsrDPV+JkEZ4/palWX5X+sf20/njqahKXtEhaaMivbGpA8EOkj1u1UvOs4QyaSGijbADiUtRFwhdRhCuTlbuGeqHmEPwXYRbTyUA37/OkhgbEqeYgU9Pc5COin15IockvGrpyD1C2h70e9in18wmKmlqDHR3DMAw3NaHFikUH8YD6tdlJWWhGYSOKZPOYcT7EWvtVANC7X2+dtLiWFfiGb0FlLgC8eDOhWGS2oK2Ugk9f5uXHLYL4AuTTyzXmsyVZWlkHQ7sUgSji78/0v+PPfg1GGlSbAlJDACMO1heerIzgRUvSqAF054P/h6/CC4elWbfl/CJgZP7G5/b92S3lgeVElN4t49xZDGRKN+W95SeTrINbuGYAieOk/exW4WLDvz6ATeEk54L+d7gF/hjE8BKp2x2z54u/LhKkbiR+S7Agq5lWWKHvS4KfLnLF/Emz1TqH61MF5lazCLGbYE8mCk/t7SRQFxP4SPUw/KECh6duM7lqEIteqb5fwK6t+tcf40CIkHSc2VZ8Yq9VvyFxZBd8r7pTVk/fnuya9KbV8cQrGZiORSfHG710hbuqIRULI4uPgss5FbR2/p47wQAIQ5G0l4KIKdKiSCrEJ5vyQytTyFWEKVPSJqZlInEvSTXj6jNJy1T8tl//q4boEeqMVVrQCIk6wjDpadyskUzKSf0YAOoEkXzAPFnFpeRHtcfNwUD0bml9oyBPdqMpQB/RIrfZgLWbSaHc6ektONBzrP0rHppqGKahXzrlBMrMg4dQxPXK0WLxeTt4SRYpU7n8C/B/wR/ITSi YOTgjgMT 5AKxjNog8pv7vQxvuQm1cmJnqMLuAnn7z9n+9HZRK9zny/5dTKIZSR7+X2GPlJrapDpPIcfNb4HHD5GJBjHoKc7aCk5uwCx3y6O+EHPqD/gGDzmkkcTReJsa31fehkAOCtMSMNmwEIAjk2m4Lcj6PUgzw8lwVHhvxV8rJfDlOawMCbzqLvwa6QGZXSyG2fIYWAABSntw5QcA+hu+4nA1B2mcgsJptKMh4VR9yUwRqV4HwRKFhXhYDf3SnRU31YIKUh7VO36Eb+QhMyBJlTYMZxsr7HThuaWdl3QRTRifl0Z2WrhGaJANe6TwIwme53c8P9SH9LIFotqQFyhV39rpD5Scaeby6acIuyVGaLUyEMRT5VuiLs+xxVr9cH+1BuWiGXqG7GfFOu8bUdLvzd6x22jxVkXx87U9FwqSdIvBIuLPdAoixeMtgXUNPimIKmC8vOY+ygQ5kIaiznQ1GAGGsLbyIVcvDrFo4Ya6GSoU57l3eDa0= 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 02-02-25 11:04:02, Christian Brauner wrote: > 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. Agreed, that would be a saner default. > 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]", This is just a helper file for managing aio context so I don't think any notification makes sense there (events are not well defined). So I'd say FMODE_NONOTIFY here as well. > fs/pipe.c: f = alloc_file_pseudo(inode, pipe_mnt, "", > mm/shmem.c: res = alloc_file_pseudo(inode, mnt, name, O_RDWR, 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. > // Unsure: > fs/nfs/nfs4file.c: filep = alloc_file_pseudo(r_ino, ss_mnt, read_name, O_RDONLY, AFAICS this struct file is for copy offload and doesn't leave the kernel. Hence FMODE_NONOTIFY should be fine. > net/socket.c: file = alloc_file_pseudo(SOCK_INODE(sock), sock_mnt, dname, In this case I think we need to be careful. It's a similar case as pipes so probably we should use ~FMODE_NONOTIFY here from pure caution. Honza -- Jan Kara SUSE Labs, CR