On Tue, Sep 16, 2014 at 2:51 PM, Fred Isaman <iisaman@xxxxxxxxxx> wrote: > Was a patch ever submitted for this? I'm seeing something similar but can't > find the fix upstream. As far as I can tell, the answer is no. If you are seeing the bug, then could you please post the discussed fix? Cheers TRond > > Fred > > On Tue, Jul 29, 2014 at 5:58 PM, Trond Myklebust > <trond.myklebust@xxxxxxxxxxxxxxx> wrote: >> >> On Tue, Jul 29, 2014 at 4:40 PM, Steve Dickson <SteveD@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- Trond Myklebust Linux NFS client maintainer, PrimaryData trond.myklebust@xxxxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
