Re: Re: [RFC PATCH v2 4/6] fuse: implementation of the FUSE_LOOKUP_HANDLE operation

[Horst Birthelmer <horst@birthelmer.de>]

On Thu, Jan 22, 2026 at 11:25:22AM +0000, Luis Henriques wrote:
> 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.

You are not bothering me at all. I am actually very greatful for those comments
since you are the first user of compounds and that is a very important part.
All the scenarios we clarify now will not bite us later.

I'm still a bit in doubt, that adding that to libfuse will help for all
cases.

> 
> Cheers,
> -- 
> Luís
>