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 D5A46D42B85 for ; Tue, 12 Nov 2024 14:28:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 44DCA8D0002; Tue, 12 Nov 2024 09:28:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 3FCAB8D0001; Tue, 12 Nov 2024 09:28:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2780C8D0002; Tue, 12 Nov 2024 09:28:18 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 06DF38D0001 for ; Tue, 12 Nov 2024 09:28:18 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 91CAA140201 for ; Tue, 12 Nov 2024 14:28:17 +0000 (UTC) X-FDA: 82777671144.19.4BE4423 Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.223.130]) by imf12.hostedemail.com (Postfix) with ESMTP id 723964000B for ; Tue, 12 Nov 2024 14:27:56 +0000 (UTC) Authentication-Results: imf12.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=PxhF9k8I; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=Ci1Vbl6T; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=a2DBeAcV; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=6y0PPdox; dmarc=none; spf=pass (imf12.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=1731421633; a=rsa-sha256; cv=none; b=c0a/FWhGRQLiYuP9Ei80NTAX3XWD+5nBCDu0rN9uFltixZxImk8VSbyjni6eBjk2JzYwce hvqydSQEIR1jJvJHpX0DIFzVADqIOeGCyAUJOQjODgEaxWDk/B9g5vf/NVPP2UtKLq18wP y3vwPmEB8a9nsYCYVR45NHbZp/eKNJY= ARC-Authentication-Results: i=1; imf12.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=PxhF9k8I; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=Ci1Vbl6T; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=a2DBeAcV; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=6y0PPdox; dmarc=none; spf=pass (imf12.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=1731421633; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=ClyVBEltyYujlDz24jO9ypnOQpbboViAYoIODTZM/lw=; b=QAFzAwvXL+CXCYRxgxwigf7aBXUO0rpy4I/ZAtwrj0Q1Y0b7YRTG4sLlgIHHAchgMyVgyl DVfGsUogq7KwIwY03/OrnOudQOdsneK/LcjivJcfjCcdhHBaRTDvCGQq4+Br77hR/Jet18 780bn1TGI+KaDNHmBddMV5bfyZVhckQ= Received: from imap1.dmz-prg2.suse.org (unknown [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 71DFE21275; Tue, 12 Nov 2024 14:28:12 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1731421693; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ClyVBEltyYujlDz24jO9ypnOQpbboViAYoIODTZM/lw=; b=PxhF9k8IkeMhUwKvndc/9URZlbD0AYtO4ZjKFDU1nr2CCKah9R96iGDFRg6LUlXx6YKC9Z V2+xWYZV7Gg4uUXjwRHr/RvIlPyuxLzWrP4A/6647U9iTJEry7fS5Y3VVs6W9ayo0SZm99 woDtwu44zNI3HAtHSLn2ngHU2bLFeO0= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1731421693; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ClyVBEltyYujlDz24jO9ypnOQpbboViAYoIODTZM/lw=; b=Ci1Vbl6TgfKD9ClavZ7Q7QuGsHIJj/bYlZoXcKvhLsd254xsstCfqkoph4by+CfU/Ek/Ec IWWOXLp/SV5TfpCw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1731421692; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ClyVBEltyYujlDz24jO9ypnOQpbboViAYoIODTZM/lw=; b=a2DBeAcVrN9MAM1HhLmGD0W8BnqzSiQmc9yAKEJcQ83IeHu8gWgqWVbca72yn8VILMK4jW zd31FhmV8ZECi+l/aIw3MRWHSFczSEW35FaStLSgM80WSNg0rUm6cEA2JXRaeIAkmKZXRF 0oPJ3Z1xnykCfRZRbonBGylyW4LPQkA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1731421692; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ClyVBEltyYujlDz24jO9ypnOQpbboViAYoIODTZM/lw=; b=6y0PPdoxrn1WdBgQzkDGOUh21uXthXUHmM6s5ILlLv9bgMYHSprTwMAfZVFmgNDxb7F95W x/ijrAkQmYOUemCA== 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 65A0813301; Tue, 12 Nov 2024 14:28:12 +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 CQnLGPxlM2cXfAAAD6G6ig (envelope-from ); Tue, 12 Nov 2024 14:28:12 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id 15AC9A08D0; Tue, 12 Nov 2024 15:28:12 +0100 (CET) Date: Tue, 12 Nov 2024 15:28:12 +0100 From: Jan Kara To: Linus Torvalds Cc: Amir Goldstein , Josef Bacik , kernel-team@fb.com, linux-fsdevel@vger.kernel.org, jack@suse.cz, brauner@kernel.org, linux-xfs@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-mm@kvack.org, linux-ext4@vger.kernel.org Subject: Re: [PATCH v6 06/17] fsnotify: generate pre-content permission event on open Message-ID: <20241112142812.37e3hyar3zqoqo5a@quack3> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Queue-Id: 723964000B X-Rspamd-Server: rspam01 X-Stat-Signature: d34pef8dnn57ppdxxmpq7imhk5b6nrwu X-HE-Tag: 1731421676-53280 X-HE-Meta: U2FsdGVkX1/NsglP+qZWILgAKzaaPDtqu6ne33f6rQ9v6I4SVDtCx1dAH0zESokdGDmSjGRkIZ1RyFXhd5+bhzRtVLRyvBKy+nlqfUSITHeLzmrTDTYr6P0x5Y+CsAfNCig4Mm8kqgWmluO60iU/7XYBAW2hkg9S5CKNjHz4UgzIzX6TgmCibRascWucWntPhryr9A+eiVYpDFnE4p7Qw1+6Nv7qMvE8BdiUdov57QKLDwWf/+Ck9kr0bBnyQ9uyi1Mz8WSXnLlLkiBLEBNydvgz9lzxotfyBMXz8HBQS1U0vLDMQ0qL9DJnUGnoJPvpKEdje4Me1uTLOwlO/q3pf2K4ppEx+5Ha/10UPCdwWQzohuAHl6QZSZZjB3D95ytQIVp7MR3PUrcSOBvRwS7NF+0yWettt1upJnb/2ffcIi5rX+7HeyqxUHt95Z5zcXU3Qd/FLXYuYMlGAlB+IdJYtq158j+La+CcDuqJLK8RHlAfRrc+VExN+2RWzBK1TgTf0v6eXJ9SXNPDeDcRpZsrNVxKS1DhaVtR/sjJYaD7u2tKOxBwgJz9xuBs6FUf57OI12WVQyfTDZWcpOkEaNnBJdcwvYX0P5/FmUvVJvnLr5cy2bECqOfhQR3ffALHEY4H9CyWZ+cXHMMdmc9UUUP3vBrz6YToGS6J6jU6wTN1etbxszb4oXKspRcrhW2btxqmp9+uZPQ2ceVTKKHAD+BspFxbU7thgj4bYhhwITTF7/dv1YyOPzgZzb3eEJkiA0yhaQ7GMxISLp8kcJWQ+tYWG5nf5wAHJ8TxIYC+y+MXwUykCaC4w3vw0ambIVNUG2YRS517hGze9B0yBDMge/LtWmEDSovJvE37CnmZ7n/S+5M8YXCCSrrVkrZ4vMWS4HbeWWXn8pzRQAX7IUpH49/mjZjdyv8W/Ez87Xg+WezfUMpWLei26iT3EVtbJv8mvoHAWk0IiGoAGGr7Rp2KEND upXkKXTQ RZYSYVi6JwNUujWA+YM02fUDuAR9lTBwhYvA97eX3j9ZI5YGXCkF8FJbv/nM09K4RksLyc2vob3X2GVkfbrLXk86iuifwUpv8M9mxlu+xrrNrsqg1q7hXeNkagAA1w4tTO304SOmeB9DNfrgAWHHFJ6pHqUxdX8U2fChRUNXd4gUR4pgDHpcSMfRTyMJ0hGK/tP4TXfvGqcEhDNZGbQ7WKE5S4ROb/qOc/fudAX/ueuBLcgDAfAEXgCKUcrkzVdivrWcedbEHTfxBDNpkk3LqtyRBHK1YkQYAqtF2T1JtcaDDG7dSve82Y2PdXyTdz5Imrz6acb37WtSJ9fMpP5ddj0H37sSqjWXl2rQ6tbM4+Jjrocw= 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 11-11-24 16:37:30, Linus Torvalds wrote: > On Mon, 11 Nov 2024 at 16:00, Amir Goldstein wrote: > > > > I think that's a good idea for pre-content events, because it's fine > > to say that if the sb/mount was not watched by a pre-content event listener > > at the time of file open, then we do not care. > > Right. > > > The problem is that legacy inotify/fanotify watches can be added after > > file is open, so that is allegedly why this optimization was not done for > > fsnotify hooks in the past. > > So honestly, even if the legacy fsnotify hooks can't look at the file > flag, they could damn well look at an inode flag. > > And I'm not even convinced that we couldn't fix them to just look at a > file flag, and say "tough luck, somebody opened that file before you > started watching, you don't get to see what they did". > > So even if we don't look at a file->f_mode flag, the lergacy cases > should look at i_fsnotify_mask, and do that *first*. > > IOW, not do it like fsnotify_object_watched() does now, which is just > broken. Again, it looks at inode->i_sb->s_fsnotify_mask completely > pointlessly, but it also does it much too late - it gets called after > we've already called into the fsnotify() code and have messed up the > I$ etc. > > The "linode->i_sb->s_fsnotify_mask" is not only an extra indirection, > it should be very *literally* pointless. If some bit isn't set in > i_sb->s_fsnotify_mask, then there should be no way to set that bit in > inode->i_fsnotify_mask. So the only time we should access > i_sb->s_fsnotify_mask is when i_notify_mask gets *modified*, not when > it gets tested. Thanks for explanation but what you write here and below seems to me as if you are not aware of some features fanotify API provides (for many years). With fanotify you can place a mark not only on a file / directory but you can place it also on a mount point or a superblock. In that case any operation of appropriate type happening through that mount point or on that superblock should deliver the event to the notification group that placed the mark. So for example we check inode->i_sb->s_fsnotify_mask on open to be able to decide whether somebody asked to get notifications about *all* opens on that superblock and generate appropriate events. These features are there since day 1 of fanotify (at least for mountpoints, superblocks were added later) and quite some userspace depends on them for doing filesystem-wide event monitoring. We could somehow cache the fact that someone placed a mark on the superblock in the inode / struct file but I don't see how to keep such cache consistent with marks that are attached to the superblock without incurring the very same cache misses we are trying to avoid. I do like your idea of caching whether somebody wants the notification in struct file as that way we can avoid the cache misses for the new pre-content hooks and possibly in hooks for the traditional fanotify permission events. But I don't see how we could possibly avoid these cache misses for the classical notification events like FAN_OPEN, FAN_ACCESS, FAN_MODIFY, ... Honza -- Jan Kara SUSE Labs, CR