[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241113203112.GI3387508@ZenIV>
Date: Wed, 13 Nov 2024 20:31:12 +0000
From: Al Viro <viro@...iv.linux.org.uk>
To: Amir Goldstein <amir73il@...il.com>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Josef Bacik <josef@...icpanda.com>, kernel-team@...com,
linux-fsdevel@...r.kernel.org, jack@...e.cz, brauner@...nel.org,
linux-xfs@...r.kernel.org, linux-btrfs@...r.kernel.org,
linux-mm@...ck.org, linux-ext4@...r.kernel.org
Subject: Re: [PATCH v7 05/18] fsnotify: introduce pre-content permission
events
On Wed, Nov 13, 2024 at 03:36:33PM +0100, Amir Goldstein wrote:
> I would make this a bit more generic helper and the comment above
> is truly clueless:
>
> /*
> - * we need a new file handle for the userspace program so it
> can read even if it was
> - * originally opened O_WRONLY.
> + * We provide an fd for the userspace program, so it could access the
> + * file without generating fanotify events itself.
> */
> - new_file = dentry_open(path,
> - group->fanotify_data.f_flags | __FMODE_NONOTIFY,
> - current_cred());
> + new_file = dentry_open_fmode(path, group->fanotify_data.f_flags,
> + FMODE_NONOTIFY, current_cred());
Hmm... Not sure I like that, TBH, since that'll lead to temptation to
turn dentry_open() into a wrapper for that thing and I would rather
keep them separate.
> > - fd = anon_inode_getfd("[fanotify]", &fanotify_fops, group, f_flags);
> > + fd = get_unused_fd_flags(flags);
>
> s/flags/f_flags
ACK - thanks for catching that one.
Powered by blists - more mailing lists