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: <20251217010046.GC7705@frogsfrogsfrogs>
Date: Tue, 16 Dec 2025 17:00:46 -0800
From: "Darrick J. Wong" <djwong@...nel.org>
To: Joanne Koong <joannelkoong@...il.com>
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 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...)

--D

> Thanks,
> Joanne
> 
> >
> >
> > Thanks,
> > Bernd
>