On Wed, Aug 20, 2025 at 09:58:15PM +0200, Amir Goldstein wrote:
> On Wed, Aug 20, 2025 at 5:00 PM Thomas Bertschinger
> <tahbertschinger@xxxxxxxxx> 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@xxxxxxxxx> 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.
I like your idea as it's in line with other extensions we've done
recently to open_by_handle_at().
