[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <874ipqcq5q.fsf@wotan.olymp>
Date: Tue, 16 Dec 2025 17:06:25 +0000
From: Luis Henriques <luis@...lia.com>
To: Miklos Szeredi <miklos@...redi.hu>
Cc: Amir Goldstein <amir73il@...il.com>, "Darrick J. Wong"
<djwong@...nel.org>, Bernd Schubert <bschubert@....com>, Kevin Chen
<kchen@....com>, Horst Birthelmer <hbirthelmer@....com>,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org, Matt
Harvey <mharvey@...ptrading.com>, kernel-dev@...lia.com
Subject: Re: [RFC PATCH v2 6/6] fuse: implementation of export_operations
with FUSE_LOOKUP_HANDLE
On Tue, Dec 16 2025, Miklos Szeredi wrote:
> On Fri, 12 Dec 2025 at 19:13, Luis Henriques <luis@...lia.com> 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@...lia.com>
>> ---
>> 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@...redi.hu>
>> + * Copyright (C) 2025 Jump Trading LLC, author: Luis Henriques <luis@...lia.com>
>> */
>>
>> #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
Powered by blists - more mailing lists