From: "J. Bruce Fields" <bfields@fieldses.org>
To: David Teigland <teigland@redhat.com>
Cc: Jeff Layton <jlayton@redhat.com>, linux-nfs@vger.kernel.org
Subject: Re: [PATCH] lockd: handle fl_grant callbacks with coalesced locks (RFC)
Date: Tue, 20 Jan 2009 18:05:48 -0500 [thread overview]
Message-ID: <20090120230548.GA28500@fieldses.org> (raw)
In-Reply-To: <20081217212827.GB16777@redhat.com>
Sorry for the delay responding!
On Wed, Dec 17, 2008 at 03:28:27PM -0600, David Teigland wrote:
> On Wed, Dec 17, 2008 at 03:01:56PM -0500, J. Bruce Fields wrote:
> > Yep, that looks much better. Though actually I suspect what was really
> > intended was to use "flc" for the notifies, and "fl" for the
> > posix_lock_file().
> >
> > Also, since flc is never actually handed to the posix lock system, I
> > think it should be a "shallow" lock copy--so it should be created with
> > __locks_copy_lock(). Something like the below?
>
> With this I'm back to seeing the same problem, but with the mismatch in
> the reverse direction.
>
> It seems fl points to lockd's file_lock, and that lockd expects notify()
> will be called with a pointer to a file_lock that matches one of its own.
> Based on that I think we'd always pass fl to notify().
The lockd grant function that's called is nlmsvc_grant_deferred(), and
it uses the passed-in fl only in nlm_compare_locks().
Perhaps the problem is that the posix_lock_file() modifies the original
file lock which lockd is also holding a pointer to, and thus the
coalescing has also changed the lock that *lockd*'s sees?
--b.
>
> The question then is whether lockd's file_lock should be coalesced or not.
> If so, we'd pass fl to posix_lock_file(). If not, we'd pass flc to
> posix_lock_file(). In both cases, fl would be passed to notify() and
> would match. In the former case, I don't see much purpose for flc to even
> exist. The patch I sent was the later case.
>
> In the original code, we coalesce flc which then fails to match the
> original (fl) in lockd. In your patch, we coalesce fl which then fails to
> match the copy of the original (flc).
>
> Dave
>
> >
> > diff --git a/fs/dlm/plock.c b/fs/dlm/plock.c
> > index eba87ff..e8d9086 100644
> > --- a/fs/dlm/plock.c
> > +++ b/fs/dlm/plock.c
> > @@ -103,7 +103,7 @@ int dlm_posix_lock(dlm_lockspace_t *lockspace, u64 number, struct file *file,
> > op->info.owner = (__u64) fl->fl_pid;
> > xop->callback = fl->fl_lmops->fl_grant;
> > locks_init_lock(&xop->flc);
> > - locks_copy_lock(&xop->flc, fl);
> > + __locks_copy_lock(&xop->flc, fl);
> > xop->fl = fl;
> > xop->file = file;
> > } else {
> > @@ -173,8 +173,8 @@ static int dlm_plock_callback(struct plock_op *op)
> > }
> >
> > /* got fs lock; bookkeep locally as well: */
> > - flc->fl_flags &= ~FL_SLEEP;
> > - if (posix_lock_file(file, flc, NULL)) {
> > + fl->fl_flags &= ~FL_SLEEP;
> > + if (posix_lock_file(file, fl, NULL)) {
> > /*
> > * This can only happen in the case of kmalloc() failure.
> > * The filesystem's own lock is the authoritative lock,
next prev parent reply other threads:[~2009-01-20 23:05 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-19 21:37 [PATCH] lockd: handle fl_grant callbacks with coalesced locks (RFC) Jeff Layton
2008-11-22 1:15 ` J. Bruce Fields
2008-11-24 15:33 ` Jeff Layton
[not found] ` <20081124103313.0c779324-RtJpwOs3+0O+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2008-11-24 17:06 ` J. Bruce Fields
2008-11-25 15:12 ` Jeff Layton
2008-12-13 12:40 ` Jeff Layton
[not found] ` <20081213074042.2e8223c3-RtJpwOs3+0O+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2008-12-16 19:38 ` J. Bruce Fields
2008-12-16 19:56 ` J. Bruce Fields
2008-12-16 21:11 ` Jeff Layton
[not found] ` <20081216161158.2d173667-RtJpwOs3+0O+kQycOl6kW4xkIHaj4LzF@public.gmane.org>
2008-12-17 19:14 ` David Teigland
2008-12-17 20:01 ` J. Bruce Fields
2008-12-17 21:28 ` David Teigland
2009-01-20 23:05 ` J. Bruce Fields [this message]
2009-01-20 23:15 ` J. Bruce Fields
2009-01-15 16:30 ` David Teigland
2009-01-19 22:54 ` David Teigland
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=20090120230548.GA28500@fieldses.org \
--to=bfields@fieldses.org \
--cc=jlayton@redhat.com \
--cc=linux-nfs@vger.kernel.org \
--cc=teigland@redhat.com \
/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