vfs: don't treat fl_type as a bitmap
authorJeff Layton <jlayton@redhat.com>
Thu, 2 Aug 2012 19:46:30 +0000 (15:46 -0400)
committerJ. Bruce Fields <bfields@redhat.com>
Mon, 20 Aug 2012 22:39:42 +0000 (18:39 -0400)
The rules for fl_type are rather convoluted. Typically it's treated as
holding specific values, except in the case of LOCK_MAND, in which case
it can be or'ed with LOCK_READ|LOCK_WRITE.

On some arches F_WRLCK == 2 and F_UNLCK == 3, so and'ing with F_WRLCK will also
catch the F_UNLCK case. It's unlikely in either case here that we'd ever see
F_UNLCK since those shouldn't end up on any lists, but it's still best to be
consistent.

Signed-off-by: Jeff Layton <jlayton@redhat.com>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
fs/locks.c

index 7e81bfc..669911e 100644 (file)
@@ -1289,7 +1289,7 @@ EXPORT_SYMBOL(__break_lease);
 void lease_get_mtime(struct inode *inode, struct timespec *time)
 {
        struct file_lock *flock = inode->i_flock;
-       if (flock && IS_LEASE(flock) && (flock->fl_type & F_WRLCK))
+       if (flock && IS_LEASE(flock) && (flock->fl_type == F_WRLCK))
                *time = current_fs_time(inode->i_sb);
        else
                *time = inode->i_mtime;
@@ -2187,8 +2187,8 @@ static void lock_get_status(struct seq_file *f, struct file_lock *fl,
        } else {
                seq_printf(f, "%s ",
                               (lease_breaking(fl))
-                              ? (fl->fl_type & F_UNLCK) ? "UNLCK" : "READ "
-                              : (fl->fl_type & F_WRLCK) ? "WRITE" : "READ ");
+                              ? (fl->fl_type == F_UNLCK) ? "UNLCK" : "READ "
+                              : (fl->fl_type == F_WRLCK) ? "WRITE" : "READ ");
        }
        if (inode) {
 #ifdef WE_CAN_BREAK_LSLK_NOW