linux-kernel - Re: [RFC PATCH v2 6/6] fuse: implementation of export_operations with 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: <87jyyloxbw.fsf@wotan.olymp>
Date: Wed, 17 Dec 2025 17:02:59 +0000
From: Luis Henriques <luis@...lia.com>
To: Horst Birthelmer <horst@...thelmer.de>
Cc: Miklos Szeredi <miklos@...redi.hu>,  Amir Goldstein
 <amir73il@...il.com>,  "Darrick J. Wong" <djwong@...nel.org>,  Bernd
 Schubert <bschubert@....com>,  Kevin Chen <kchen@....com>,  Horst
 Birthelmer <hbirthelmer@....com>,  linux-fsdevel@...r.kernel.org,
  linux-kernel@...r.kernel.org,  Matt Harvey <mharvey@...ptrading.com>,
  kernel-dev@...lia.com
Subject: Re: [RFC PATCH v2 6/6] fuse: implementation of export_operations
 with FUSE_LOOKUP_HANDLE

On Tue, Dec 16 2025, Horst Birthelmer wrote:

> On Tue, Dec 16, 2025 at 05:06:25PM +0000, Luis Henriques wrote:
>> On Tue, Dec 16 2025, Miklos Szeredi wrote:
> ...
>> >
>> > I think it should be either
>> >
>> >   - encode nodeid + generation (backward compatibility),
>> >
>> >   - or encode file handle for servers that support it
>> >
>> > but not both.
>> 
>> OK, in fact v1 was trying to do something like that, by defining the
>> handle with this:
>> 
>> struct fuse_inode_handle {
>> 	u32 type;
>> 	union {
>> 		struct {
>> 			u64 nodeid;
>> 			u32 generation;
>> 		};
>> 		struct fuse_file_handle fh;
>> 	};
>> };
>> 
>> (The 'type' is likely to be useless, as we know if the server supports fh
>> or not.)
>> 
>> > Which means that fuse_iget() must be able to search the cache based on
>> > the handle as well, but that should not be too difficult to implement
>> > (need to hash the file handle).
>> 
>> Right, I didn't got that far in v1.  I'll see what I can come up to.
>> Doing memcmp()s would definitely be too expensive, so using hashes is the
>> only way I guess.
>> 
> Please excuse my ignorance, but why would memcmp() be too expensive for a proof of concept?
> Inode handles are limited and the cache is somewhat limited.

(Oops, looks like I missed your email.)

So, if every time we're looking for a file handle we need to memcmp() it
with all the handles until we find it (or not!), that would easily be very
expensive if we have a lot of handles cached.  That's what I meant in my
reply, comparing this with an hash-based lookup.

(Not sure I answered your question, as I may have also misunderstood
Miklos suggestions.  It happens quite often!  Just read my replies in this
patchset :-) )

Cheers,
-- 
Luís