locks: set fl_owner for leases back to current->files
This fixes a regression due to commit130d1f956a
(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:130d1f956a
(locks: ensure that fl_owner is always initialized properly in flock and lease codepaths) Signed-off-by: Jeff Layton <jlayton@primarydata.com>
This commit is contained in:
parent
962bd40bc3
commit
0c27362998
|
@ -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;
|
||||
|
|
Loading…
Reference in New Issue