summaryrefslogtreecommitdiff
path: root/kernel
diff options
context:
space:
mode:
authorJeff Layton <jlayton@poochiereds.net>2015-09-17 07:47:08 -0400
committerSasha Levin <sasha.levin@oracle.com>2016-01-21 11:23:28 -0500
commite46b3f459f2efa11329013b3df96723ec4d2f314 (patch)
treec6c05414625c70b9bc75f9c0d52212b89ad0c1a4 /kernel
parent1d985e6898cd3fccd11c9f9d37a2f86ff72311c9 (diff)
downloadlwn-e46b3f459f2efa11329013b3df96723ec4d2f314.tar.gz
lwn-e46b3f459f2efa11329013b3df96723ec4d2f314.zip
nfsd: serialize state seqid morphing operations
[ Upstream commit 35a92fe8770ce54c5eb275cd76128645bea2d200 ] Andrew was seeing a race occur when an OPEN and OPEN_DOWNGRADE were running in parallel. The server would receive the OPEN_DOWNGRADE first and check its seqid, but then an OPEN would race in and bump it. The OPEN_DOWNGRADE would then complete and bump the seqid again. The result was that the OPEN_DOWNGRADE would be applied after the OPEN, even though it should have been rejected since the seqid changed. The only recourse we have here I think is to serialize operations that bump the seqid in a stateid, particularly when we're given a seqid in the call. To address this, we add a new rw_semaphore to the nfs4_ol_stateid struct. We do a down_write prior to checking the seqid after looking up the stateid to ensure that nothing else is going to bump it while we're operating on it. In the case of OPEN, we do a down_read, as the call doesn't contain a seqid. Those can run in parallel -- we just need to serialize them when there is a concurrent OPEN_DOWNGRADE or CLOSE. LOCK and LOCKU however always take the write lock as there is no opportunity for parallelizing those. Reported-and-Tested-by: Andrew W Elble <aweits@rit.edu> Signed-off-by: Jeff Layton <jeff.layton@primarydata.com> Cc: stable@vger.kernel.org Signed-off-by: J. Bruce Fields <bfields@redhat.com> Signed-off-by: Sasha Levin <sasha.levin@oracle.com>
Diffstat (limited to 'kernel')
0 files changed, 0 insertions, 0 deletions