From bd2decac5e8ab7b326f54b40e3ac8b3b1ac935ed Mon Sep 17 00:00:00 2001 From: Jeff Layton Date: Thu, 15 Feb 2018 15:16:18 -0500 Subject: [PATCH] nfsd4: send the special close_stateid in v4.0 replies as well We already send it for v4.1, but RFC7530 also notes that the stateid in the close reply is bogus. Always send the special close stateid, even in v4.0 responses. No client should put any meaning on it whatsoever. For now, we continue to increment the stateid value, though that might not be necessary either. Signed-off-by: Jeff Layton Signed-off-by: J. Bruce Fields --- fs/nfsd/nfs4state.c | 19 +++++++++++++++---- 1 file changed, 15 insertions(+), 4 deletions(-) diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c index 61b770e39809..34e6915831d8 100644 --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -5521,15 +5521,26 @@ nfsd4_close(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate, goto out; stp->st_stid.sc_type = NFS4_CLOSED_STID; + + /* + * Technically we don't _really_ have to increment or copy it, since + * it should just be gone after this operation and we clobber the + * copied value below, but we continue to do so here just to ensure + * that racing ops see that there was a state change. + */ nfs4_inc_and_copy_stateid(&close->cl_stateid, &stp->st_stid); nfsd4_close_open_stateid(stp); mutex_unlock(&stp->st_mutex); - /* See RFC5661 sectionm 18.2.4 */ - if (stp->st_stid.sc_client->cl_minorversion) - memcpy(&close->cl_stateid, &close_stateid, - sizeof(close->cl_stateid)); + /* v4.1+ suggests that we send a special stateid in here, since the + * clients should just ignore this anyway. Since this is not useful + * for v4.0 clients either, we set it to the special close_stateid + * universally. + * + * See RFC5661 section 18.2.4, and RFC7530 section 16.2.5 + */ + memcpy(&close->cl_stateid, &close_stateid, sizeof(close->cl_stateid)); /* put reference from nfs4_preprocess_seqid_op */ nfs4_put_stid(&stp->st_stid); -- 2.30.2