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: <CAJfpegsDL70SZVBKNcdUJcyuf+ifQGuMRy+p80ToUaQFL2aXag@mail.gmail.com>
Date: Wed, 17 Dec 2025 11:08:04 +0100
From: Miklos Szeredi <miklos@...redi.hu>
To: Luis Henriques <luis@...lia.com>
Cc: Joanne Koong <joannelkoong@...il.com>, "Darrick J. Wong" <djwong@...nel.org>, 
	Bernd Schubert <bschubert@....com>, 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, 17 Dec 2025 at 10:38, Luis Henriques <luis@...lia.com> wrote:

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

Yes, I think LOOKUP_HANDLE should supersede LOOKUP.

Which begs the question: do we need nodeid and generation if file
handles are used by the server?

The generation is for guaranteeing uniqueness, and a file handle must
also provide that property, so it is clearly superfluous.

The nodeid is different.  It can be used as a temporary tag for easy
lookup of a cached object (e.g. cast to a pointer).  Since it's
temporary, it can't be embedded in the file handle.

The direct cache reference can be replaced with a hash table lookup
based on the file handle.  This would have an additional advantage,
namely that the lifetime of objects in the user cache are not strictly
synchronized with the kernel cache (FORGET completely omitted, or just
a hint).

Thanks,
Miklos