summaryrefslogtreecommitdiffstats
path: root/fs/lockd/svclock.c
diff options
context:
space:
mode:
authorMarc Eshel <eshel@almaden.ibm.com>2006-12-06 05:31:28 +0100
committerJ. Bruce Fields <bfields@citi.umich.edu>2007-05-07 02:38:49 +0200
commit2beb6614f5e36c6165b704c167d82ef3e4ceaa0c (patch)
tree7c5c1277f139c754d7b73a1822016574de655bd6 /fs/lockd/svclock.c
parentnfsd4: Convert NFSv4 to new lock interface (diff)
downloadlinux-2beb6614f5e36c6165b704c167d82ef3e4ceaa0c.tar.xz
linux-2beb6614f5e36c6165b704c167d82ef3e4ceaa0c.zip
locks: add fl_grant callback for asynchronous lock return
Acquiring a lock on a cluster filesystem may require communication with remote hosts, and to avoid blocking lockd or nfsd threads during such communication, we allow the results to be returned asynchronously. When a ->lock() call needs to block, the file system will return -EINPROGRESS, and then later return the results with a call to the routine in the fl_grant field of the lock_manager_operations struct. This differs from the case when ->lock returns -EAGAIN to a blocking lock request; in that case, the filesystem calls fl_notify when the lock is granted, and the caller retries the original lock. So while fl_notify is merely a hint to the caller that it should retry, fl_grant actually communicates the final result of the lock operation (with the lock already acquired in the succesful case). Therefore fl_grant takes a lock, a status and, for the test lock case, a conflicting lock. We also allow fl_grant to return an error to the filesystem, to handle the case where the fl_grant requests arrives after the lock manager has already given up waiting for it. Signed-off-by: Marc Eshel <eshel@almaden.ibm.com> Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Diffstat (limited to 'fs/lockd/svclock.c')
0 files changed, 0 insertions, 0 deletions