On Wed, May 15, 2019 at 10:33 PM Jan Kara <jack@xxxxxxx> wrote: > > Proc filesystem has special locking rules for various files. Thus > fanotify which opens files on event delivery can easily deadlock > against another process that waits for fanotify permission event to be > handled. Since permission events on /proc have doubtful value anyway, > just disallow them. > Let's add context: Link: https://lore.kernel.org/linux-fsdevel/20190320131642.GE9485@xxxxxxxxxxxxxx/ > Signed-off-by: Jan Kara <jack@xxxxxxx> > --- > fs/notify/fanotify/fanotify_user.c | 20 ++++++++++++++++++++ > 1 file changed, 20 insertions(+) > > diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c > index a90bb19dcfa2..73719949faa6 100644 > --- a/fs/notify/fanotify/fanotify_user.c > +++ b/fs/notify/fanotify/fanotify_user.c > @@ -920,6 +920,20 @@ static int fanotify_test_fid(struct path *path, __kernel_fsid_t *fsid) > return 0; > } > > +static int fanotify_events_supported(struct path *path, __u64 mask) > +{ > + /* > + * Proc is special and various files have special locking rules so > + * fanotify permission events have high chances of deadlocking the > + * system. Just disallow them. > + */ > + if (mask & FANOTIFY_PERM_EVENTS && > + !strcmp(path->mnt->mnt_sb->s_type->name, "proc")) { Better use an SB_I_ flag to forbid permission events on fs? > + return -EOPNOTSUPP; I would go with EINVAL following precedent of per filesystem flags check on rename(2), but not insisting. Anyway, following Matthew's man page update for FAN_REPORT_FID, we should also add this as reason for EOPNOTSUPP/EINVAL. Thanks, Amir.
