This fixes a regression due to commit 130d1f956ab3. I had mistakenly
thought that the fl_owner wasn't used in the lease code, but I missed
the place in __break_lease that does use it.
The i_have_this_lease check in generic_add_lease uses it. While I'm not
sure that check is terribly helpful [1], reset it back to using
current->files in order to ensure that there's no behavior change here.
[1]: leases are owned by the file description. It's possible that this
is a threaded program, and the lease breaker and the task that
would handle the signal are different, even if they have the same
file table. So, there is the potential for false positives with
this check.
Fixes:
Signed-off-by: Jeff Layton <jlayton@xxxxxxxxxxxxxxx>
---
fs/locks.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/locks.c b/fs/locks.c
index da57c9b7e844..717fbc404e6b 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -431,7 +431,7 @@ static int lease_init(struct file *filp, long type, struct file_lock *fl)
if (assign_type(fl, type) != 0)
return -EINVAL;
- fl->fl_owner = (fl_owner_t)filp;
+ fl->fl_owner = (fl_owner_t)current->files;
fl->fl_pid = current->tgid;
fl->fl_file = filp;
--
1.9.3
--
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
