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

Message-ID: <aXEjX7MD4GzGRvdE@fedora>
Date: Wed, 21 Jan 2026 20:12:49 +0100
From: Horst Birthelmer <horst@...thelmer.de>
To: Bernd Schubert <bschubert@....com>
Cc: Bernd Schubert <bernd@...ernd.com>, Luis Henriques <luis@...lia.com>, 
	Amir Goldstein <amir73il@...il.com>, Miklos Szeredi <miklos@...redi.hu>, 
	"Darrick J. Wong" <djwong@...nel.org>, 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: Re: [RFC PATCH v2 4/6] fuse: implementation of the
 FUSE_LOOKUP_HANDLE operation

On Wed, Jan 21, 2026 at 08:03:32PM +0100, Bernd Schubert wrote:
> 
> 
> On 1/21/26 20:00, Horst Birthelmer wrote:
> > On Wed, Jan 21, 2026 at 07:49:25PM +0100, Bernd Schubert wrote:
> >>
> >>
> > ...
> >>> The problem Luis had was that he cannot construct the second request in the compound correctly
> >>> since he does not have all the in parameters to write complete request.
> >>
> >> What I mean is, the auto-handler of libfuse could complete requests of
> >> the 2nd compound request with those of the 1st request?
> >>
> > With a crazy bunch of flags, we could probably do it, yes.
> > It is way easier that the fuse server treats certain compounds
> > (combination of operations) as a single request and handles
> > those accordingly.
> 
> Hmm, isn't the problem that each fuse server then needs to know those
> common compound combinations? And that makes me wonder, what is the
> difference to an op code then?

I'm pretty sure we both have some examples and counter examples in mind.

Let's implement a couple of the suggested compounds and we will see 
if we can make generic rules. I'm not convinced yet, that we want to
have a generic implementation in libfuse.

The advantage to the 'add an opcode' for every combination 
(and there are already a couple of those) approach is that
you don't need more opcodes, so no changes to the kernel.
You need some code in the fuse server, though, which to me is
fine, since if you have atomic operations implemented there,
why not actually use them.

The big advantage is, choice.

There will be some examples (like the one from Luis)
where you don't actually have a generic choice,
or you create some convention, like you just had in mind.
(put the result of the first operation into the input
of the next ... or into some fields ... etc.)

> 
> 
> Thanks,
> Bernd

Horst