Re: [PATCHSET RFC 0/6] add support for name_to, open_by_handle_at(2) to io_uring

[Amir Goldstein <amir73il@gmail.com>]

On Wed, Aug 20, 2025 at 5:00 PM Thomas Bertschinger
<tahbertschinger@gmail.com> wrote:
>
> On Wed Aug 20, 2025 at 2:34 AM MDT, Amir Goldstein wrote:
> > On Wed, Aug 20, 2025 at 4:57 AM Thomas Bertschinger
> > <tahbertschinger@gmail.com> wrote:
> >> Any thoughts on that? This seemed to me like there wasn't an obvious
> >> easy solution, hence why I just didn't attempt it at all in v1.
> >> Maybe I'm missing something, though.
> >>
> >
> > Since FILEID_IS_CONNECTABLE, we started using the high 16 bits of
> > fh_type for FILEID_USER_FLAGS, since fs is not likely expecting a fh_type
> > beyond 0xff (Documentation/filesystems/nfs/exporting.rst):
> > "A filehandle fragment consists of an array of 1 or more 4byte words,
> > together with a one byte "type"."
> >
> > The name FILEID_USER_FLAGS may be a bit misleading - it was
> > never the intention for users to manipulate those flags, although they
> > certainly can and there is no real harm in that.
> >
> > These flags are used in the syscall interface only, but
> > ->fh_to_{dentry,parent}() function signature also take an int fh_flags
> > argument, so we can use that to express the non-blocking request.
> >
> > Untested patch follows (easier than explaining):
>
> Ah, that makes sense and makes this seem feasible. Thanks for pointing
> that out!
>
> It also seems that each FS could opt in to this with a new EXPORT_OP
> flag so that the FSes that want to support this can be updated
> individually. Then, updating most or every exportable FS isn't a
> requirement for this.

Makes a lot of sense. yes.

>
> Do you have an opinion on that, versus expecting every ->fh_to_dentry()
> implementation to respect the new flag?

Technically, you do not need every fs to respect this flag, you only need them
to not ignore it.

Generally, if you pass (fileid_type | EXPORT_FH_CACHED) as the type
argument, most filesystems will not accept this value anyway and return
NULL or PTR_ERR(-ESTALE), so not ignoring.

But I think it is much preferred to check the opt-in EXPORT_OP
flag and return EAGAIN from generic code in the case that fs does
not support non-blocking decode.

And fs that do opt in should probably return PTR_ERR(-EAGAIN)
when the file type is correct but non-blocking decode is not possible.

Thanks,
Amir.