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