Gitweb:     
http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=2beb6614f5e36c6165b704c167d82ef3e4ceaa0c
Commit:     2beb6614f5e36c6165b704c167d82ef3e4ceaa0c
Parent:     fd85b8170dabbf021987875ef7f903791f4f181e
Author:     Marc Eshel <[EMAIL PROTECTED]>
AuthorDate: Tue Dec 5 23:31:28 2006 -0500
Committer:  J. Bruce Fields <[EMAIL PROTECTED]>
CommitDate: Sun May 6 20:38:49 2007 -0400

    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 <[EMAIL PROTECTED]>
    Signed-off-by: J. Bruce Fields <[EMAIL PROTECTED]>
---
 fs/locks.c         |   19 +++++++++++++++++++
 include/linux/fs.h |    1 +
 2 files changed, 20 insertions(+), 0 deletions(-)

diff --git a/fs/locks.c b/fs/locks.c
index 242328e..53b0cd1 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -1698,6 +1698,25 @@ out:
  * If the filesystem defines a private ->lock() method, then @conf will
  * be left unchanged; so a caller that cares should initialize it to
  * some acceptable default.
+ *
+ * To avoid blocking kernel daemons, such as lockd, that need to acquire POSIX
+ * locks, the ->lock() interface may return asynchronously, before the lock has
+ * been granted or denied by the underlying filesystem, if (and only if)
+ * fl_grant is set. Callers expecting ->lock() to return asynchronously
+ * will only use F_SETLK, not F_SETLKW; they will set FL_SLEEP if (and only if)
+ * the request is for a blocking lock. When ->lock() does return 
asynchronously,
+ * it must return -EINPROGRESS, and call ->fl_grant() when the lock
+ * request completes.
+ * If the request is for non-blocking lock the file system should return
+ * -EINPROGRESS then try to get the lock and call the callback routine with
+ * the result. If the request timed out the callback routine will return a
+ * nonzero return code and the file system should release the lock. The file
+ * system is also responsible to keep a corresponding posix lock when it
+ * grants a lock so the VFS can find out which locks are locally held and do
+ * the correct lock cleanup when required.
+ * The underlying filesystem must not drop the kernel lock or call
+ * ->fl_grant() before returning to the caller with a -EINPROGRESS
+ * return code.
  */
 int vfs_lock_file(struct file *filp, unsigned int cmd, struct file_lock *fl, 
struct file_lock *conf)
 {
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 64b8ae2..b22991d 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -785,6 +785,7 @@ struct file_lock_operations {
 struct lock_manager_operations {
        int (*fl_compare_owner)(struct file_lock *, struct file_lock *);
        void (*fl_notify)(struct file_lock *);  /* unblock callback */
+       int (*fl_grant)(struct file_lock *, struct file_lock *, int);
        void (*fl_copy_lock)(struct file_lock *, struct file_lock *);
        void (*fl_release_private)(struct file_lock *);
        void (*fl_break)(struct file_lock *);
-
To unsubscribe from this list: send the line "unsubscribe git-commits-head" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to