From: Trond Myklebust Date: Sat, 24 Jan 2015 23:38:15 +0000 (-0500) Subject: NFSv4: Always do open_to_lock_owner if the lock stateid is uninitialised X-Git-Tag: firefly_0821_release~176^2~2246^2~51 X-Git-Url: http://demsky.eecs.uci.edu/git/?a=commitdiff_plain;h=6b447539aa9aaac0a0215f3e28a0839553210e7e;p=firefly-linux-kernel-4.4.55.git 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 --- 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; }