diff options
author | Jeff Layton <jlayton@poochiereds.net> | 2015-10-01 09:05:50 -0400 |
---|---|---|
committer | J. Bruce Fields <bfields@redhat.com> | 2015-10-23 15:57:33 -0400 |
commit | 9767feb2c64b29775f1ea683130b44f95f67d169 (patch) | |
tree | cfde0f75348706306314749a9ac8164d0237a0d4 /net | |
parent | cc8a55320b5f1196bee5bd14e4bb2ebd3b983317 (diff) | |
download | linux-9767feb2c64b29775f1ea683130b44f95f67d169.tar.bz2 |
nfsd: ensure that seqid morphing operations are atomic wrt to copies
Bruce points out that the increment of the seqid in stateids is not
serialized in any way, so it's possible for racing calls to bump it
twice and end up sending the same stateid. While we don't have any
reports of this problem it _is_ theoretically possible, and could lead
to spurious state recovery by the client.
In the current code, update_stateid is always followed by a memcpy of
that stateid, so we can combine the two operations. For better
atomicity, we add a spinlock to the nfs4_stid and hold that when bumping
the seqid and copying the stateid.
Signed-off-by: Jeff Layton <jeff.layton@primarydata.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Diffstat (limited to 'net')
0 files changed, 0 insertions, 0 deletions