[PATCH 9/17] locks: add lock cancel command

[PATCH 9/17] locks: add lock cancel command

[J. Bruce Fields]

From: Marc Eshel <eshel@almaden.ibm.com> - unquoted

Lock managers need to be able to cancel pending lock requests.  In the case
where the exported filesystem manages its own locks, it's not sufficient just
to call posix_unblock_lock(); we need to let the filesystem know what's
happening too.

We do this by adding a new fcntl lock command: FL_CANCELLK.  Some day this
might also be made available to userspace applications that could benefit from
an asynchronous locking api.

Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
---
 fs/locks.c            |   17 +++++++++++++++++
 include/linux/fcntl.h |    4 ++++
 include/linux/fs.h    |    1 +
 3 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/fs/locks.c b/fs/locks.c
index 485b38a..68ae4d4 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -2041,6 +2041,23 @@ posix_unblock_lock(struct file *filp, struct file_lock *waiter)
 
 EXPORT_SYMBOL(posix_unblock_lock);
 
+/**
+ * vfs_cancel_lock - file byte range unblock lock
+ * @filp: The file to apply the unblock to
+ * @fl: The lock to be unblocked
+ *
+ * Used by lock managers to cancel blocked requests
+ */
+int vfs_cancel_lock(struct file *filp, struct file_lock *fl)
+{
+	if (filp->f_op && filp->f_op->lock)
+		return filp->f_op->lock(filp, F_CANCELLK, fl);
+	else
+		return posix_unblock_lock(filp, fl);
+}
+
+EXPORT_SYMBOL_GPL(vfs_cancel_lock);
+
 static void lock_get_status(char* out, struct file_lock *fl, int id, char *pfx)
 {
 	struct inode *inode = NULL;
diff --git a/include/linux/fcntl.h b/include/linux/fcntl.h
index 996f561..40b9326 100644
--- a/include/linux/fcntl.h
+++ b/include/linux/fcntl.h
@@ -3,6 +3,10 @@
 
 #include <asm/fcntl.h>
 
+/* Cancel a blocking posix lock; internal use only until we expose an
+ * asynchronous lock api to userspace: */
+#define F_CANCELLK	(F_LINUX_SPECIFIC_BASE+5)
+
 #define F_SETLEASE	(F_LINUX_SPECIFIC_BASE+0)
 #define F_GETLEASE	(F_LINUX_SPECIFIC_BASE+1)
 
diff --git a/include/linux/fs.h b/include/linux/fs.h
index bec1dbe..c58690d 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -857,6 +857,7 @@ extern int posix_lock_file_wait(struct file *, struct file_lock *);
 extern int posix_unblock_lock(struct file *, struct file_lock *);
 extern int vfs_test_lock(struct file *, struct file_lock *);
 extern int vfs_lock_file(struct file *, unsigned int, struct file_lock *, struct file_lock *);
+extern int vfs_cancel_lock(struct file *filp, struct file_lock *fl);
 extern int flock_lock_file_wait(struct file *filp, struct file_lock *fl);
 extern int __break_lease(struct inode *inode, unsigned int flags);
 extern void lease_get_mtime(struct inode *, struct timespec *time);
-- 
1.5.0.rc1.gf4b6c

Re: [PATCH 9/17] locks: add lock cancel command

[Christoph Hellwig]

On Thu, Apr 05, 2007 at 07:40:59PM -0400, J. Bruce Fields wrote:
> From: Marc Eshel <eshel@almaden.ibm.com> - unquoted
> 
> Lock managers need to be able to cancel pending lock requests.  In the case
> where the exported filesystem manages its own locks, it's not sufficient just
> to call posix_unblock_lock(); we need to let the filesystem know what's
> happening too.
> 
> We do this by adding a new fcntl lock command: FL_CANCELLK.  Some day this
> might also be made available to userspace applications that could benefit from
> an asynchronous locking api.

Should we really add more and more subcases to ->lock that probably don't
share implementation code?  I'd much prefer adding different operations.

Re: [PATCH 9/17] locks: add lock cancel command

[J. Bruce Fields]

On Mon, Apr 09, 2007 at 07:41:44PM +0100, Christoph Hellwig wrote:
> On Thu, Apr 05, 2007 at 07:40:59PM -0400, J. Bruce Fields wrote:
> > We do this by adding a new fcntl lock command: FL_CANCELLK.  Some day this
> > might also be made available to userspace applications that could benefit from
> > an asynchronous locking api.
> 
> Should we really add more and more subcases to ->lock that probably don't
> share implementation code?  I'd much prefer adding different operations.

That'd be OK.  We considered both--

	http://marc.info/?l=linux-fsdevel&m=116616992004056&w=2

--but chose a new ->lock case just because that might provide a cleaner
mapping to the userspace interface if we ended up doing that some day.

Is there any hard reason why it wouldn't work?

--b.