linux-kernel - Re: [RFC PATCH v2 4/6] fuse: implementation of the FUSE_LOOKUP

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87o6nxoxry.fsf@wotan.olymp>
Date: Wed, 17 Dec 2025 16:53:21 +0000
From: Luis Henriques <luis@...lia.com>
To: Bernd Schubert <bschubert@....com>
Cc: Miklos Szeredi <miklos@...redi.hu>,  Amir Goldstein
 <amir73il@...il.com>,  "Darrick J. Wong" <djwong@...nel.org>,  Kevin Chen
 <kchen@....com>,  Horst Birthelmer <hbirthelmer@....com>,
  "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
  "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,  Matt
 Harvey <mharvey@...ptrading.com>,  "kernel-dev@...lia.com"
 <kernel-dev@...lia.com>
Subject: Re: [RFC PATCH v2 4/6] fuse: implementation of the
 FUSE_LOOKUP_HANDLE operation

On Wed, Dec 17 2025, Bernd Schubert wrote:

> On 12/16/25 12:48, Luis Henriques wrote:
>> On Mon, Dec 15 2025, Bernd Schubert wrote:
>> 
>>> On 12/12/25 19:12, Luis Henriques wrote:
>>>> The implementation of LOOKUP_HANDLE modifies the LOOKUP operation to include
>>>> an extra inarg: the file handle for the parent directory (if it is
>>>> available).  Also, because fuse_entry_out now has a extra variable size
>>>> struct (the actual handle), it also sets the out_argvar flag to true.
>>>>
>>>> Most of the other modifications in this patch are a fallout from these
>>>> changes: because fuse_entry_out has been modified to include a variable size
>>>> struct, every operation that receives such a parameter have to take this
>>>> into account:
>>>>
>>>>    CREATE, LINK, LOOKUP, MKDIR, MKNOD, READDIRPLUS, SYMLINK, TMPFILE
>>>>
>>>> Signed-off-by: Luis Henriques <luis@...lia.com>
>>>> ---
>>>>   fs/fuse/dev.c             | 16 +++++++
>>>>   fs/fuse/dir.c             | 87 ++++++++++++++++++++++++++++++---------
>>>>   fs/fuse/fuse_i.h          | 34 +++++++++++++--
>>>>   fs/fuse/inode.c           | 69 +++++++++++++++++++++++++++----
>>>>   fs/fuse/readdir.c         | 10 ++---
>>>>   include/uapi/linux/fuse.h |  8 ++++
>>>>   6 files changed, 189 insertions(+), 35 deletions(-)
>>>>
>>>> diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
>>>> index 629e8a043079..fc6acf45ae27 100644
>>>> --- a/fs/fuse/dev.c
>>>> +++ b/fs/fuse/dev.c
>>>> @@ -606,6 +606,22 @@ static void fuse_adjust_compat(struct fuse_conn *fc, struct fuse_args *args)
>>>>   	if (fc->minor < 4 && args->opcode == FUSE_STATFS)
>>>>   		args->out_args[0].size = FUSE_COMPAT_STATFS_SIZE;
>>>>   
>>>> +	if (fc->minor < 45) {
>>>
>>> Could we use fc->lookup_handle here? Numbers are hard with backports
>> 
>> To be honest, I'm not sure this code is correct.  I just followed the
>> pattern.  I'll need to dedicate some more time looking into this,
>> specially because the READDIRPLUS op handling is still TBD.
>> 
>> <snip>
>> 
>>>> @@ -505,6 +535,30 @@ struct inode *fuse_iget(struct super_block *sb, u64 nodeid,
>>>>   	if (!inode)
>>>>   		return NULL;
>>>>   
>>>> +	fi = get_fuse_inode(inode);
>>>> +	if (fc->lookup_handle) {
>>>> +		if ((fh == NULL) && (nodeid != FUSE_ROOT_ID)) {
>>>> +			pr_err("NULL file handle for nodeid %llu\n", nodeid);
>>>> +			iput(inode);
>>>> +			return NULL;
>>>
>>> Hmm, so there are conditions like "if (fi && fi->fh) {" in lookup and I
>>> was thinking "nice, fuse-server can decide to skip the fh for some
>>> inodes like FUSE_ROOT_ID. But now it gets forbidden here. In combination
>>> with the other comment in fuse_inode_handle_alloc(), could be allocate
>>> here to the needed size and allow fuse-server to not send the handle
>>> for some files?
>> 
>> I'm not sure the code is consistent with this regard, but here I'm doing
>> exactly that: allowing the fh to be NULL only for FUSE_ROOT_ID.  Or did I
>> misunderstood your comment?
>
> Sorry for late reply.
>
> Yeah sorry, what I meant is that the file handle size might be different
> for any of the inodes, in between 0 and max-size for any of the inodes?

So, as per the other discussion of this patch, Miklos was suggesting the
maximum size negotiation could be totally removed, and the allocation
would be done on-demand [1].  (But probably still keeping an hard limit on
MAX_HANDLE_SZ.)

In that case, different inodes could indeed have different file handle
sizes, defined by the server.  Which would be nice, I guess.

But as I also mentioned in other places, there are already a bunch of
changes, and I need going back to the drawing board :-)

[1] https://lore.kernel.org/all/CAJfpegszP+2XA=vADK4r09KU30BQd-r9sNu2Dog88yLG8iV7WQ@mail.gmail.com

Cheers,
-- 
Luís