From: "Talpey, Thomas" Subject: Re: [PATCH RFC 1/1] NLM GRANTED callback race Date: Wed, 17 Oct 2007 17:15:10 -0400 Message-ID: References: <1192639478.7573.50.camel@heimdal.trondhjem.org> <20071017192340.GK2328@fieldses.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: nfs@lists.sourceforge.net To: "J. Bruce Fields" Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.91] helo=mail.sourceforge.net) by sc8-sf-list2-new.sourceforge.net with esmtp (Exim 4.43) id 1IiGLW-0000Hh-Kd for nfs@lists.sourceforge.net; Wed, 17 Oct 2007 14:22:30 -0700 Received: from mx2.netapp.com ([216.240.18.37]) by mail.sourceforge.net with esmtp (Exim 4.44) id 1IiGLb-0003hY-Ul for nfs@lists.sourceforge.net; Wed, 17 Oct 2007 14:22:36 -0700 In-Reply-To: <20071017192340.GK2328@fieldses.org> References: <1192639478.7573.50.camel@heimdal.trondhjem.org> <20071017192340.GK2328@fieldses.org> List-Id: "Discussion of NFS under Linux development, interoperability, and testing." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: nfs-bounces@lists.sourceforge.net Errors-To: nfs-bounces@lists.sourceforge.net 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. 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. Tom. ------------------------------------------------------------------------- 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