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

[Jeff Layton <jlayton@kernel.org>]

On Mon, 2025-09-29 at 12:37 -0400, Chuck Lever wrote:
> 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.
> 

It would be very strange for a legit client to request this, so a hard
error would be fine too.
-- 
Jeff Layton <jlayton@kernel.org>