Hi,

I'm sending a new version of my work on lookup_handle, even though it's
still incomplete.  As suggested elsewhere, it is now based on compound
commands and thus it sits on top of Horst's patchset [0].  Also, because
this version is a complete re-write of the approach presented in my previous
RFC [1] I'm not going to detail what changed.

Here's a few notes:

- The code isn't yet fully testable as there are several pieces missing.
  For example, the FUSE_TMPFILE and FUSE_READDIRPLUS operations are not yet
  implemented.  The NFS-related changes have also been dropped in this
  revision.

- There are several details still to be sorted out in the compound
  operations.  For example, the nodeid for the statx operation in the
  lookup+statx is set to FUSE_ROOT_ID.

- The second operation (mkobj_handle+statx+open) is still draft (or maybe
  just wrong!).  It's not handling flags correctly, and the error handling
  has to be better thought out.

- Some of the patches in this set could probably be picked independently
  (e.g. patch 4 or even patch 1)

So, why am I sending this broken and incomplete patchset?  Well, simply
because I'd feel more confidence getting this approach validated.  I don't
expect any through review, but I would appreciate feedback on anything that
would help me correct major flaws.

[0] https://lore.kernel.org/all/20260210-fuse-compounds-upstream-v5-0-ea0585f62daa@ddn.com
[1] https://lore.kernel.org/all/20251212181254.59365-1-luis@igalia.com

Cheers,
-- 
Luis

Luis Henriques (8):
  fuse: simplify fuse_lookup_name() interface
  fuse: export extend_arg() and factor out fuse_ext_size()
  fuse: store index of the variable length argument
  fuse: drop unnecessary argument from fuse_lookup_init()
  fuse: extract helper functions from fuse_do_statx()
  fuse: implementation of lookup_handle+statx compound operation
  fuse: export fuse_open_args_fill() helper function
  fuse: implementation of mkobj_handle+statx+open compound operation

 fs/fuse/compound.c        |   1 +
 fs/fuse/cuse.c            |   1 +
 fs/fuse/dev.c             |   4 +-
 fs/fuse/dir.c             | 650 +++++++++++++++++++++++++++++++++-----
 fs/fuse/file.c            |   3 +-
 fs/fuse/fuse_i.h          |  42 ++-
 fs/fuse/inode.c           |  50 ++-
 fs/fuse/ioctl.c           |   1 +
 fs/fuse/readdir.c         |   2 +-
 fs/fuse/virtio_fs.c       |   6 +-
 fs/fuse/xattr.c           |   2 +
 include/uapi/linux/fuse.h |  25 +-
 12 files changed, 679 insertions(+), 108 deletions(-)

On Wed, Feb 25, 2026 at 11:24:31AM +0000, Luis Henriques wrote:
> Hi,
> 
> I'm sending a new version of my work on lookup_handle, even though it's
> still incomplete.  As suggested elsewhere, it is now based on compound
> commands and thus it sits on top of Horst's patchset [0].  Also, because
> this version is a complete re-write of the approach presented in my previous
> RFC [1] I'm not going to detail what changed.
> 
> Here's a few notes:
> 
> - The code isn't yet fully testable as there are several pieces missing.
>   For example, the FUSE_TMPFILE and FUSE_READDIRPLUS operations are not yet
>   implemented.  The NFS-related changes have also been dropped in this
>   revision.
> 
> - There are several details still to be sorted out in the compound
>   operations.  For example, the nodeid for the statx operation in the
>   lookup+statx is set to FUSE_ROOT_ID.
> 
> - The second operation (mkobj_handle+statx+open) is still draft (or maybe
>   just wrong!).  It's not handling flags correctly, and the error handling
>   has to be better thought out.
> 
> - Some of the patches in this set could probably be picked independently
>   (e.g. patch 4 or even patch 1)
> 
> So, why am I sending this broken and incomplete patchset?  Well, simply
> because I'd feel more confidence getting this approach validated.  I don't
> expect any through review, but I would appreciate feedback on anything that
> would help me correct major flaws.

I, personally, appreciate the fact that you sent this out, so I can understand how
you are using the compounds for this real world problem, and it gives me confidence
that I'm not completely off with the compounds. 

Do you by any chance have implemented the fuse server part, too, or looked at it?
I'm just curious.

> 
> [0] https://lore.kernel.org/all/20260210-fuse-compounds-upstream-v5-0-ea0585f62daa@ddn.com
> [1] https://lore.kernel.org/all/20251212181254.59365-1-luis@igalia.com
> 
> Cheers,
> -- 
> Luis

Thanks,
Horst

Hey Horst,

On Wed, Feb 25 2026, Horst Birthelmer wrote:

> On Wed, Feb 25, 2026 at 11:24:31AM +0000, Luis Henriques wrote:
>> Hi,
>> 
>> I'm sending a new version of my work on lookup_handle, even though it's
>> still incomplete.  As suggested elsewhere, it is now based on compound
>> commands and thus it sits on top of Horst's patchset [0].  Also, because
>> this version is a complete re-write of the approach presented in my previous
>> RFC [1] I'm not going to detail what changed.
>> 
>> Here's a few notes:
>> 
>> - The code isn't yet fully testable as there are several pieces missing.
>>   For example, the FUSE_TMPFILE and FUSE_READDIRPLUS operations are not yet
>>   implemented.  The NFS-related changes have also been dropped in this
>>   revision.
>> 
>> - There are several details still to be sorted out in the compound
>>   operations.  For example, the nodeid for the statx operation in the
>>   lookup+statx is set to FUSE_ROOT_ID.
>> 
>> - The second operation (mkobj_handle+statx+open) is still draft (or maybe
>>   just wrong!).  It's not handling flags correctly, and the error handling
>>   has to be better thought out.
>> 
>> - Some of the patches in this set could probably be picked independently
>>   (e.g. patch 4 or even patch 1)
>> 
>> So, why am I sending this broken and incomplete patchset?  Well, simply
>> because I'd feel more confidence getting this approach validated.  I don't
>> expect any through review, but I would appreciate feedback on anything that
>> would help me correct major flaws.
>
> I, personally, appreciate the fact that you sent this out, so I can understand how
> you are using the compounds for this real world problem, and it gives me confidence
> that I'm not completely off with the compounds. 
>
> Do you by any chance have implemented the fuse server part, too, or looked at it?
> I'm just curious.

I do have _something_ for testing, yes.  Obviously, I will eventually
share it but I wasn't planning to share it at this stage yet (it's ugly
and full of debug code).  But if you'd like to have a look I can do a quick
clean-up and push it somewhere.

Cheers,
-- 
Luís