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] [thread-next>] [day] [month] [year] [list]

Message-ID: <b3ygfin4h2v64fs2cup2fu5pux7skm7nby7nhostqo7ejgbw2r@zvr6yre5vr57>
Date: Tue, 16 Dec 2025 21:12:46 +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 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.

Cheers,
Horst