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.
Do you have an opinion on that, versus expecting every ->fh_to_dentry()
implementation to respect the new flag?
