locks: set fl_owner for leases back to current->files
authorJeff Layton <jlayton@poochiereds.net>
Tue, 10 Jun 2014 16:29:05 +0000 (12:29 -0400)
committerJeff Layton <jlayton@poochiereds.net>
Tue, 10 Jun 2014 16:29:05 +0000 (12:29 -0400)
commit0c27362998a8357f199501aa401e99c51c2eb46e
tree11b922376e2574f0586c452cd74495e2c7728c9d
parent962bd40bc30e412828e091bfda041b7547e779c8
locks: set fl_owner for leases back to current->files

This fixes a regression due to commit 130d1f956ab3 (locks: ensure that
fl_owner is always initialized properly in flock and lease codepaths). 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: 130d1f956ab3 (locks: ensure that fl_owner is always initialized properly in flock and lease codepaths)
Signed-off-by: Jeff Layton <jlayton@primarydata.com>
fs/locks.c