Re: [RFC][PATCH 4/4] fanotify: support reporting non-decodeable file handles

[Jan Kara <jack@suse.cz>]

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@gmail.com>
...
> 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@suse.com>
SUSE Labs, CR