From: Marc Eshel <[email protected]> - unquoted
The nfsv4 protocol's lock operation, in the case of a conflict, returns
information about the conflicting lock.
It's unclear how clients can use this, so for now we're not going so far as to
add a filesystem method that can return a conflicting lock, but we may as well
return something in the local case when it's easy to.
Signed-off-by: "J. Bruce Fields" <[email protected]>
---
fs/locks.c | 18 ++++++++++++++++++
include/linux/lockd/bind.h | 1 +
2 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index c88139d..1bd6418 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -1706,6 +1706,24 @@ int vfs_lock_file(struct file *filp, unsigned int cmd, struct file_lock *fl)
}
EXPORT_SYMBOL(vfs_lock_file);
+/**
+ * vfs_lock_file_conf - file byte range lock
+ * @filp: The file to apply the lock to
+ * @fl: The lock to be applied
+ * @conf: Place to return a copy of the conflicting lock, if found.
+ *
+ * read comments for vfs_lock_file()
+ */
+int vfs_lock_file_conf(struct file *filp, struct file_lock *fl, struct file_lock *conf)
+{
+ if (filp->f_op && filp->f_op->lock) {
+ __locks_copy_lock(conf, fl);
+ return filp->f_op->lock(filp, F_SETLK, fl);
+ } else
+ return posix_lock_file_conf(filp, fl, conf);
+}
+EXPORT_SYMBOL(vfs_lock_file_conf);
+
/* Apply the lock described by l to an open file descriptor.
* This implements both the F_SETLK and F_SETLKW commands of fcntl().
*/
diff --git a/include/linux/lockd/bind.h b/include/linux/lockd/bind.h
index c88da8e..01c25e4 100644
--- a/include/linux/lockd/bind.h
+++ b/include/linux/lockd/bind.h
@@ -40,5 +40,6 @@ extern void lockd_down(void);
extern int vfs_test_lock(struct file *, struct file_lock *, struct file_lock *);
extern int vfs_lock_file(struct file *, int cmd, struct file_lock *);
+extern int vfs_lock_file_conf(struct file *, struct file_lock *, struct file_lock *);
#endif /* LINUX_LOCKD_BIND_H */
--
1.5.0.rc1.g72fe
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Sat, Feb 03, 2007 at 12:34:00AM -0500, J. Bruce Fields wrote:
> From: Marc Eshel <[email protected]> - unquoted
>
> The nfsv4 protocol's lock operation, in the case of a conflict, returns
> information about the conflicting lock.
>
> It's unclear how clients can use this, so for now we're not going so far as to
> add a filesystem method that can return a conflicting lock, but we may as well
> return something in the local case when it's easy to.
>
> Signed-off-by: "J. Bruce Fields" <[email protected]>
> ---
> fs/locks.c | 18 ++++++++++++++++++
> include/linux/lockd/bind.h | 1 +
> 2 files changed, 19 insertions(+), 0 deletions(-)
>
> diff --git a/fs/locks.c b/fs/locks.c
> index c88139d..1bd6418 100644
> --- a/fs/locks.c
> +++ b/fs/locks.c
> @@ -1706,6 +1706,24 @@ int vfs_lock_file(struct file *filp, unsigned int cmd, struct file_lock *fl)
> }
> EXPORT_SYMBOL(vfs_lock_file);
>
> +/**
> + * vfs_lock_file_conf - file byte range lock
> + * @filp: The file to apply the lock to
> + * @fl: The lock to be applied
> + * @conf: Place to return a copy of the conflicting lock, if found.
> + *
> + * read comments for vfs_lock_file()
> + */
> +int vfs_lock_file_conf(struct file *filp, struct file_lock *fl, struct file_lock *conf)
> +{
> + if (filp->f_op && filp->f_op->lock) {
> + __locks_copy_lock(conf, fl);
> + return filp->f_op->lock(filp, F_SETLK, fl);
> + } else
> + return posix_lock_file_conf(filp, fl, conf);
> +}
> +EXPORT_SYMBOL(vfs_lock_file_conf);
Is there any reason we want to have both variants? I think vfs_lock_file
should simple get the last argument and we shouldn't have a separate
vfs_lock_file_conf (which btw doesn't have an exactly descriptive name).
The also allows you to kill __posix_lock_file_conf and only keep a single
posix_lock_file routines that gets the argument aswell.
And btw, in case you ask why I demand all these addition cleanuos:
you're touching an already more than messy codebase and make it more
complex, that needs some cleanups to counterbalance :)
On Sat, Feb 03, 2007 at 08:54:50AM +0000, Christoph Hellwig wrote:
> Is there any reason we want to have both variants? I think vfs_lock_file
> should simple get the last argument and we shouldn't have a separate
> vfs_lock_file_conf (which btw doesn't have an exactly descriptive name).
> The also allows you to kill __posix_lock_file_conf and only keep a single
> posix_lock_file routines that gets the argument aswell.
That sounds reasonable.
> And btw, in case you ask why I demand all these addition cleanuos:
> you're touching an already more than messy codebase and make it more
> complex, that needs some cleanups to counterbalance :)
I find locks.c really hard to read, so I'm happy for any suggestions for
cleanups....
--b.