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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <87zf6nov6c.fsf@wotan.olymp>
Date: Fri, 09 Jan 2026 11:57:31 +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 4/6] fuse: implementation of the
 FUSE_LOOKUP_HANDLE operation

Hi Miklos,

On Tue, Dec 16 2025, Miklos Szeredi wrote:

> On Fri, 12 Dec 2025 at 19:12, Luis Henriques <luis@...lia.com> 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.
>
> How about adding this as an extension header (FUSE_EXT_HANDLE)?  That
> would allow any operation to take a handle instead of a nodeid.
>
> Yeah, the infrastructure for adding extensions is inadequate, but I
> think the API is ready for this.
>
>> @@ -181,8 +182,24 @@ static void fuse_lookup_init(struct fuse_conn *fc, struct fuse_args *args,
>>         args->in_args[2].size = 1;
>>         args->in_args[2].value = "";
>>         args->out_numargs = 1;
>> -       args->out_args[0].size = sizeof(struct fuse_entry_out);
>> +       args->out_args[0].size = sizeof(*outarg) + outarg->fh.size;
>> +
>> +       if (fc->lookup_handle) {
>> +               struct fuse_inode *fi = NULL;
>> +
>> +               args->opcode = FUSE_LOOKUP_HANDLE;
>> +               args->out_argvar = true;
>
> How about allocating variable length arguments on demand?  That would
> allow getting rid of max_handle_size negotiation.
>
>         args->out_var_alloc  = true;
>         args->out_args[1].size = MAX_HANDLE_SZ;
>         args->out_args[1].value = NULL; /* Will be allocated to the actual size of the handle */

I've been trying to wrap my head around all the suggested changes, and
experimenting with a few options.  Since there are some major things that
need to be modified, I'd like to confirm that I got them right:

1. In the old FUSE_LOOKUP, the args->in_args[0] will continue to use the
   struct fuse_entry_out, which won't be changed and will continue to have
   a static size.

2. FUSE_LOOKUP_HANDLE will add a new out_arg, which will be dynamically
   allocated (using your suggestion: 'args->out_var_alloc').  This will be
   a new struct fuse_entry_handle_out, similar to fuse_entry_out, but
   replacing the struct fuse_attr by a struct fuse_statx, and adding the
   file handle struct.

3. FUSE_LOOKUP_HANDLE will use the args->in_args[0] as an extension header
   (FUSE_EXT_HANDLE).  Note that other operations (e.g. those in function
   create_new_entry()) will actually need to *add* an extra extension
   header, as extension headers are already being used there.
   This extension header will use the new struct fuse_entry_handle_out.

The above items seem to require some heavy changes on my current design.
That's why I'd like to make sure I got those right so that v3 is on the
right path.

Thanks in advance for any feedback!

Cheers,
-- 
Luís