On Tue 25-04-23 16:01:05, Amir Goldstein wrote: > fanotify users do not always need to decode the file handles reported > with FAN_REPORT_FID. > > Relax the restriction that filesystem needs to support NFS export and > allow reporting file handles from filesystems that only support ecoding > unique file handles. > > For such filesystems, users will have to use the AT_HANDLE_FID of > name_to_handle_at(2) if they want to compare the object in path to the > object fid reported in an event. > > Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx> ... > diff --git a/fs/notify/fanotify/fanotify_user.c b/fs/notify/fanotify/fanotify_user.c > index 8f430bfad487..a5af84cbb30d 100644 > --- a/fs/notify/fanotify/fanotify_user.c > +++ b/fs/notify/fanotify/fanotify_user.c > @@ -1586,11 +1586,9 @@ static int fanotify_test_fid(struct dentry *dentry) > * We need to make sure that the file system supports at least > * encoding a file handle so user can use name_to_handle_at() to > * compare fid returned with event to the file handle of watched > - * objects. However, name_to_handle_at() requires that the > - * filesystem also supports decoding file handles. > + * objects, but it does not need to support decoding file handles. > */ > - if (!dentry->d_sb->s_export_op || > - !dentry->d_sb->s_export_op->fh_to_dentry) > + if (!dentry->d_sb->s_export_op) > return -EOPNOTSUPP; So AFAICS the only thing you require is that s_export_op is set to *something* as exportfs_encode_inode_fh() can deal with NULL ->encode_fh just fine without any filesystem cooperation. What is the reasoning behind the dentry->d_sb->s_export_op check? Is there an implicit expectation that if s_export_op is set to something, the filesystem has sensible i_generation? Or is it just a caution that you don't want the functionality to be enabled for unexpected filesystems? In either case it would be good to capture the reasoning either in a comment or the changelog... Honza -- Jan Kara <jack@xxxxxxxx> SUSE Labs, CR
