From: "J. Bruce Fields" <bfields@fieldses.org>
Subject: Re: [PATCH RFC 1/1] NLM GRANTED callback race
Date: Wed, 17 Oct 2007 18:25:49 -0400
Message-ID: <20071017222549.GQ2328@fieldses.org>
References: <EXNANE01OSQeSOzNCWb00000734@exnane01.hq.netapp.com>
	<1192639478.7573.50.camel@heimdal.trondhjem.org>
	<EXNANE013Bma4RCIlWr00000742@exnane01.hq.netapp.com>
	<20071017192340.GK2328@fieldses.org>
	<EXNANE01NMjiGwYt7yi00000750@exnane01.hq.netapp.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: nfs@lists.sourceforge.net
To: "Talpey, Thomas" <Thomas.Talpey@netapp.com>
In-Reply-To: <EXNANE01NMjiGwYt7yi00000750@exnane01.hq.netapp.com>
Sender: nfs-bounces@lists.sourceforge.net
Errors-To: nfs-bounces@lists.sourceforge.net

On Wed, Oct 17, 2007 at 05:15:10PM -0400, Talpey, Thomas wrote:
> At 03:23 PM 10/17/2007, J. Bruce Fields wrote:
> >> BTW, the Linux server discards unsent NLM_GRANTED callbacks when
> >> the client is granted a lock in its retry case. But it performs no such
> >> checking on any responses that arrive from prior sends (see
> >> fs/lockd/svclock.c nlmsvc_grant_reply() and nlmsvc_unlink_block()).
> >> It simply processes the next blocked lock, as I described.
> >
> >I don't understand.  As far as I can tell, the server acquires a lock
> >locally at the time it sends the GRANT, and it never unlocks in the code
> >that handles replies to the grant.  Note that nlmsvc_unlink_block() just
> >remove the data structures that track the blocked (not-yet-acquired)
> >lock, and is (err, I hope) more or less a no-op in the case the lock in
> >question is already acquired.
> 
> I don't fully understand the Linux server nlm code either, but I am sure
> it suffers a similar problem, because it ends up with locks in different
> state between client and server.

OK.  But it's possible it might be a slightly different race?  Your
description of the race certainly doesn't match my understanding of the
server nlm code, but of course it's possible I could be missing
something.

> I'm happy to help you with fixing the server in conjunction with this.
> It's relatively easy to recreate it with a couple of clients and some
> error injection.

That would be great, thanks!

--b.

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs