Re: [PATCH v2 12/21] fuse: add struct fuse_entry2_out and helpers for extended entry replies

Amir Goldstein <[email protected]> Sat, 16 May 2026 19:25:05 +0200
Newsgroups org.kernel.vger.linux-unionfs,dev.linux.lists.fuse-devel
Message-ID <CAOQ4uxjMPPp-R37yKoOs1kGUdAOmnp3keVWvfuxi1r8jrxAcTA@mail.gmail.com>
On Sat, May 16, 2026 at 2:52 AM Joanne Koong <[email protected]> wrote:
>
> Add struct fuse_entry2_out, which is a new extended entry reply struct
> that carries a backing_id and statx attributes. This will be necessary
> for setting fuse passthrough on inodes.
>
> Add helpers that subsequent commits will use to process fuse_entry2_out
> for passthrough support for lookup, revalidate, and create.
> fuse_statx_to_attr() is also moved to earlier in the file to avoid
> forward declaring.
>

I think you had a discussion with Miklos about whether
it makes sense to do a compound response for LOOKUP+STATX.
I don't remember the conclusion, but if this can save us all the
if (use_entry2) { } else {} all over the code, then I think it is worth it.

Can you give me the bottom line from your discussion or was there
no conclusion reached?

If we do that, where do we return backing_id?
Could make use of the reserved[] fields in fuse_statx_out.

I happen to have a test patch at the tip of my fuse-backing-inode-wip
branch:
6e296625eafd6 fuse: support setting backing inode passthrough on getattr

It's not using the statx response, and it was just done for testing,
but in theory,
if a server wants to  change an inode from non-passthrough to
yes-passthrough mid lifetime
doing this on attribute cache expiry may make more sense than on entry
timeout expiry, because backing_id is an attribute of the inode not the dentry.

Not sure if this is making any sense.

Thanks,
Amir.