On Tue, 10 Jun 2014 16:53:43 -0400 "J. Bruce Fields" <bfields@xxxxxxxxxxxx> wrote: > On Tue, Jun 10, 2014 at 04:14:36PM -0400, Jeff Layton wrote: > > 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. > > ACK to restoring the old behavior, but meanwhile I'm pretty confused by > the old behavior. > Same here. Until we can untangle the history, it's probably best to not change anything. I suspect that it might be best to just get rid of that check, but it predates git so it might take some digging to understand the original rationale. > > Fixes: > > Did you mean to have a 130d1f956ab3 there? > Yes, thanks. Fixed in my tree... > --b. > > > 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 > > -- Jeff Layton <jlayton@xxxxxxxxxxxxxxx> -- 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
