linux-kernel - Re: 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] [day] [month] [year] [list]

Message-ID: <zm53hropvk565xfkjpfy4v2pvgj56pvg37ajm5s4zptjdegdqv@xdbxobdwkimd>
Date: Wed, 17 Dec 2025 19:02:54 +0100
From: Horst Birthelmer <horst@...thelmer.de>
To: Luis Henriques <luis@...lia.com>
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: Re: [RFC PATCH v2 6/6] fuse: implementation of export_operations
 with FUSE_LOOKUP_HANDLE

On Wed, Dec 17, 2025 at 05:02:59PM +0000, Luis Henriques wrote:
> 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.)

Don't worry about it.

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

I get all that. My point was more of a suggestion to not worry too much about
that comparison, since the data size is really limited.
If you know and/or have figured out all the rest, you can think about what exactly
to hash if necessary.

BTW, I really liked your approach, that's why I said that. 
It was more of a general comment than a technical one.

> 
> (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 :-) )
I have read the replies ;-)

Cheers,
Horst