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

On Sat, May 16, 2026 at 12:29 PM Horst Birthelmer <[email protected]> wrote:
>
> On Sat, May 16, 2026 at 07:25:05PM +0200, Amir Goldstein wrote:
> > 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?

I think the conclusion was that for fusex it will be compounded, but
I'm not sure what Miklos is thinking for fuse.

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

I like this idea but I think for supporting yes passthrough -> no
passthrough, it would have to go through an ioctl mechanism since the
getattr could be passed through. In that case, I was thinking it would
be better to have the interfaces be consistent (eg both yes
passthrough -> no passthrough and no passthrough -> yes passthrough go
through an ioctl interface).

I think even with the backing id as part of statx and lookup+statx
compounded together, there would still have to be the "if (use_entry2)
{} else {}" branching logic to handle the new slimmed-down-lookup
differently from old lookup).

>
> Hi Amir,
>
> I see there is a lot of talk about using the compounds in a couple of different contexts.
> I really have to apologize for not having the latest patch ready by now, but I'm
> a bit unsure how to do it.
>
> I'm not entirely sure if compounds will only be a thing for fusex or if it will ever
> be accepted for the classic FUSE.

I'm not sure what the plan is either. I think this will get clarified
on Thursday hopefully.

Thanks,
Joanne

>
> I actually have a patch that I have not tested well enough, since I have to maintain
> our own version and then have to do the fusex one and probably the new verison for
> the classic FUSE version.
>
> So, sorry about that, but I'm not having enough clarity on what to focus on.
>
> >
> > Not sure if this is making any sense.
> >
> > Thanks,
> > Amir.
> >
>
> Horst