When i_flock contains only flocks, the posix unlock is
extraneous. On gfs2, ocfs2, and possibly others, the
posix unlock can be costly, and something to avoid if
possible.
As the comment implies, there will be races here. The
question is, do those races become harmful with this
new loop?
Signed-off-by: David Teigland <teigland@xxxxxxxxxx>
---
fs/locks.c | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/fs/locks.c b/fs/locks.c
index 703f545..4507401 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -1982,15 +1982,27 @@ out:
void locks_remove_posix(struct file *filp, fl_owner_t owner)
{
struct file_lock lock;
+ struct file_lock **before;
+ struct inode *inode;
/*
* If there are no locks held on this file, we don't need to call
* posix_lock_file(). Another process could be setting a lock on this
* file at the same time, but we wouldn't remove that lock anyway.
*/
- if (!filp->f_path.dentry->d_inode->i_flock)
+ inode = filp->f_path.dentry->d_inode;
+
+ if (!inode->i_flock)
return;
+ for_each_lock(inode, before) {
+ struct file_lock *fl = *before;
+ if (IS_POSIX(fl))
+ goto do_unlock;
+ }
+ return;
+
+do_unlock:
lock.fl_type = F_UNLCK;
lock.fl_flags = FL_POSIX | FL_CLOSE;
lock.fl_start = 0;
--
1.7.6
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
