projects / linux-2.6-block.git / commit
? search:
summary | shortlog | log | commit | commitdiff | tree
(parent: 39071e6) | patch
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)
commit6b447539aa9aaac0a0215f3e28a0839553210e7e
tree66bfecb6aecbf164a9ab61dcb5ebe639c4d6d43ftree | snapshot
parent39071e6fff7d7e11a5993afd67240ef04a4d05a0commit | diff
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>
fs/nfs/nfs4proc.c diff | blob | blame | history
Linux 6.x block layer and io_uring tree(s)