summaryrefslogtreecommitdiffstats
path: root/drivers/pinctrl/pinctrl-adi2-bf60x.c
diff options
context:
space:
mode:
authorNeilBrown <neilb@suse.com>2016-12-19 11:33:13 +1100
committerTrond Myklebust <trond.myklebust@primarydata.com>2016-12-19 17:29:50 -0500
commit3f8f25489fa62437530f654041504936d377d204 (patch)
tree0b77bc80edabba6f29d65a574e22919273779d7f /drivers/pinctrl/pinctrl-adi2-bf60x.c
parentcfd278c280f997cf2fe4662e0acab0fe465f637b (diff)
downloadlinux-3f8f25489fa62437530f654041504936d377d204.tar.gz
linux-3f8f25489fa62437530f654041504936d377d204.tar.bz2
linux-3f8f25489fa62437530f654041504936d377d204.zip
NFSv4: ensure __nfs4_find_lock_state returns consistent result.
If a file has both flock locks and OFD locks, then it is possible that two different nfs4 lock states could apply to file accesses from a single process. It is not possible to know, efficiently, which one is "correct". Presumably the state which represents a lock that covers the region undergoing IO would be the "correct" one to use, but finding that has a non-trivial cost and would provide miniscule value. Currently we just return whichever is first in the list, which could result in inconsistent behaviour if an application ever put it self in this position. As consistent behaviour is preferable (when perfectly correct behaviour is not available), change the search to return a consistent result in this circumstance. Specifically: if there is both a flock and OFD lock state, always return the flock one. Reviewed-by: Jeff Layton <jlayton@redhat.com> Signed-off-by: NeilBrown <neilb@suse.com> Signed-off-by: Trond Myklebust <trond.myklebust@primarydata.com>
Diffstat (limited to 'drivers/pinctrl/pinctrl-adi2-bf60x.c')
0 files changed, 0 insertions, 0 deletions