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: <87ldhp7wbf.fsf@wotan.olymp>
Date: Thu, 22 Jan 2026 10:53:24 +0000
From: Luis Henriques <luis@...lia.com>
To: Horst Birthelmer <horst@...thelmer.de>
Cc: Bernd Schubert <bschubert@....com>,  Bernd Schubert <bernd@...ernd.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: [RFC PATCH v2 4/6] fuse: implementation of the
 FUSE_LOOKUP_HANDLE operation

On Thu, Jan 22 2026, Horst Birthelmer wrote:

> On Thu, Jan 22, 2026 at 09:52:23AM +0000, Luis Henriques wrote:
>> Hi!
>> 
>> On Wed, Jan 21 2026, Horst Birthelmer wrote:
>> 
>> > 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.
>> 
>> Right, I think that at least the compound requests that can not be
>> serialised (i.e. those that can not be executed using the libfuse helper
>> function fuse_execute_compound_sequential()) should be flagged as such.
>> An extra flag to be set in the request should do the job.
>> 
>> This way, if this flag isn't set in a compound request and the FUSE server
>> doesn't have a compound handle, libfuse could serialise the requests.
>> Otherwise, it would return -ENOTSUPP.
>> 
>> >> 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.)
>> 
>> So, to summarise:
>> 
>> In the end, even FUSE servers that do support compound operations will
>> need to check the operations within a request, and act accordingly.  There
>> will be new combinations that will not be possible to be handle by servers
>> in a generic way: they'll need to return -EOPNOTSUPP if the combination of
>> operations is unknown.  libfuse may then be able to support the
>> serialisation of that specific operation compound.  But that'll require
>> flagging the request as "serialisable".
>
> OK, so this boils down to libfuse trying a bit harder than it does at the moment.
> After it calls the compound handler it should check for EOPNOTSUP and the flag
> and then execute the single requests itself.
>
> At the moment the fuse server implementation itself has to do this.
> Actually the patched passthrough_hp does exactly that.
>
> I think I can live with that.

Well, I was trying to suggest to have, at least for now, as little changes
to libfuse as possible.  Something like this:

	if (req->se->op.compound)
		req->se->op.compound(req, arg->count, arg->flags, in_payload);
	else if (arg->flags & FUSE_COMPOUND_SERIALISABLE)
		fuse_execute_compound_sequential(req);
	else
		fuse_reply_err(req, ENOSYS);

Eventually, support for specific non-serialisable operations could be
added, but that would have to be done for each individual compound.
Obviously, the server itself could also try to serialise the individual
operations in the compound handle, and use the same helper.

Cheers,
-- 
Luís