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: <87ike5xxbd.fsf@wotan.olymp>
Date: Wed, 17 Dec 2025 09:38:30 +0000
From: Luis Henriques <luis@...lia.com>
To: Joanne Koong <joannelkoong@...il.com>
Cc: "Darrick J. Wong" <djwong@...nel.org>,  Bernd Schubert
 <bschubert@....com>,  Miklos Szeredi <miklos@...redi.hu>,  Amir Goldstein
 <amir73il@...il.com>,  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, Joanne Koong wrote:

> On Wed, Dec 17, 2025 at 9:00 AM Darrick J. Wong <djwong@...nel.org> wrote:
>>
>> On Wed, Dec 17, 2025 at 08:32:02AM +0800, Joanne Koong wrote:
>> > On Tue, Dec 16, 2025 at 4:54 PM Bernd Schubert <bschubert@....com> wrote:
>> > >
>> > > On 12/16/25 09:49, Joanne Koong wrote:
>> > > > On Sat, Dec 13, 2025 at 2:14 AM 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.
>> > > >>
>> > > >> 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(-)
>> > > >>
>> > > >
>> > > > Could you explain why the file handle size needs to be dynamically set
>> > > > by the server instead of just from the kernel-side stipulating that
>> > > > the file handle size is FUSE_HANDLE_SZ (eg 128 bytes)? It seems to me
>> > > > like that would simplify a lot of the code logic here.
>> > >
>> > > It would be quite a waste if one only needs something like 12 or 16
>> > > bytes, wouldn't it? 128 is the upper limit, but most file systems won't
>> > > need that much.
>> >
>> > Ah, I was looking at patch 5 + 6 and thought the use of the lookup
>> > handle was for servers that want to pass it to NFS. But just read
>> > through the previous threads and see now it's for adding server
>> > restart. That makes sense, thanks for clarifying.
>>
>> <-- wakes up from his long slumber
>>
>> Why wouldn't you use the same handle format for NFS and for fuse server
>> restarts?  I would think that having separate formats would cause type
>> confusion and friction.
>>
>> But that said, the fs implementation (fuse server) gets to decide the
>> handle format it uses, because they're just binary blobcookies to the
>> clients.  I think that's why the size is variable.
>>
>> (Also I might be missing some context, if fuse handles aren't used in
>> the same places as nfs handles...)
>
> I think the fuse server would use the same NFS handle format if it
> needs to pass it to NFS but with the server restart stuff, the handle
> will also be used generically by servers that don't need to interact
> with NFS (or at least that's my understanding of it though I might be
> missing some context here too).

That is correct: the handle is to be used both by new FUSE lookup
operation, and by the NFS.  If the FUSE server does not implement this
LOOKUP_HANDLE operation (only the LOOKUP), then the old NFS handle
(nodeid+gen) is used instead.

(A question that just appeared in my mind is whether the two lookup
operations should be exclusive, i.e. if the kernel should explicitly avoid
sending a LOOKUP to a server that implements LOOKUP_HANDLE and vice-versa.
I _think_ the current implementation currently does this, but that was
mostly by accident.)

The relation of all this to the server restartability is that this new
handle will (eventually!) allow a server to recover a connection/mount
because it has to be a unique identifier (as opposed to the nodeid, which
can be reused).  But other use-cases have been mentioned, such as the
usage of open_by_handle_at() for example.

Cheers,
-- 
Luís