From: Linus Torvalds <torvalds@linux-foundation.org>
To: Josef Bacik <josef@toxicpanda.com>
Cc: kernel-team@fb.com, linux-fsdevel@vger.kernel.org, jack@suse.cz,
amir73il@gmail.com, 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
Date: Tue, 12 Nov 2024 12:12:20 -0800 [thread overview]
Message-ID: <CAHk-=wjkBEch_Z9EMbup2bHtbtt7aoj-o5V6Nara+VxeUtckGw@mail.gmail.com> (raw)
In-Reply-To: <141e2cc2dfac8b2f49c1c8d219dd7c20925b2cef.1731433903.git.josef@toxicpanda.com>
On Tue, 12 Nov 2024 at 09:56, Josef Bacik <josef@toxicpanda.com> wrote:
>
> #ifdef CONFIG_FANOTIFY_ACCESS_PERMISSIONS
> +static inline int fsnotify_pre_content(struct file *file)
> +{
> + struct inode *inode = file_inode(file);
> +
> + /*
> + * Pre-content events are only reported for regular files and dirs
> + * if there are any pre-content event watchers on this sb.
> + */
> + if ((!S_ISDIR(inode->i_mode) && !S_ISREG(inode->i_mode)) ||
> + !(inode->i_sb->s_iflags & SB_I_ALLOW_HSM) ||
> + !fsnotify_sb_has_priority_watchers(inode->i_sb,
> + FSNOTIFY_PRIO_PRE_CONTENT))
> + return 0;
> +
> + return fsnotify_file(file, FS_PRE_ACCESS);
> +}
Yeah, no.
None of this should check inode->i_sb->s_iflags at any point.
The "is there a pre-content" thing should check one thing, and one
thing only: that "is this file watched" flag.
The whole indecipherable mess of inline functions that do random
things in <linux/fsnotify.h> needs to be cleaned up, not made even
more indecipherable.
I'm NAKing this whole series until this is all sane and cleaned up,
and I don't want to see a new hacky version being sent out tomorrow
with just another layer of new hacks, with random new inline functions
that call other inline functions and have complex odd conditionals
that make no sense.
Really. If the new hooks don't have that *SINGLE* bit test, they will
not get merged.
And that *SINGLE* bit test had better not be hidden under multiple
layers of odd inline functions.
You DO NOT get to use the same old broken complex function for the new
hooks that then mix these odd helpers.
This whole "add another crazy inline function using another crazy
helper needs to STOP. Later on in the patch series you do
+/*
+ * fsnotify_truncate_perm - permission hook before file truncate
+ */
+static inline int fsnotify_truncate_perm(const struct path *path,
loff_t length)
+{
+ return fsnotify_pre_content(path, &length, 0);
+}
or things like this:
+static inline bool fsnotify_file_has_pre_content_watches(struct file *file)
+{
+ if (!(file->f_mode & FMODE_NOTIFY_PERM))
+ return false;
+
+ if (!(file_inode(file)->i_sb->s_iflags & SB_I_ALLOW_HSM))
+ return false;
+
+ return fsnotify_file_object_watched(file, FSNOTIFY_PRE_CONTENT_EVENTS);
+}
and no, NONE of that should be tested at runtime.
I repeat: you should have *ONE* inline function that basically does
static inline bool fsnotify_file_watched(struct file *file)
{
return file && unlikely(file->f_mode & FMODE_NOTIFY_PERM);
}
and absolutely nothing else. If that file is set, the file has
notification events, and you go to an out-of-line slow case. You don't
inline the unlikely cases after that.
And you make sure that you only set that special bit on files and
filesystems that support it. You most definitely don't check for
SB_I_ALLOW_HSM kind of flags at runtime in critical code.
Linus
next prev parent reply other threads:[~2024-11-12 20:12 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-12 17:55 [PATCH v7 00/18] fanotify: add pre-content hooks Josef Bacik
2024-11-12 17:55 ` [PATCH v7 01/18] fsnotify: opt-in for permission events at file_open_perm() time Josef Bacik
2024-11-12 19:45 ` Linus Torvalds
2024-11-12 22:37 ` Amir Goldstein
2024-11-12 17:55 ` [PATCH v7 02/18] fanotify: don't skip extra event info if no info_mode is set Josef Bacik
2024-11-12 17:55 ` [PATCH v7 03/18] fanotify: rename a misnamed constant Josef Bacik
2024-11-12 17:55 ` [PATCH v7 04/18] fanotify: reserve event bit of deprecated FAN_DIR_MODIFY Josef Bacik
2024-11-12 17:55 ` [PATCH v7 05/18] fsnotify: introduce pre-content permission events Josef Bacik
2024-11-12 20:12 ` Linus Torvalds [this message]
2024-11-12 23:06 ` Amir Goldstein
2024-11-12 23:48 ` Linus Torvalds
2024-11-13 0:05 ` Amir Goldstein
2024-11-13 16:57 ` Linus Torvalds
2024-11-13 18:49 ` Amir Goldstein
2024-11-14 15:01 ` Jan Kara
2024-11-14 17:22 ` Amir Goldstein
2024-11-13 0:12 ` Al Viro
2024-11-13 0:23 ` Linus Torvalds
2024-11-13 0:38 ` Linus Torvalds
2024-11-13 1:19 ` Al Viro
2024-11-13 4:30 ` Al Viro
2024-11-13 8:50 ` Amir Goldstein
2024-11-13 14:36 ` Amir Goldstein
2024-11-13 20:31 ` Al Viro
2024-11-13 10:10 ` Christian Brauner
2024-11-20 11:09 ` Christian Brauner
2024-11-20 11:36 ` Amir Goldstein
2024-11-13 19:11 ` Amir Goldstein
2024-11-13 21:22 ` Linus Torvalds
2024-11-13 22:35 ` Amir Goldstein
2024-11-13 23:07 ` Linus Torvalds
2024-11-12 17:55 ` [PATCH v7 06/18] fsnotify: pass optional file access range in pre-content event Josef Bacik
2024-11-12 17:55 ` [PATCH v7 07/18] fsnotify: generate pre-content permission event on open Josef Bacik
2024-11-12 19:54 ` Linus Torvalds
2024-11-12 23:40 ` Amir Goldstein
2024-11-13 0:58 ` Linus Torvalds
2024-11-13 10:12 ` Amir Goldstein
2024-11-12 17:55 ` [PATCH v7 08/18] fsnotify: generate pre-content permission event on truncate Josef Bacik
2024-11-12 17:55 ` [PATCH v7 09/18] fanotify: introduce FAN_PRE_ACCESS permission event Josef Bacik
2024-11-15 11:28 ` Amir Goldstein
2024-11-15 11:47 ` Jan Kara
2024-11-12 17:55 ` [PATCH v7 10/18] fanotify: report file range info with pre-content events Josef Bacik
2024-11-12 17:55 ` [PATCH v7 11/18] fanotify: allow to set errno in FAN_DENY permission response Josef Bacik
2024-11-12 17:55 ` [PATCH v7 12/18] fanotify: add a helper to check for pre content events Josef Bacik
2024-11-13 18:33 ` Amir Goldstein
2024-11-12 17:55 ` [PATCH v7 13/18] fanotify: disable readahead if we have pre-content watches Josef Bacik
2024-11-12 17:55 ` [PATCH v7 14/18] mm: don't allow huge faults for files with pre content watches Josef Bacik
2024-11-12 17:55 ` [PATCH v7 15/18] fsnotify: generate pre-content permission event on page fault Josef Bacik
2024-11-12 17:55 ` [PATCH v7 16/18] xfs: add pre-content fsnotify hook for write faults Josef Bacik
2024-11-12 17:55 ` [PATCH v7 17/18] btrfs: disable defrag on pre-content watched files Josef Bacik
2024-11-12 17:55 ` [PATCH v7 18/18] fs: enable pre-content events on supported file systems Josef Bacik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAHk-=wjkBEch_Z9EMbup2bHtbtt7aoj-o5V6Nara+VxeUtckGw@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=amir73il@gmail.com \
--cc=brauner@kernel.org \
--cc=jack@suse.cz \
--cc=josef@toxicpanda.com \
--cc=kernel-team@fb.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox