Re: [PATCH v3 08/13] fanotify: enable FAN_REPORT_FID init flag

[Jan Kara <jack@suse.cz>]

On Thu 29-11-18 10:46:36, Jan Kara wrote:
> On Sun 25-11-18 15:43:47, Amir Goldstein wrote:
> > When setting up an fanotify listener, user may request to get fid
> > information in event instead of an open file descriptor.
> > 
> > The fid obtained with event on a watched object contains the file
> > handle returned by name_to_handle_at(2) and fsid returned by statfs(2).
> > 
> > When setting a mark, we need to make sure that the filesystem
> > supports encoding file handles with name_to_handle_at(2) and that
> > statfs(2) encodes a non-zero fsid.
> ...
> > diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c
> > index ea8e81a3e80b..d7aa2f392a64 100644
> > --- a/fs/notify/fanotify/fanotify_user.c
> > +++ b/fs/notify/fanotify/fanotify_user.c
> > @@ -857,6 +859,49 @@ SYSCALL_DEFINE2(fanotify_init, unsigned int, flags, unsigned int, event_f_flags)
> >  	return fd;
> >  }
> >  
> > +/* Check if filesystem can encode a unique fid */
> > +static int fanotify_test_fid(struct path *path)
> > +{
> > +	struct kstatfs stat, root_stat;
> > +	int err;
> > +
> > +	/*
> > +	 * Make sure path is not in filesystem with zero fsid (e.g. tmpfs).
> > +	 * TODO: cache fsid in the mark connector.
> > +	 */
> 
> TODO in a submitted patch looks strange (looks like the patch isn't done
> yet ;)) and in this particular case the code is perfectly justified even
> without talking about future functionality...
> 
> > +	err = vfs_statfs(path, &stat);
> > +	if (err)
> > +		return err;
> > +
> > +	if (!stat.f_fsid.val[0] && !stat.f_fsid.val[1])
> > +		return -ENODEV;
> > +
> > +	/*
> > +	 * Make sure path is not inside a filesystem subvolume (e.g. btrfs)
> > +	 * which uses a different fsid than sb root.
> > +	 */
> > +	err = statfs_by_dentry(path->dentry->d_sb->s_root, &root_stat);
> > +	if (err)
> > +		return err;
> > +
> > +	if (root_stat.f_fsid.val[0] != stat.f_fsid.val[0] ||
> > +	    root_stat.f_fsid.val[1] != stat.f_fsid.val[1])
> > +		return -EXDEV;
> 
> I think inode watches in subvolumes are actually fine? The same fs object
> is going to get different struct inode for different subvolumes if I
> remember right. So there won't be any surprises with unexpected fsid being
> reported.
> 
> Also mount watches are actually fine for subvolume as different subvolumes
> appear as different mountpoints, don't they? And I think implementation
> that would have different fsid for inodes in the same mountpoint would be
> indeed very weird. So again no problem with fsid mismatch.
> 
> So we need this check only for superblock watches.

See my reply to the next patch for more on this. Also I was thinking about
the "no zero fsid" restriction. I understand where you are coming from but
IMO FAN_REPORT_FID can be useful even if the filesystem doesn't support
fsid - e.g. if you create a notification group and put there marks  only for
one filesystem, then you don't need the fsid part at all. I don't have a
strong opinion on this (we can always enable this functionality later if we
want) but wanted to run this by you.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR