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

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

[Luis Henriques]

Hi Horst!

On Fri, Jan 09 2026, Horst Birthelmer wrote:

> On Fri, Jan 09, 2026 at 07:12:41PM +0000, Bernd Schubert wrote:
>> On 1/9/26 19:29, Amir Goldstein wrote:
>> > On Fri, Jan 9, 2026 at 4:56 PM Bernd Schubert <bschubert@ddn.com> wrote:
>> >>
>> >>
>> >>
>> >> On 1/9/26 16:37, Miklos Szeredi wrote:
>> >>> On Fri, 9 Jan 2026 at 16:03, Amir Goldstein <amir73il@gmail.com> wrote:
>> >>>
>> >>>> What about FUSE_CREATE? FUSE_TMPFILE?
>> >>>
>> >>> FUSE_CREATE could be decomposed to FUSE_MKOBJ_H + FUSE_STATX + FUSE_OPEN.
>> >>>
>> >>> FUSE_TMPFILE is special, the create and open needs to be atomic.   So
>> >>> the best we can do is FUSE_TMPFILE_H + FUSE_STATX.
>> >>>
>> > 
>> > I thought that the idea of FUSE_CREATE is that it is atomic_open()
>> > is it not?
>> > If we decompose that to FUSE_MKOBJ_H + FUSE_STATX + FUSE_OPEN
>> > it won't be atomic on the server, would it?
>> 
>> Horst just posted the libfuse PR for compounds
>> https://github.com/libfuse/libfuse/pull/1418
>> 
>> You can make it atomic on the libfuse side with the compound
>> implementation. I.e. you have the option leave it to libfuse to handle
>> compound by compound as individual requests, or you handle the compound
>> yourself as one request.
>> 
>> I think we need to create an example with self handling of the compound,
>> even if it is just to ensure that we didn't miss anything in design.
>
> I actually do have an example that would be suitable.
> I could implement the LOOKUP+CREATE as a pseudo atomic operation in passthrough_hp.

So, I've been working on getting an implementation of LOOKUP_HANDLE+STATX.
And I would like to hear your opinion on a problem I found:

If the kernel is doing a LOOKUP, you'll send the parent directory nodeid
in the request args.  On the other hand, the nodeid for a STATX will be
the nodeid will be for the actual inode being statx'ed.

The problem is that when merging both requests into a compound request,
you don't have the nodeid for the STATX.  I've "fixed" this by passing in
FUSE_ROOT_ID and hacking user-space to work around it: if the lookup
succeeds, we have the correct nodeid for the STATX.  That seems to work
fine for my case, where the server handles the compound request itself.
But from what I understand libfuse can also handle it as individual
requests, and in this case the server wouldn't know the right nodeid for
the STATX.

Obviously, the same problem will need to be solved for other operations
(for example for FUSE_CREATE where we'll need to do a FUSE_MKOBJ_H +
FUSE_STATX + FUSE_OPEN).

I guess this can eventually be fixed in libfuse, by updating the nodeid in
this case.  Another solution is to not allow these sort of operations to
be handled individually.  But maybe I'm just being dense and there's a
better solution for this.

Cheers,
-- 
Luís

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

[Horst Birthelmer]

Hi Luis,

On Wed, Jan 21, 2026 at 05:56:12PM +0000, Luis Henriques wrote:
> Hi Horst!
> 
> On Fri, Jan 09 2026, Horst Birthelmer wrote:
> 
> > On Fri, Jan 09, 2026 at 07:12:41PM +0000, Bernd Schubert wrote:
> >> On 1/9/26 19:29, Amir Goldstein wrote:
> >> > On Fri, Jan 9, 2026 at 4:56 PM Bernd Schubert <bschubert@ddn.com> wrote:
> >> >>
> >> >>
> >> >>
> >> >> On 1/9/26 16:37, Miklos Szeredi wrote:
> >> >>> On Fri, 9 Jan 2026 at 16:03, Amir Goldstein <amir73il@gmail.com> wrote:
> >> >>>
> >> >>>> What about FUSE_CREATE? FUSE_TMPFILE?
> >> >>>
> >> >>> FUSE_CREATE could be decomposed to FUSE_MKOBJ_H + FUSE_STATX + FUSE_OPEN.
> >> >>>
> >> >>> FUSE_TMPFILE is special, the create and open needs to be atomic.   So
> >> >>> the best we can do is FUSE_TMPFILE_H + FUSE_STATX.
> >> >>>
> >> > 
> >> > I thought that the idea of FUSE_CREATE is that it is atomic_open()
> >> > is it not?
> >> > If we decompose that to FUSE_MKOBJ_H + FUSE_STATX + FUSE_OPEN
> >> > it won't be atomic on the server, would it?
> >> 
> >> Horst just posted the libfuse PR for compounds
> >> https://github.com/libfuse/libfuse/pull/1418
> >> 
> >> You can make it atomic on the libfuse side with the compound
> >> implementation. I.e. you have the option leave it to libfuse to handle
> >> compound by compound as individual requests, or you handle the compound
> >> yourself as one request.
> >> 
> >> I think we need to create an example with self handling of the compound,
> >> even if it is just to ensure that we didn't miss anything in design.
> >
> > I actually do have an example that would be suitable.
> > I could implement the LOOKUP+CREATE as a pseudo atomic operation in passthrough_hp.
> 
> So, I've been working on getting an implementation of LOOKUP_HANDLE+STATX.
> And I would like to hear your opinion on a problem I found:
> 
> If the kernel is doing a LOOKUP, you'll send the parent directory nodeid
> in the request args.  On the other hand, the nodeid for a STATX will be
> the nodeid will be for the actual inode being statx'ed.
> 
> The problem is that when merging both requests into a compound request,
> you don't have the nodeid for the STATX.  I've "fixed" this by passing in
> FUSE_ROOT_ID and hacking user-space to work around it: if the lookup
> succeeds, we have the correct nodeid for the STATX.  That seems to work
> fine for my case, where the server handles the compound request itself.
> But from what I understand libfuse can also handle it as individual
> requests, and in this case the server wouldn't know the right nodeid for
> the STATX.
> 
> Obviously, the same problem will need to be solved for other operations
> (for example for FUSE_CREATE where we'll need to do a FUSE_MKOBJ_H +
> FUSE_STATX + FUSE_OPEN).
> 
> I guess this can eventually be fixed in libfuse, by updating the nodeid in
> this case.  Another solution is to not allow these sort of operations to
> be handled individually.  But maybe I'm just being dense and there's a
> better solution for this.
> 

You have come across a problem, that I have come across, too, during my experiments. 
I think that makes it a rather common problem when creating compounds.

This can only be solved by convention and it is the reason why I have disabled the default
handling of compounds in libfuse. Bernd actually wanted to do that automatically, but I think
that is too risky for exactly the reason you have found.

The fuse server has to decide if it wants to handle the compound as such or as a
bunch of single requests.

At the moment I think it is best to just not use the libfuse single request handling 
of the compound where it is not possible. 
As my passthrough_hp shows, you can handle certain compounds as a compound where you know all the information
(like some lookup, you just did in the fuse server) and leave the 'trivial' ones to the lib.

We could actually pass 'one' id in the 'in header' of the compound as some sort of global parent 
but that would be another convention that the fuse server has to know and keep.

> Cheers,
> -- 
> Luís

Horst

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

[Bernd Schubert]

On 1/21/26 19:16, Horst Birthelmer wrote:
> Hi Luis,
> 
> On Wed, Jan 21, 2026 at 05:56:12PM +0000, Luis Henriques wrote:
>> Hi Horst!
>>
>> On Fri, Jan 09 2026, Horst Birthelmer wrote:
>>
>>> On Fri, Jan 09, 2026 at 07:12:41PM +0000, Bernd Schubert wrote:
>>>> On 1/9/26 19:29, Amir Goldstein wrote:
>>>>> On Fri, Jan 9, 2026 at 4:56 PM Bernd Schubert <bschubert@ddn.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 1/9/26 16:37, Miklos Szeredi wrote:
>>>>>>> On Fri, 9 Jan 2026 at 16:03, Amir Goldstein <amir73il@gmail.com> wrote:
>>>>>>>
>>>>>>>> What about FUSE_CREATE? FUSE_TMPFILE?
>>>>>>>
>>>>>>> FUSE_CREATE could be decomposed to FUSE_MKOBJ_H + FUSE_STATX + FUSE_OPEN.
>>>>>>>
>>>>>>> FUSE_TMPFILE is special, the create and open needs to be atomic.   So
>>>>>>> the best we can do is FUSE_TMPFILE_H + FUSE_STATX.
>>>>>>>
>>>>>
>>>>> I thought that the idea of FUSE_CREATE is that it is atomic_open()
>>>>> is it not?
>>>>> If we decompose that to FUSE_MKOBJ_H + FUSE_STATX + FUSE_OPEN
>>>>> it won't be atomic on the server, would it?
>>>>
>>>> Horst just posted the libfuse PR for compounds
>>>> https://github.com/libfuse/libfuse/pull/1418
>>>>
>>>> You can make it atomic on the libfuse side with the compound
>>>> implementation. I.e. you have the option leave it to libfuse to handle
>>>> compound by compound as individual requests, or you handle the compound
>>>> yourself as one request.
>>>>
>>>> I think we need to create an example with self handling of the compound,
>>>> even if it is just to ensure that we didn't miss anything in design.
>>>
>>> I actually do have an example that would be suitable.
>>> I could implement the LOOKUP+CREATE as a pseudo atomic operation in passthrough_hp.
>>
>> So, I've been working on getting an implementation of LOOKUP_HANDLE+STATX.
>> And I would like to hear your opinion on a problem I found:
>>
>> If the kernel is doing a LOOKUP, you'll send the parent directory nodeid
>> in the request args.  On the other hand, the nodeid for a STATX will be
>> the nodeid will be for the actual inode being statx'ed.
>>
>> The problem is that when merging both requests into a compound request,
>> you don't have the nodeid for the STATX.  I've "fixed" this by passing in
>> FUSE_ROOT_ID and hacking user-space to work around it: if the lookup
>> succeeds, we have the correct nodeid for the STATX.  That seems to work
>> fine for my case, where the server handles the compound request itself.
>> But from what I understand libfuse can also handle it as individual
>> requests, and in this case the server wouldn't know the right nodeid for
>> the STATX.
>>
>> Obviously, the same problem will need to be solved for other operations
>> (for example for FUSE_CREATE where we'll need to do a FUSE_MKOBJ_H +
>> FUSE_STATX + FUSE_OPEN).
>>
>> I guess this can eventually be fixed in libfuse, by updating the nodeid in
>> this case.  Another solution is to not allow these sort of operations to
>> be handled individually.  But maybe I'm just being dense and there's a
>> better solution for this.
>>
> 
> You have come across a problem, that I have come across, too, during my experiments. 
> I think that makes it a rather common problem when creating compounds.
> 
> This can only be solved by convention and it is the reason why I have disabled the default
> handling of compounds in libfuse. Bernd actually wanted to do that automatically, but I think
> that is too risky for exactly the reason you have found.
> 
> The fuse server has to decide if it wants to handle the compound as such or as a
> bunch of single requests.

Idea was actually to pass compounds to the daemon if it has a compound
handler, if not to handle it automatically. Now for open+getattr
fuse-server actually not want the additional getattr - cannot be handle
automatically. But for lookup+stat and others like this, if fuse server
server does not know how to handle the entire compound, libfuse could
still do it correctly, i.e. have its own handler for known compounds?

> 
> At the moment I think it is best to just not use the libfuse single request handling 
> of the compound where it is not possible. 
> As my passthrough_hp shows, you can handle certain compounds as a compound where you know all the information
> (like some lookup, you just did in the fuse server) and leave the 'trivial' ones to the lib.
> 
> We could actually pass 'one' id in the 'in header' of the compound as some sort of global parent 
> but that would be another convention that the fuse server has to know and keep.
> 


Thanks,
Bernd

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

[Horst Birthelmer]

On Wed, Jan 21, 2026 at 07:28:43PM +0100, Bernd Schubert wrote:
> On 1/21/26 19:16, Horst Birthelmer wrote:
> > Hi Luis,
> > 
> > On Wed, Jan 21, 2026 at 05:56:12PM +0000, Luis Henriques wrote:
> >> Hi Horst!
> >>
> >> On Fri, Jan 09 2026, Horst Birthelmer wrote:
> >>
> >>> On Fri, Jan 09, 2026 at 07:12:41PM +0000, Bernd Schubert wrote:
> >>>> On 1/9/26 19:29, Amir Goldstein wrote:
> >>>>> On Fri, Jan 9, 2026 at 4:56 PM Bernd Schubert <bschubert@ddn.com> wrote:
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 1/9/26 16:37, Miklos Szeredi wrote:
> >>>>>>> On Fri, 9 Jan 2026 at 16:03, Amir Goldstein <amir73il@gmail.com> wrote:
> >>>>>>>
> >>>>>>>> What about FUSE_CREATE? FUSE_TMPFILE?
> >>>>>>>
> >>>>>>> FUSE_CREATE could be decomposed to FUSE_MKOBJ_H + FUSE_STATX + FUSE_OPEN.
> >>>>>>>
> >>>>>>> FUSE_TMPFILE is special, the create and open needs to be atomic.   So
> >>>>>>> the best we can do is FUSE_TMPFILE_H + FUSE_STATX.
> >>>>>>>
> >>>>>
> >>>>> I thought that the idea of FUSE_CREATE is that it is atomic_open()
> >>>>> is it not?
> >>>>> If we decompose that to FUSE_MKOBJ_H + FUSE_STATX + FUSE_OPEN
> >>>>> it won't be atomic on the server, would it?
> >>>>
> >>>> Horst just posted the libfuse PR for compounds
> >>>> https://github.com/libfuse/libfuse/pull/1418
> >>>>
> >>>> You can make it atomic on the libfuse side with the compound
> >>>> implementation. I.e. you have the option leave it to libfuse to handle
> >>>> compound by compound as individual requests, or you handle the compound
> >>>> yourself as one request.
> >>>>
> >>>> I think we need to create an example with self handling of the compound,
> >>>> even if it is just to ensure that we didn't miss anything in design.
> >>>
> >>> I actually do have an example that would be suitable.
> >>> I could implement the LOOKUP+CREATE as a pseudo atomic operation in passthrough_hp.
> >>
> >> So, I've been working on getting an implementation of LOOKUP_HANDLE+STATX.
> >> And I would like to hear your opinion on a problem I found:
> >>
> >> If the kernel is doing a LOOKUP, you'll send the parent directory nodeid
> >> in the request args.  On the other hand, the nodeid for a STATX will be
> >> the nodeid will be for the actual inode being statx'ed.
> >>
> >> The problem is that when merging both requests into a compound request,
> >> you don't have the nodeid for the STATX.  I've "fixed" this by passing in
> >> FUSE_ROOT_ID and hacking user-space to work around it: if the lookup
> >> succeeds, we have the correct nodeid for the STATX.  That seems to work
> >> fine for my case, where the server handles the compound request itself.
> >> But from what I understand libfuse can also handle it as individual
> >> requests, and in this case the server wouldn't know the right nodeid for
> >> the STATX.
> >>
> >> Obviously, the same problem will need to be solved for other operations
> >> (for example for FUSE_CREATE where we'll need to do a FUSE_MKOBJ_H +
> >> FUSE_STATX + FUSE_OPEN).
> >>
> >> I guess this can eventually be fixed in libfuse, by updating the nodeid in
> >> this case.  Another solution is to not allow these sort of operations to
> >> be handled individually.  But maybe I'm just being dense and there's a
> >> better solution for this.
> >>
> > 
> > You have come across a problem, that I have come across, too, during my experiments. 
> > I think that makes it a rather common problem when creating compounds.
> > 
> > This can only be solved by convention and it is the reason why I have disabled the default
> > handling of compounds in libfuse. Bernd actually wanted to do that automatically, but I think
> > that is too risky for exactly the reason you have found.
> > 
> > The fuse server has to decide if it wants to handle the compound as such or as a
> > bunch of single requests.
> 
> Idea was actually to pass compounds to the daemon if it has a compound
> handler, if not to handle it automatically. Now for open+getattr
> fuse-server actually not want the additional getattr - cannot be handle
> automatically. But for lookup+stat and others like this, if fuse server
> server does not know how to handle the entire compound, libfuse could
> still do it correctly, i.e. have its own handler for known compounds?

We could definitely provide a library of compounds that we 'know' in libfuse,
of course. No argument there.

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.

BTW, I forgot in my last mail to say that we have another problem, where we need 
some sort of convention where we will bang our heads sooner or later.
If the fuse server does not support the given compound it should 
return EOPNOTSUP in my opinion.
IIRC this is not implemented correctly so far.

> 
> > 
> > At the moment I think it is best to just not use the libfuse single request handling 
> > of the compound where it is not possible. 
> > As my passthrough_hp shows, you can handle certain compounds as a compound where you know all the information
> > (like some lookup, you just did in the fuse server) and leave the 'trivial' ones to the lib.
> > 
> > We could actually pass 'one' id in the 'in header' of the compound as some sort of global parent 
> > but that would be another convention that the fuse server has to know and keep.
> > 
> 
> 
> Thanks,
> Bernd

Horst

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

[Bernd Schubert]

On 1/21/26 19:36, Horst Birthelmer wrote:
> On Wed, Jan 21, 2026 at 07:28:43PM +0100, Bernd Schubert wrote:
>> On 1/21/26 19:16, Horst Birthelmer wrote:
>>> Hi Luis,
>>>
>>> On Wed, Jan 21, 2026 at 05:56:12PM +0000, Luis Henriques wrote:
>>>> Hi Horst!
>>>>
>>>> On Fri, Jan 09 2026, Horst Birthelmer wrote:
>>>>
>>>>> On Fri, Jan 09, 2026 at 07:12:41PM +0000, Bernd Schubert wrote:
>>>>>> On 1/9/26 19:29, Amir Goldstein wrote:
>>>>>>> On Fri, Jan 9, 2026 at 4:56 PM Bernd Schubert <bschubert@ddn.com> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 1/9/26 16:37, Miklos Szeredi wrote:
>>>>>>>>> On Fri, 9 Jan 2026 at 16:03, Amir Goldstein <amir73il@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>>> What about FUSE_CREATE? FUSE_TMPFILE?
>>>>>>>>>
>>>>>>>>> FUSE_CREATE could be decomposed to FUSE_MKOBJ_H + FUSE_STATX + FUSE_OPEN.
>>>>>>>>>
>>>>>>>>> FUSE_TMPFILE is special, the create and open needs to be atomic.   So
>>>>>>>>> the best we can do is FUSE_TMPFILE_H + FUSE_STATX.
>>>>>>>>>
>>>>>>>
>>>>>>> I thought that the idea of FUSE_CREATE is that it is atomic_open()
>>>>>>> is it not?
>>>>>>> If we decompose that to FUSE_MKOBJ_H + FUSE_STATX + FUSE_OPEN
>>>>>>> it won't be atomic on the server, would it?
>>>>>>
>>>>>> Horst just posted the libfuse PR for compounds
>>>>>> https://github.com/libfuse/libfuse/pull/1418
>>>>>>
>>>>>> You can make it atomic on the libfuse side with the compound
>>>>>> implementation. I.e. you have the option leave it to libfuse to handle
>>>>>> compound by compound as individual requests, or you handle the compound
>>>>>> yourself as one request.
>>>>>>
>>>>>> I think we need to create an example with self handling of the compound,
>>>>>> even if it is just to ensure that we didn't miss anything in design.
>>>>>
>>>>> I actually do have an example that would be suitable.
>>>>> I could implement the LOOKUP+CREATE as a pseudo atomic operation in passthrough_hp.
>>>>
>>>> So, I've been working on getting an implementation of LOOKUP_HANDLE+STATX.
>>>> And I would like to hear your opinion on a problem I found:
>>>>
>>>> If the kernel is doing a LOOKUP, you'll send the parent directory nodeid
>>>> in the request args.  On the other hand, the nodeid for a STATX will be
>>>> the nodeid will be for the actual inode being statx'ed.
>>>>
>>>> The problem is that when merging both requests into a compound request,
>>>> you don't have the nodeid for the STATX.  I've "fixed" this by passing in
>>>> FUSE_ROOT_ID and hacking user-space to work around it: if the lookup
>>>> succeeds, we have the correct nodeid for the STATX.  That seems to work
>>>> fine for my case, where the server handles the compound request itself.
>>>> But from what I understand libfuse can also handle it as individual
>>>> requests, and in this case the server wouldn't know the right nodeid for
>>>> the STATX.
>>>>
>>>> Obviously, the same problem will need to be solved for other operations
>>>> (for example for FUSE_CREATE where we'll need to do a FUSE_MKOBJ_H +
>>>> FUSE_STATX + FUSE_OPEN).
>>>>
>>>> I guess this can eventually be fixed in libfuse, by updating the nodeid in
>>>> this case.  Another solution is to not allow these sort of operations to
>>>> be handled individually.  But maybe I'm just being dense and there's a
>>>> better solution for this.
>>>>
>>>
>>> You have come across a problem, that I have come across, too, during my experiments. 
>>> I think that makes it a rather common problem when creating compounds.
>>>
>>> This can only be solved by convention and it is the reason why I have disabled the default
>>> handling of compounds in libfuse. Bernd actually wanted to do that automatically, but I think
>>> that is too risky for exactly the reason you have found.
>>>
>>> The fuse server has to decide if it wants to handle the compound as such or as a
>>> bunch of single requests.
>>
>> Idea was actually to pass compounds to the daemon if it has a compound
>> handler, if not to handle it automatically. Now for open+getattr
>> fuse-server actually not want the additional getattr - cannot be handle
>> automatically. But for lookup+stat and others like this, if fuse server
>> server does not know how to handle the entire compound, libfuse could
>> still do it correctly, i.e. have its own handler for known compounds?
> 
> We could definitely provide a library of compounds that we 'know' in libfuse,
> of course. No argument there.
> 
> 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?

> 
> BTW, I forgot in my last mail to say that we have another problem, where we need 
> some sort of convention where we will bang our heads sooner or later.
> If the fuse server does not support the given compound it should 
> return EOPNOTSUP in my opinion.
> IIRC this is not implemented correctly so far.
> 
>>
>>>
>>> At the moment I think it is best to just not use the libfuse single request handling 
>>> of the compound where it is not possible. 
>>> As my passthrough_hp shows, you can handle certain compounds as a compound where you know all the information
>>> (like some lookup, you just did in the fuse server) and leave the 'trivial' ones to the lib.
>>>
>>> We could actually pass 'one' id in the 'in header' of the compound as some sort of global parent 
>>> but that would be another convention that the fuse server has to know and keep.
>>>
>>
>>
>> Thanks,
>> Bernd
> 
> Horst

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

[Horst Birthelmer]

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.

> >> Thanks,
> >> Bernd
> > 
> > Horst
> 

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

[Bernd Schubert]

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?


Thanks,
Bernd

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

[Horst Birthelmer]

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

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

[Luis Henriques]

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".

Cheers,
-- 
Luís

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

[Horst Birthelmer]

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.

> 
> Cheers,
> -- 
> Luís

Thanks,
Horst

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

[Bernd Schubert]

On 1/22/26 11:20, 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.

I'm not sure. I think the server compound handler should call into
libfuse as it does right now and ask libfuse to handle it, if it doesn't
have its own handler. But then it needs to be safe. I.e. open+getattr -
cannot be enabled by default, at least not the getattr part, because not
all servers will need that. I.e. server needs to set bits to libfuse to
enable some compound operations. Things like atomic open probably could
be enabled by default.


Thanks,
Bernd

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

[Luis Henriques]

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

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

[Horst Birthelmer]

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.

> Cheers,
> -- 
> Luís

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

[Luis Henriques]

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

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

[Bernd Schubert]

On 1/22/26 12:25, 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.

Kind of, we have an organization github account as well - the PRs went
through that first. We need to add more documentation why it cannot
be done from fuse directly in all cases. Well, the kernel could indeed
add the flags when it is safe. Though the first user of compounds is
open+getattr and there it should not be handled automatically, at
least not without introducing change behavior.


Thanks,
Bernd

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

[Horst Birthelmer]

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
>