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: <CAJfpegst6oha7-M+8v9cYpk7MR-9k_PZofJ3uzG39DnVoVXMkA@mail.gmail.com>
Date: Fri, 9 Jan 2026 13:38:29 +0100
From: Miklos Szeredi <miklos@...redi.hu>
To: Luis Henriques <luis@...lia.com>
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

On Fri, 9 Jan 2026 at 12:57, Luis Henriques <luis@...lia.com> wrote:

> 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.

Yes.

> 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.

Another idea: let's simplify the interface by removing the attributes
from the lookup reply entirely.  To get back the previous
functionality, compound requests can be used: LOOKUP_HANDLE + STATX.

> 3. FUSE_LOOKUP_HANDLE will use the args->in_args[0] as an extension header

No, extensions go after the regular request data: headers, payload,
extension(s).

We could think about changing that for uring, where it would make
sense to put the extensions after the regular headers, but currently
it doesn't work that way and goes into the payload section.

In any case LOOKUP_HANDLE should follow the existing practice.

>    (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.

Right.

>    This extension header will use the new struct fuse_entry_handle_out.

Why _out?

It should just be a struct fuse_ext_header followed by a struct
fuse_file_handle.

Thanks,
Miklos