Message-ID: <87h5sd7uu5.fsf@wotan.olymp>
Date: Thu, 22 Jan 2026 11:25:22 +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 10:53:24AM +0000, Luis Henriques wrote:
>> On Thu, Jan 22 2026, Horst Birthelmer wrote:
> ...
>> >> 
>> >> 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.
>> 
>
> Is there a specific reason why you want that change in lowlevel.c?
> The patched passthrouhg_hp does this implicitly, actually without the flag.
> It handles what it knows as 'atomic' compound and uses the helper for the rest.
> If you don't want to handle specific combinations, just check for them 
> and return an error.

Sorry, I have the feeling that I'm starting to bikeshed a bit...

Anyway, I saw the passthrough_hp code, and that's why I thought it would
be easy to just move that into the lowlevel API.  I assumed this would be
a very small change to your current code that would also allow to safely
handle "serialisable" requests in servers that do not have the
->compound() handler.  Obviously, the *big* difference from your code
would be that the kernel would need to flag the non-serialisable requests,
so that user-space would know whether they could handle requests
individually or not.

And another thought I just had (more bikeshedding!) is that if the server
will be allowed to call fuse_execute_compound_sequential(), then this
function would also need to check that flag and return an error if the
request can't be serialisable.

Anyway, I'll stop bothering you now :-)  These comments should probably
have been done in the libfuse PR anyway.

Cheers,
-- 
Luís

Powered by blists - more mailing lists