On Mon, Jun 17, 2024 at 7:23 PM Jan Kara <jack@xxxxxxx> wrote:
>
> Currently we will not generate FS_OPEN events for O_PATH file
> descriptors but we will generate FS_CLOSE events for them. This is
> asymmetry is confusing. Arguably no fsnotify events should be generated
> for O_PATH file descriptors as they cannot be used to access or modify
> file content, they are just convenient handles to file objects like
> paths. So fix the asymmetry by stopping to generate FS_CLOSE for O_PATH
> file descriptors.
>
> Signed-off-by: Jan Kara <jack@xxxxxxx>
Looks good.
Reviewed-by: Amir Goldstein <amir73il@xxxxxxxxx>
> ---
> include/linux/fsnotify.h | 8 +++++++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/fsnotify.h b/include/linux/fsnotify.h
> index 4da80e92f804..278620e063ab 100644
> --- a/include/linux/fsnotify.h
> +++ b/include/linux/fsnotify.h
> @@ -112,7 +112,13 @@ static inline int fsnotify_file(struct file *file, __u32 mask)
> {
> const struct path *path;
>
> - if (file->f_mode & FMODE_NONOTIFY)
> + /*
> + * FMODE_NONOTIFY are fds generated by fanotify itself which should not
> + * generate new events. We also don't want to generate events for
> + * FMODE_PATH fds (involves open & close events) as they are just
> + * handle creation / destruction events and not "real" file events.
> + */
> + if (file->f_mode & (FMODE_NONOTIFY | FMODE_PATH))
> return 0;
>
> path = &file->f_path;
> --
> 2.35.3
>
