[nfsv4] Re: question about delegated timestamps (delstid draft)

[Jeff Layton <[e-mail]>]

On Wed, 2024-08-28 at 13:33 -0400, Jeff Layton wrote:
> On Wed, 2024-08-28 at 13:13 -0400, Jeff Layton wrote:
> > The draft says mentions this:
> > 
> >    Further, when it gets a SETATTR in the same compound as the
> >    DELEGRETURN, then it MUST accept those fattr4_time_deleg_access
> >    attribute and fattr4_time_deleg_modify attribute changes and
> > derive
> >    the change time or reject the changes with NFS4ERR_DELAY (see
> >    Section 15.1.1.3 of [RFC8881]).
> > 
> > Presumably, the SETATTR will precede the DELEGRETURN in the
> > compound,
> > in which case (at least under Linux kernel server) we will not have
> > vetted the DELEGRETURN stateid yet.
> > 
> > The simplest fix might be to just have it accept SETATTR for the
> > delegated atime and mtime iff the client is the owner of the write
> > delegation.
> 
> Sorry, to be clear, my question is:
> 
> What should we do if we're presented with a bogus delegation stateid
> in
> a compound with SETATTR, DELEGRETURN ? I'm assuming we wouldn't want
> to
> accept changing these attrs without knowing that the client holds a
> valid deleg, because this potentially affects the ctime as well.
> 
> Assuming that's the case, what should we return if we're going to
> reject setting these attrs? NFS4ERR_ACCESS or _PERM seems not quite
> right. Maybe _DELEG_REVOKED ?
> 

Or...we could just mandate that the client send the deleg stateid in
the SETATTR request in order to set these attrs?
-- 
Jeff Layton <[e-mail]>