On Thu, 2007-05-10 at 18:38 -0400, J. Bruce Fields wrote: > In 9d6a8c5c213e34c475e72b245a8eb709258e968c we changed posix_test_lock > to modify its single file_lock argument instead of taking separate input > and output arguments. This makes it no longer safe to set the output > lock's fl_type to F_UNLCK before looking for a conflict, since that > means searching for a conflict against a lock with type F_UNLCK. > > This fixes a regression which causes F_GETLK to incorrectly report no > conflict on most filesystems (including any filesystem that doesn't do > its own locking). > > Also fix posix_lock_to_flock() to copy the lock type. This isn't > strictly necessary, since the caller already does this; but it seems > less likely to cause confusion in the future. > > Thanks to Doug Chapman for the bug report. > > Signed-off-by: "J. Bruce Fields" <[EMAIL PROTECTED]> > --- > fs/locks.c | 5 +++-- > 1 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/fs/locks.c b/fs/locks.c > index 671a034..8ec16ab 100644 > --- a/fs/locks.c > +++ b/fs/locks.c > @@ -669,7 +669,6 @@ posix_test_lock(struct file *filp, struct file_lock *fl) > { > struct file_lock *cfl; > > - fl->fl_type = F_UNLCK; > lock_kernel(); > for (cfl = filp->f_path.dentry->d_inode->i_flock; cfl; cfl = > cfl->fl_next) { > if (!IS_POSIX(cfl)) > @@ -681,7 +680,8 @@ posix_test_lock(struct file *filp, struct file_lock *fl) > __locks_copy_lock(fl, cfl); > unlock_kernel(); > return 1; > - } > + } else > + fl->fl_type = F_UNLCK; > unlock_kernel(); > return 0; > } > @@ -1632,6 +1632,7 @@ static int posix_lock_to_flock(struct flock *flock, > struct file_lock *fl) > flock->l_len = fl->fl_end == OFFSET_MAX ? 0 : > fl->fl_end - fl->fl_start + 1; > flock->l_whence = 0; > + flock->l_type = fl->fl_type; > return 0; > } >
I tested this both with my little hacked up test program as well as with the LTP tests. Looks good. Nice job on the quick turnaround on this Bruce. - Doug - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/