summaryrefslogtreecommitdiffstats
path: root/fs/nfs/nfs4proc.c
diff options
context:
space:
mode:
authorTrond Myklebust <trond.myklebust@primarydata.com>2015-01-25 00:38:15 +0100
committerTrond Myklebust <trond.myklebust@primarydata.com>2015-01-25 00:46:46 +0100
commit6b447539aa9aaac0a0215f3e28a0839553210e7e (patch)
tree66bfecb6aecbf164a9ab61dcb5ebe639c4d6d43f /fs/nfs/nfs4proc.c
parentNFSv4: Fix atomicity problems with lock stateid updates (diff)
downloadlinux-6b447539aa9aaac0a0215f3e28a0839553210e7e.tar.xz
linux-6b447539aa9aaac0a0215f3e28a0839553210e7e.zip
NFSv4: Always do open_to_lock_owner if the lock stateid is uninitialised
The original text in RFC3530 was terribly confusing since it conflated lockowners and lock stateids. RFC3530bis clarifies that you must use open_to_lock_owner when there is no lock state for that file+lockowner combination. Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Diffstat (limited to 'fs/nfs/nfs4proc.c')
-rw-r--r--fs/nfs/nfs4proc.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/fs/nfs/nfs4proc.c b/fs/nfs/nfs4proc.c
index db9d98eda07b..f12ded041a42 100644
--- a/fs/nfs/nfs4proc.c
+++ b/fs/nfs/nfs4proc.c
@@ -5611,7 +5611,7 @@ static void nfs4_lock_prepare(struct rpc_task *task, void *calldata)
if (nfs_wait_on_sequence(data->arg.lock_seqid, task) != 0)
goto out_wait;
/* Do we need to do an open_to_lock_owner? */
- if (!(data->arg.lock_seqid->sequence->flags & NFS_SEQID_CONFIRMED)) {
+ if (!test_bit(NFS_LOCK_INITIALIZED, &data->lsp->ls_flags)) {
if (nfs_wait_on_sequence(data->arg.open_seqid, task) != 0) {
goto out_release_lock_seqid;
}