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: <87sed9ozg9.fsf@wotan.olymp>
Date: Wed, 17 Dec 2025 16:17:10 +0000
From: Luis Henriques <luis@...lia.com>
To: Miklos Szeredi <miklos@...redi.hu>
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, Dec 17 2025, Miklos Szeredi wrote:

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

Ack.

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

OK, this will require some more (or a lot more!) thinking from my side.
There are already several big(ish) suggestions I've started looking into,
and I need to go through them again.  Slowly ;-)

It's not clear to me at this point how to keep using nodeid+gen for
backward compatibility and replacing it by an hash table for the new
operation.  At first, it looks like a lot of code complexity will be
required for that.  But as I said, I'll need to go back and start
experimenting.

Other big change is to use fuse_ext_header instead of a variable size arg:
sounds interesting but will require more experimentation.  So, time for
going back to the drawing board!

Cheers,
-- 
Luís