From patchwork Thu Aug 4 18:17:35 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Trond Myklebust X-Patchwork-Id: 1036652 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by demeter1.kernel.org (8.14.4/8.14.4) with ESMTP id p74IHumS001041 for ; Thu, 4 Aug 2011 18:17:56 GMT Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755351Ab1HDSRz (ORCPT ); Thu, 4 Aug 2011 14:17:55 -0400 Received: from mx2.netapp.com ([216.240.18.37]:5713 "EHLO mx2.netapp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754816Ab1HDSRz convert rfc822-to-8bit (ORCPT ); Thu, 4 Aug 2011 14:17:55 -0400 X-IronPort-AV: E=Sophos;i="4.67,318,1309762800"; d="scan'208";a="568100169" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 04 Aug 2011 11:17:39 -0700 Received: from sacrsexc2-prd.hq.netapp.com (sacrsexc2-prd.hq.netapp.com [10.99.115.28]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id p74IHdWA001732; Thu, 4 Aug 2011 11:17:39 -0700 (PDT) Received: from SACMVEXC2-PRD.hq.netapp.com ([10.99.115.17]) by sacrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 4 Aug 2011 11:17:37 -0700 Received: from 10.55.68.146 ([10.55.68.146]) by SACMVEXC2-PRD.hq.netapp.com ([10.99.115.16]) with Microsoft Exchange Server HTTP-DAV ; Thu, 4 Aug 2011 18:17:36 +0000 Received: from lade.trondhjem.org by SACMVEXC2-PRD.hq.netapp.com; 04 Aug 2011 14:17:35 -0400 Subject: Re: [NLM] fcntl(F_SETLKW) yields -ENOLCK when grace period expires. From: Trond Myklebust To: Frank van Maarseveen Cc: "J. Bruce Fields" , Linux NFS mailing list Date: Thu, 04 Aug 2011 14:17:35 -0400 In-Reply-To: <20110804172710.GB18087@janus> References: <20110804103018.GA11727@janus> <20110804163452.GE12445@fieldses.org> <20110804164313.GA17572@janus> <20110804164913.GG12445@fieldses.org> <1312477820.8919.5.camel@lade.trondhjem.org> <20110804172710.GB18087@janus> Organization: NetApp Inc X-Mailer: Evolution 3.0.2 (3.0.2-3.fc15) Message-ID: <1312481855.8919.20.camel@lade.trondhjem.org> Mime-Version: 1.0 X-OriginalArrivalTime: 04 Aug 2011 18:17:37.0067 (UTC) FILETIME=[C9E3EFB0:01CC52D2] Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org X-Greylist: IP, sender and recipient auto-whitelisted, not delayed by milter-greylist-4.2.6 (demeter1.kernel.org [140.211.167.41]); Thu, 04 Aug 2011 18:18:25 +0000 (UTC) On Thu, 2011-08-04 at 19:27 +0200, Frank van Maarseveen wrote: > On Thu, Aug 04, 2011 at 01:10:20PM -0400, Trond Myklebust wrote: > > On Thu, 2011-08-04 at 12:49 -0400, J. Bruce Fields wrote: > > > On Thu, Aug 04, 2011 at 06:43:13PM +0200, Frank van Maarseveen wrote: > > > > On Thu, Aug 04, 2011 at 12:34:52PM -0400, J. Bruce Fields wrote: > > > > > On Thu, Aug 04, 2011 at 12:30:19PM +0200, Frank van Maarseveen wrote: > > > > > > Both client- and server run 2.6.39.3, NFSv3 over UDP (without the > > > > > > relock_filesystem patch proposed earlier). > > > > > > > > > > > > A second client has an exclusive lock on a file on the server. The > > > > > > client under test calls fcntl(F_SETLKW) to wait for the same exclusive > > > > > > lock. Wireshark sees NLM V4 LOCK calls resulting in NLM_BLOCKED. > > > > > > > > > > > > Next the server is rebooted. The second client recovers the lock > > > > > > correctly. The client under test now receives NLM_DENIED_GRACE_PERIOD for > > > > > > every NLM V4 LOCK request resulting from the waiting fcntl(F_SETLKW). When > > > > > > this changes to NLM_BLOCKED after grace period expiration the fcntl > > > > > > returns -ENOLCK ("No locks available.") instead of continuing to wait. > > > > > > > > > > So that sounds like a client bug, and correct behavior from the server > > > > > (assuming the second client was still holding the lock throughout). > > > > > > > > yes. > > > > Is the client actually asking for a blocking lock after the grace period > > expires? > > yes, according to my interpretation of that of wireshark, see reply to Bruce. > OK... Does the following patch help? Cheers Trond --- diff --git a/fs/lockd/clntproc.c b/fs/lockd/clntproc.c index 8392cb8..40c0d88 100644 --- a/fs/lockd/clntproc.c +++ b/fs/lockd/clntproc.c @@ -270,6 +270,9 @@ nlmclnt_call(struct rpc_cred *cred, struct nlm_rqst *req, u32 proc) return -ENOLCK; msg.rpc_proc = &clnt->cl_procinfo[proc]; + /* Reset the reply status */ + if (argp->block) + resp->status = nlm_lck_blocked; /* Perform the RPC call. If an error occurs, try again */ if ((status = rpc_call_sync(clnt, &msg, 0)) < 0) { dprintk("lockd: rpc_call returned error %d\n", -status);