public inbox for linux-nfs@vger.kernel.org
 help / color / mirror / Atom feed
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: Wed, 17 Dec 2008 15:01:56 -0500	[thread overview]
Message-ID: <20081217200156.GO4614@fieldses.org> (raw)
In-Reply-To: <20081217191453.GA16777@redhat.com>

On Wed, Dec 17, 2008 at 01:14:53PM -0600, David Teigland wrote:
> On Tue, Dec 16, 2008 at 04:11:58PM -0500, Jeff Layton wrote:
> > On Tue, 16 Dec 2008 14:56:35 -0500
> > "J. Bruce Fields" <bfields@fieldses.org> wrote:
> > > After thinking a little more: the interface is a lot simpler if it's
> > > just a simple request and reply (with the reply for a lock identical to
> > > the request).  I believe that's more or less what gfs2 is already do
> > > internally, if we look at the posix lock upcalls it's making to
> > > userspace.  So it shouldn't be hard to fix gfs2 to hand us back a lock
> > > that doesn't take into account any coalescing.  If it needs to keep an
> > > extra (unmodified) copy of the lock around, that's OK.
> > > 
> > > Did you try that and find a reason that doesn't work?
> > > 
> > > --b.
> > > 
> > 
> > Agreed. That would be much simpler, I think...
> > 
> > I didn't try that, though I did consider it before wandering down the
> > rabbit hole. Dave, any thoughts?
> 
> Jeff suggested the following patch, which I've tried and it fixes the
> problem I was seeing.  It passes the original, unmodified file_lock to
> notify(), instead of the copy which is passed to (and coalesced by)
> posix_lock_file().  I'm guessing this was reason for having a copy of the
> file_lock in the first place, but it was just not used correctly.

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?

--b.

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,

  reply	other threads:[~2008-12-17 20:01 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 [this message]
2008-12-17 21:28                         ` David Teigland
2009-01-20 23:05                           ` J. Bruce Fields
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=20081217200156.GO4614@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