From: Jeff Layton <jlayton@poochiereds.net>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH 2/2] locks: set fl_owner for leases back to current->files
Date: Tue, 10 Jun 2014 16:59:11 -0400 [thread overview]
Message-ID: <20140610165911.2ddc7fcb@f20.localdomain> (raw)
In-Reply-To: <20140610205343.GM3957@fieldses.org>
On Tue, 10 Jun 2014 16:53:43 -0400
"J. Bruce Fields" <bfields@fieldses.org> 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@primarydata.com>
> > ---
> > 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@poochiereds.net>
prev parent reply other threads:[~2014-06-10 20:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-10 20:14 [PATCH 0/2] locks: some small locks.c fixups for v3.16 Jeff Layton
2014-06-10 20:14 ` [PATCH 1/2] locks: add missing memory barrier in break_deleg Jeff Layton
2014-06-10 20:48 ` J. Bruce Fields
2014-06-10 21:05 ` Jeff Layton
2014-06-10 20:14 ` [PATCH 2/2] locks: set fl_owner for leases back to current->files Jeff Layton
2014-06-10 20:53 ` J. Bruce Fields
2014-06-10 20:59 ` Jeff Layton [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140610165911.2ddc7fcb@f20.localdomain \
--to=jlayton@poochiereds.net \
--cc=bfields@fieldses.org \
--cc=linux-fsdevel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).