diff options
author | Marc Eshel <eshel@almaden.ibm.com> | 2006-12-05 23:31:28 -0500 |
---|---|---|
committer | J. Bruce Fields <bfields@citi.umich.edu> | 2007-05-06 20:38:49 -0400 |
commit | 2beb6614f5e36c6165b704c167d82ef3e4ceaa0c (patch) | |
tree | 7c5c1277f139c754d7b73a1822016574de655bd6 /include/linux/selinux_netlink.h | |
parent | fd85b8170dabbf021987875ef7f903791f4f181e (diff) | |
download | blackbird-op-linux-2beb6614f5e36c6165b704c167d82ef3e4ceaa0c.tar.gz blackbird-op-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 'include/linux/selinux_netlink.h')
0 files changed, 0 insertions, 0 deletions