Re: [RFC PATCH v2 6/6] fuse: implementation of export_operations with FUSE_LOOKUP_HANDLE

[Luis Henriques]

On Tue, Dec 16 2025, Miklos Szeredi wrote:

> On Fri, 12 Dec 2025 at 19:13, Luis Henriques <luis@xxxxxxxxxx> wrote:
>>
>> This patch allows the NFS handle to use the new file handle provided by the
>> LOOKUP_HANDLE operation.  It still allows the usage of nodeid+generation as
>> an handle if this operation is not supported by the FUSE server or if no
>> handle is available for a specific inode.  I.e. it can mix both file handle
>> types FILEID_INO64_GEN{_PARENT} and FILEID_FUSE_WITH{OUT}_PARENT.
>>
>> Signed-off-by: Luis Henriques <luis@xxxxxxxxxx>
>> ---
>>  fs/fuse/export.c         | 162 ++++++++++++++++++++++++++++++++++++---
>>  include/linux/exportfs.h |   7 ++
>>  2 files changed, 160 insertions(+), 9 deletions(-)
>>
>> diff --git a/fs/fuse/export.c b/fs/fuse/export.c
>> index 4a9c95fe578e..b40d146a32f2 100644
>> --- a/fs/fuse/export.c
>> +++ b/fs/fuse/export.c
>> @@ -3,6 +3,7 @@
>>   * FUSE NFS export support.
>>   *
>>   * Copyright (C) 2001-2008  Miklos Szeredi <miklos@xxxxxxxxxx>
>> + * Copyright (C) 2025 Jump Trading LLC, author: Luis Henriques <luis@xxxxxxxxxx>
>>   */
>>
>>  #include "fuse_i.h"
>> @@ -10,7 +11,8 @@
>>
>>  struct fuse_inode_handle {
>>         u64 nodeid;
>> -       u32 generation;
>> +       u32 generation; /* XXX change to u64, and use fid->i64.ino in encode/decode? */
>> +       struct fuse_file_handle fh;
>>  };
>>
>>  static struct dentry *fuse_get_dentry(struct super_block *sb,
>> @@ -67,8 +69,8 @@ static struct dentry *fuse_get_dentry(struct super_block *sb,
>>         return ERR_PTR(err);
>>  }
>>
>> -static int fuse_encode_fh(struct inode *inode, u32 *fh, int *max_len,
>> -                          struct inode *parent)
>> +static int fuse_encode_gen_fh(struct inode *inode, u32 *fh, int *max_len,
>> +                             struct inode *parent)
>>  {
>>         int len = parent ? 6 : 3;
>>         u64 nodeid;
>> @@ -96,38 +98,180 @@ static int fuse_encode_fh(struct inode *inode, u32 *fh, int *max_len,
>>         }
>>
>>         *max_len = len;
>> +
>>         return parent ? FILEID_INO64_GEN_PARENT : FILEID_INO64_GEN;
>>  }
>>
>> -static struct dentry *fuse_fh_to_dentry(struct super_block *sb,
>> -               struct fid *fid, int fh_len, int fh_type)
>> +static int fuse_encode_fuse_fh(struct inode *inode, u32 *fh, int *max_len,
>> +                              struct inode *parent)
>> +{
>> +       struct fuse_inode *fi = get_fuse_inode(inode);
>> +       struct fuse_inode *fip = NULL;
>> +       struct fuse_inode_handle *handle = (void *)fh;
>> +       int type = FILEID_FUSE_WITHOUT_PARENT;
>> +       int len, lenp = 0;
>> +       int buflen = *max_len << 2; /* max_len: number of words */
>> +
>> +       len = sizeof(struct fuse_inode_handle) + fi->fh->size;
>> +       if (parent) {
>> +               fip = get_fuse_inode(parent);
>> +               if (fip->fh && fip->fh->size) {
>> +                       lenp = sizeof(struct fuse_inode_handle) +
>> +                               fip->fh->size;
>> +                       type = FILEID_FUSE_WITH_PARENT;
>> +               }
>> +       }
>> +
>> +       if (buflen < (len + lenp)) {
>> +               *max_len = (len + lenp) >> 2;
>> +               return  FILEID_INVALID;
>> +       }
>> +
>> +       handle[0].nodeid = fi->nodeid;
>> +       handle[0].generation = inode->i_generation;
>
> I think it should be either
>
>   - encode nodeid + generation (backward compatibility),
>
>   - or encode file handle for servers that support it
>
> but not both.

OK, in fact v1 was trying to do something like that, by defining the
handle with this:

struct fuse_inode_handle {
	u32 type;
	union {
		struct {
			u64 nodeid;
			u32 generation;
		};
		struct fuse_file_handle fh;
	};
};

(The 'type' is likely to be useless, as we know if the server supports fh
or not.)

> Which means that fuse_iget() must be able to search the cache based on
> the handle as well, but that should not be too difficult to implement
> (need to hash the file handle).

Right, I didn't got that far in v1.  I'll see what I can come up to.
Doing memcmp()s would definitely be too expensive, so using hashes is the
only way I guess.

Cheers,
-- 
Luís