]> git.karo-electronics.de Git - karo-tx-linux.git/commitdiff
NFSv4: Always do open_to_lock_owner if the lock stateid is uninitialised
authorTrond Myklebust <trond.myklebust@primarydata.com>
Sat, 24 Jan 2015 23:38:15 +0000 (18:38 -0500)
committerTrond Myklebust <trond.myklebust@primarydata.com>
Sat, 24 Jan 2015 23:46:46 +0000 (18:46 -0500)
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>
fs/nfs/nfs4proc.c

index db9d98eda07be85a0d66e93e239c64e28ad88669..f12ded041a426c3f25ab684a71b404325fdec057 100644 (file)
@@ -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;
                }