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: <CAJnrk1bVZDA9Q8u+9dpAySuaz+JDGdp9AcYyEMLe9zME35Y48g@mail.gmail.com>
Date: Wed, 17 Dec 2025 10:48:27 +0800
From: Joanne Koong <joannelkoong@...il.com>
To: "Darrick J. Wong" <djwong@...nel.org>
Cc: Bernd Schubert <bschubert@....com>, Luis Henriques <luis@...lia.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 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).

Thanks,
Joanne

>
> --D
>
> > Thanks,
> > Joanne
> >
> > >
> > >
> > > Thanks,
> > > Bernd
> >