Re: [PATCH v1] NFSD: Define actions for the new time_deleg FATTR4 attributes

[Chuck Lever <chuck.lever@oracle.com>]

On 9/29/25 6:39 AM, Jeff Layton wrote:
>> Do clients query SUPPORTED_ATTRS and look for these two bits to
>> know whether to expect attribute delegation?
>>
> The Linux client does:
> 
> static bool nfs4_server_delegtime_capable(struct nfs4_server_caps_res *res)
> {
>         u32 share_access_want = res->open_caps.oa_share_access_want[0];
>         u32 attr_bitmask = res->attr_bitmask[2];
> 
>         return (share_access_want & NFS4_SHARE_WANT_DELEG_TIMESTAMPS) &&
>                ((attr_bitmask & FATTR4_WORD2_NFS42_TIME_DELEG_MASK) ==
>                                         FATTR4_WORD2_NFS42_TIME_DELEG_MASK);
> }
> 
> 
> ...so I guess we can't report them as unsupported. They do still need
> to be supported for SETATTR. Still, we should just mask them off if
> someone tries to query for them.

There appears to be a bit of a gray area here. RFC 8881 Section 18.7.3
states:

> The server MUST return a value for each attribute that the client
> requests if the attribute is supported by the server for the target
> file system. If the server does not support a particular attribute on
> the target file system, then it MUST NOT return the attribute value
> and MUST NOT set the attribute bit in the result bitmap. The server
> MUST return an error if it supports an attribute on the target but
> cannot obtain its value. In that case, no attribute values will be
> returned.

RFC 9754 Section 5 states:

> These new attributes are invalid to be used with GETATTR, VERIFY, and
> NVERIFY, and they can only be used with CB_GETATTR and SETATTR by a
> client holding an appropriate delegation.

This text does not prescribe a specific server response if it should be
presented with a GETATTR operation (or a READDIR, one assumes) that
queries delegated time stamps.

Perhaps, rather than clearing the result bitmask, NFS4ERR_INVAL is the
mandated server response.


-- 
Chuck Lever