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 46B21D68B2F for ; Thu, 14 Nov 2024 15:01:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 2C7456B0089; Thu, 14 Nov 2024 10:01:38 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 276966B008A; Thu, 14 Nov 2024 10:01:38 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0F0726B008C; Thu, 14 Nov 2024 10:01:38 -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 E8BB86B0089 for ; Thu, 14 Nov 2024 10:01:37 -0500 (EST) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 8A736AD230 for ; Thu, 14 Nov 2024 15:01:37 +0000 (UTC) X-FDA: 82785013794.04.BC074A5 Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.223.131]) by imf15.hostedemail.com (Postfix) with ESMTP id B3441A0036 for ; Thu, 14 Nov 2024 15:00:48 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=qzCjYVvh; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=0wd5stp0; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=z2wk7+RR; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=6IyzxITT; dmarc=none; spf=pass (imf15.hostedemail.com: domain of jack@suse.cz designates 195.135.223.131 as permitted sender) smtp.mailfrom=jack@suse.cz ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731596364; a=rsa-sha256; cv=none; b=Y9ms1qNizONFqfV92ZNowNV3w0aUxG8WmUpkTVe80NkL7g1gmwxH57X3hnKiicNhLV3dLb MJPLkQlhAevxBTeoVolGUFqtoXeIGqIhhKEeepqWRTkOXrkarZSqqtX8dNVezAAAt5nfw8 BlLNhjbWu3EVeybpw3pQYscOQXHMdOs= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=qzCjYVvh; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=0wd5stp0; dkim=pass header.d=suse.cz header.s=susede2_rsa header.b=z2wk7+RR; dkim=pass header.d=suse.cz header.s=susede2_ed25519 header.b=6IyzxITT; dmarc=none; spf=pass (imf15.hostedemail.com: domain of jack@suse.cz designates 195.135.223.131 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=1731596364; 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=JOkgEKZwGt7e3JeGaWOfoWvvbqGAC0Wgb9QpxyCmJ5Q=; b=lOkxDN1kp+1h5poHsfwxl9siaIuY03w0avey2Hdm4BGfeMbo91UqS2GBP6/5xWnBCBDJpu /bPxS9/h/h2BiKjbzozdq5NfT5hnJvK0ckEVcONkAa+FmsgXhgV8VfA575A2WiSIH5AevJ g6mWPVP+R0jI3gYW3M0wxFVPKZPNOOE= 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-out2.suse.de (Postfix) with ESMTPS id CBB0A1F38F; Thu, 14 Nov 2024 15:01:31 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1731596492; 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=JOkgEKZwGt7e3JeGaWOfoWvvbqGAC0Wgb9QpxyCmJ5Q=; b=qzCjYVvhu+QfKL50FEb8/3whUikamdA5FGUZ2QboApYNf6agssDJRK/PU+GfEvDPZ1wqcJ IZtvqoGSAa8tLuJAuvsj2+oTnFcbZ0/8ytWhad5oGQXW3dC0b2Bv14o32nBA/1OJ/90KCf Ik7VQRZqvd3DHLUyjGnQ57JD7aQdJ2g= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1731596492; 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=JOkgEKZwGt7e3JeGaWOfoWvvbqGAC0Wgb9QpxyCmJ5Q=; b=0wd5stp0gMvsKH7Mk24JfNc4I3q0c2B+kTZqarrMyz0EfR+c4vdF64U91GOyscEhEodDer WcgfTknV/W0/9HDw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_rsa; t=1731596491; 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=JOkgEKZwGt7e3JeGaWOfoWvvbqGAC0Wgb9QpxyCmJ5Q=; b=z2wk7+RRZRVFCtTzgrFxgGXmn5UGzMMKXDooO5Rxj6Smjgw19vXHCxLSlRfDvgHOD8H3Uu K9NT70/mhgxSA4lOC/xETXXK6Hz2ORiGJwpva7oeSS6k1QVFVssxP8nfvknhYiDaLdGVSn 8etHSDR2xuzoanMqswo3cWKt4xEr1Vw= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.cz; s=susede2_ed25519; t=1731596491; 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=JOkgEKZwGt7e3JeGaWOfoWvvbqGAC0Wgb9QpxyCmJ5Q=; b=6IyzxITTU0qTKg5sEMi+esXkqmnPw5iy9nXqCbZNZDGttOWIoUitYww86SDmHNfg5S2g9G 4euMM4xqUXylbvDA== 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 BCC9113721; Thu, 14 Nov 2024 15:01:31 +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 OCoTLssQNmdXfwAAD6G6ig (envelope-from ); Thu, 14 Nov 2024 15:01:31 +0000 Received: by quack3.suse.cz (Postfix, from userid 1000) id 45680A0962; Thu, 14 Nov 2024 16:01:27 +0100 (CET) Date: Thu, 14 Nov 2024 16:01:27 +0100 From: Jan Kara To: Amir Goldstein Cc: Linus Torvalds , 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 v7 05/18] fsnotify: introduce pre-content permission events Message-ID: <20241114150127.clibtrycjd3ke5ld@quack3> References: <141e2cc2dfac8b2f49c1c8d219dd7c20925b2cef.1731433903.git.josef@toxicpanda.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Action: no action X-Rspamd-Queue-Id: B3441A0036 X-Stat-Signature: g4netkdgzpcn3ycaom5bsjedt3waa3i3 X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1731596448-826534 X-HE-Meta: U2FsdGVkX1/LFt/0z5OOj9/9EIrAXpV4ZCs+nxhj+Sr3QwOppqffn6aF8mRFrEARdatcTb9Ml8/16m57uEfIXXIHbUU41XAIozXwtZUI+al49hSQTQo4uWVBWHO025CzHKV+bKpqNn4zxPYqVApf6wWhFHDEARh+ezWhHN9FsNI9kb66JnUpCnLjAvcu+dRjUlQ1jbqnSh7kUA/Ck1MYWGyxxHktkIgoPMQFnneY8BsdL3ZzjVAgJrM1BRa/0+vsNOmWl42mekCkijo+TqB2d6OwW9rNjXyvbv3LGC4WsMxhsagXNlRpI/59snkFmAbaNhl0URIkuE4Dk4UUjdI7KzkEDFwVuGK3RG3FarPnop78zIGgZytxqhRB4/NVzYXIkkZT1Ny4yO/dkfXx6aLBH5uhIGEMryL2BTXJHzbeN40trMgmMEDLJESsFJxluKZ8oZmhwQSauwEza2fIR3cppvh1NuVX7flYuWGdi1RiCjpNWErwmgt967anAK3z9keeA5KNCbCDgudIRI+eSbn6DtnHy2p+6LzY2U3OEzn+HCKwX3aJjKos63o6C2S6wFLRY2yR8zIshnFBOWfcumAxqpF4kpCnizh6IKzaFDJAQSbJ+4cPrH4IPl+ctzr7qXznFYvrpCP2D7bL7X2jCnu3qHMfq+yfRbKdZDMWvMFjLaBTfGnyfActetCSpVZhiSEGtAbpvXtU14m4ZBcP2C+evlSsoHti+05DxNLlNzWx1J/T7ULAf4Xf9VRZ0SniKGBMACLh2Nq7my9jDgvRXctCifPeHzaPegswUA4jvrMYGUARtmGHhUIenpyeHt+qtN9paFsJZsIUcyZdJb3etjlp2FHM7Gz5JRa9epja5wnPempV/wt9W51Q8Zdo/OZxfMmKzDXfmpiU3a0CZtGBq5SZef4EkmPJJfxP9zullXJeP5Ak0ES9dUi6Dh0w9dQENWmM1sN4pWl67c+DBSEx2Cg AddGgR7K bUdnokcr2OFOlXhhST2xL22g6lp7qmXr2A6BGWEzEmLoSthBWPSkbWfAxQWPXpKQoW19JE3wAwdKkdFvOdNt5q4oSv03vCrA009gjKJEoio8EzIWZZftksb/pyU1wHNpdgm7JfZNwcLTnMfScRgcrGo5bFlFi4CFy3aPj0NB24wFuW3vAKTflF5MSSfi1CQcAPR9GMyHXb7zCUv2+J+SKrAv/+eBC1yQCG12zI+7/MGtR5I4f4WrQ5nUxT1LSYG+akkBRH3SmMv/pHHWPIM2DLbh0U/+Xj8fqeL7rJsni3HjdGea7IoMCg7fSeMuOSm8oy4beorHqYlppQs4tJz4hDu/Y/1MjLnIXNCd/0pEwF34HlcGX8DVkoNb/HhyAcGw8CIYBIfM1weUl9Px9LXP5TjLn1ufEHXtTNyEHg+ZoDOhNksx1QkH9In/DqYxr7L/BmuB+ 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 Wed 13-11-24 19:49:31, Amir Goldstein wrote: > From 7a2cd74654a53684d545b96c57c9091e420b3add Mon Sep 17 00:00:00 2001 > From: Amir Goldstein > Date: Tue, 12 Nov 2024 13:46:08 +0100 > Subject: [PATCH] fsnotify: opt-in for permission events at file open time > > Legacy inotify/fanotify listeners can add watches for events on inode, > parent or mount and expect to get events (e.g. FS_MODIFY) on files that > were already open at the time of setting up the watches. > > fanotify permission events are typically used by Anti-malware sofware, > that is watching the entire mount and it is not common to have more that > one Anti-malware engine installed on a system. > > To reduce the overhead of the fsnotify_file_perm() hooks on every file > access, relax the semantics of the legacy FAN_ACCESS_PERM event to generate > events only if there were *any* permission event listeners on the > filesystem at the time that the file was opened. > > The new semantic is implemented by extending the FMODE_NONOTIFY bit into > two FMODE_NONOTIFY_* bits, that are used to store a mode for which of the > events types to report. > > This is going to apply to the new fanotify pre-content events in order > to reduce the cost of the new pre-content event vfs hooks. > > Suggested-by: Linus Torvalds > Link: https://lore.kernel.org/linux-fsdevel/CAHk-=wj8L=mtcRTi=NECHMGfZQgXOp_uix1YVh04fEmrKaMnXA@mail.gmail.com/ > Signed-off-by: Amir Goldstein Couple of notes below. > diff --git a/fs/open.c b/fs/open.c > index 226aca8c7909..194c2c8d8cd4 100644 > --- a/fs/open.c > +++ b/fs/open.c > @@ -901,7 +901,7 @@ static int do_dentry_open(struct file *f, > f->f_sb_err = file_sample_sb_err(f); > > if (unlikely(f->f_flags & O_PATH)) { > - f->f_mode = FMODE_PATH | FMODE_OPENED; > + f->f_mode = FMODE_PATH | FMODE_OPENED | FMODE_NONOTIFY; > f->f_op = &empty_fops; > return 0; > } > @@ -929,6 +929,12 @@ static int do_dentry_open(struct file *f, > if (error) > goto cleanup_all; > > + /* > + * Set FMODE_NONOTIFY_* bits according to existing permission watches. > + * If FMODE_NONOTIFY was already set for an fanotify fd, this doesn't > + * change anything. > + */ > + f->f_mode |= fsnotify_file_mode(f); Maybe it would be obvious to do this like: file_set_fsnotify_mode(f); Because currently this depends on the details of how exactly FMODE_NONOTIFY is encoded. > diff --git a/include/linux/fs.h b/include/linux/fs.h > index 70359dd669ff..dd583ce7dba8 100644 > --- a/include/linux/fs.h > +++ b/include/linux/fs.h > @@ -173,13 +173,14 @@ typedef int (dio_iodone_t)(struct kiocb *iocb, loff_t offset, > > #define FMODE_NOREUSE ((__force fmode_t)(1 << 23)) > > -/* FMODE_* bit 24 */ > - > /* File is embedded in backing_file object */ > -#define FMODE_BACKING ((__force fmode_t)(1 << 25)) > +#define FMODE_BACKING ((__force fmode_t)(1 << 24)) > + > +/* File shouldn't generate fanotify pre-content events */ > +#define FMODE_NONOTIFY_HSM ((__force fmode_t)(1 << 25)) > > -/* File was opened by fanotify and shouldn't generate fanotify events */ > -#define FMODE_NONOTIFY ((__force fmode_t)(1 << 26)) > +/* File shouldn't generate fanotify permission events */ > +#define FMODE_NONOTIFY_PERM ((__force fmode_t)(1 << 26)) > > /* File is capable of returning -EAGAIN if I/O will block */ > #define FMODE_NOWAIT ((__force fmode_t)(1 << 27)) > @@ -190,6 +191,21 @@ typedef int (dio_iodone_t)(struct kiocb *iocb, loff_t offset, > /* File does not contribute to nr_files count */ > #define FMODE_NOACCOUNT ((__force fmode_t)(1 << 29)) > > +/* > + * The two FMODE_NONOTIFY_ bits used together have a special meaning of > + * not reporting any events at all including non-permission events. > + * These are the possible values of FMODE_NOTIFY(f->f_mode) and their meaning: > + * > + * FMODE_NONOTIFY_HSM - suppress only pre-content events. > + * FMODE_NONOTIFY_PERM - suppress permission (incl. pre-content) events. > + * FMODE_NONOTIFY - suppress all (incl. non-permission) events. > + */ > +#define FMODE_NONOTIFY_MASK \ > + (FMODE_NONOTIFY_HSM | FMODE_NONOTIFY_PERM) > +#define FMODE_NONOTIFY FMODE_NONOTIFY_MASK > +#define FMODE_NOTIFY(mode) \ > + ((mode) & FMODE_NONOTIFY_MASK) This looks a bit error-prone to me (FMODE_NONOTIFY looks like another FMODE flag but in fact it is not which is an invitation for subtle bugs) and the tests below which are sometimes done as (FMODE_NOTIFY(mode) == xxx) and sometimes as (file->f_mode & xxx) are inconsistent and confusing (unless you understand what's happening under the hood). So how about defining macros like FMODE_FSNOTIFY_NORMAL(), FMODE_FSNOTIFY_CONTENT() and FMODE_FSNOTIFY_PRE_CONTENT() which evaluate to true if we should be sending normal/content/pre-content events to the file. With appropriate comments this should make things more obvious. Honza -- Jan Kara SUSE Labs, CR