Searched hist:"0 a262ffb" (Results 1 – 1 of 1) sorted by relevance
/openbmc/linux/fs/nfsd/ |
H A D | nfs4state.c | 0a262ffb Mon Jun 17 16:29:40 CDT 2013 J. Bruce Fields <bfields@redhat.com> nfsd4: do not throw away 4.1 lock state on last unlock
This reverts commit eb2099f31b0f090684a64ef8df44a30ff7c45fc2 "nfsd4: release lockowners on last unlock in 4.1 case". Trond identified language in rfc 5661 section 8.2.4 which forbids this behavior:
Stateids associated with byte-range locks are an exception. They remain valid even if a LOCKU frees all remaining locks, so long as the open file with which they are associated remains open, unless the client frees the stateids via the FREE_STATEID operation.
And bakeathon 2013 testing found a 4.1 freebsd client was getting an incorrect BAD_STATEID return from a FREE_STATEID in the above situation and then failing.
The spec language honestly was probably a mistake but at this point with implementations already following it we're probably stuck with that.
Signed-off-by: J. Bruce Fields <bfields@redhat.com> 0a262ffb Mon Jun 17 16:29:40 CDT 2013 J. Bruce Fields <bfields@redhat.com> nfsd4: do not throw away 4.1 lock state on last unlock This reverts commit eb2099f31b0f090684a64ef8df44a30ff7c45fc2 "nfsd4: release lockowners on last unlock in 4.1 case". Trond identified language in rfc 5661 section 8.2.4 which forbids this behavior: Stateids associated with byte-range locks are an exception. They remain valid even if a LOCKU frees all remaining locks, so long as the open file with which they are associated remains open, unless the client frees the stateids via the FREE_STATEID operation. And bakeathon 2013 testing found a 4.1 freebsd client was getting an incorrect BAD_STATEID return from a FREE_STATEID in the above situation and then failing. The spec language honestly was probably a mistake but at this point with implementations already following it we're probably stuck with that. Signed-off-by: J. Bruce Fields <bfields@redhat.com>
|