Return-Path: linux-nfs-owner@vger.kernel.org Received: from mail-vc0-f173.google.com ([209.85.220.173]:53575 "EHLO mail-vc0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754240AbaG2V6F (ORCPT ); Tue, 29 Jul 2014 17:58:05 -0400 Received: by mail-vc0-f173.google.com with SMTP id hy10so549367vcb.4 for ; Tue, 29 Jul 2014 14:58:03 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <53D806C1.9030206@RedHat.com> References: <53D7EA62.3070204@RedHat.com> <53D806C1.9030206@RedHat.com> Date: Tue, 29 Jul 2014 17:58:03 -0400 Message-ID: Subject: Re: nfs4_state_manager() vs. nfs_server_remove_lists() From: Trond Myklebust To: Steve Dickson Cc: Linux NFS Mailing list , Andy Adamson Content-Type: text/plain; charset=UTF-8 Sender: linux-nfs-owner@vger.kernel.org List-ID: On Tue, Jul 29, 2014 at 4:40 PM, Steve Dickson wrote: > On 29/07/14 15:52, Trond Myklebust wrote: >> Let's just move up the test for "pos->rpc_ops != new->rpc_ops", >> "pos->cl_minorversion != new->cl_minorversion" and "pos->cl_proto != >> new->cl_proto" so that they all happen before we try to test the value >> of cl_cons_state. >> As far as I can tell, all those values are guaranteed to be set as >> part of the struct nfs_client allocators, before we ever put the >> result on the cl_share_link list. > > The check for > if (pos->cl_cons_state > NFS_CS_READY) > > then right after that check is: > > if (pos->cl_cons_state != NFS_CS_READY) > continue; > > confuses me... Is the second check even needed? > > steved. Yes. The result of the lease_recovery could be that the nfs_client is left in a state of error if, say, we get a NFS4ERR_CLID_INUSE beastie. Cheers Trond -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@primarydata.com