summaryrefslogtreecommitdiffstats
path: root/fs/nfs_common
diff options
context:
space:
mode:
authorJeff Layton <jlayton@primarydata.com>2014-08-22 10:18:44 -0400
committerJeff Layton <jlayton@primarydata.com>2014-09-09 16:01:09 -0400
commit09802fd2a8caea2a2147fca8d7975697c5de573d (patch)
tree99f87c52a0921d3eaa9796a349784bf676bc3b3c /fs/nfs_common
parentaef9583b234a4ecdbcaf2c3024f29d4244b18e83 (diff)
downloadlinux-09802fd2a8caea2a2147fca8d7975697c5de573d.tar.gz
linux-09802fd2a8caea2a2147fca8d7975697c5de573d.tar.bz2
linux-09802fd2a8caea2a2147fca8d7975697c5de573d.zip
lockd: rip out deferred lock handling from testlock codepath
As Kinglong points out, the nlm_block->b_fl field is no longer used at all. Also, vfs_test_lock in the generic locking code will only return FILE_LOCK_DEFERRED if FL_SLEEP is set, and it isn't here. The only other place that returns that value is the DLM lock code, but it only does that in dlm_posix_lock, never in dlm_posix_get. Remove all of the deferred locking code from the testlock codepath since it doesn't appear to ever be used anyway. I do have a small concern that this might cause a behavior change in the case where you have a block already sitting on the list when the testlock request comes in, but that looks like it doesn't really work properly anyway. I think it's best to just pass that down to vfs_test_lock and let the filesystem report that instead of trying to infer what's going on with the lock by looking at an existing block. Cc: cluster-devel@redhat.com Signed-off-by: Jeff Layton <jlayton@primarydata.com> Reviewed-by: Kinglong Mee <kinglongmee@gmail.com>
Diffstat (limited to 'fs/nfs_common')
0 files changed, 0 insertions, 0 deletions