p71924506
/
linux_old1
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

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 <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
This commit is contained in:
Jeff Layton 2018-02-15 15:16:18 -05:00 committed by J. Bruce Fields
parent 3b68e6ee3c
commit bd2decac5e
1 changed files with 15 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
fs/nfsd/nfs4state.c
View File

@ -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);