From mboxrd@z Thu Jan 1 00:00:00 1970 From: "J. Bruce Fields" Subject: Re: [PATCH 03/33] SUNRPC: Don't attempt to destroy expired RPCSEC_GSS credentials.. Date: Wed, 23 Apr 2008 14:19:35 -0400 Message-ID: <20080423181935.GC5280@fieldses.org> References: <20080419204047.14124.49490.stgit@c-69-242-210-120.hsd1.mi.comcast.net> <20080419204047.14124.64969.stgit@c-69-242-210-120.hsd1.mi.comcast.net> <1208822443.7767.23.camel@heimdal.trondhjem.org> <86898638-C54D-44F7-917E-1EDF6795B56C@oracle.com> <1208876800.11982.6.camel@heimdal.trondhjem.org> <1208960443.7459.9.camel@heimdal.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Chuck Lever , linux-nfs@vger.kernel.org To: Trond Myklebust Return-path: Received: from mail.fieldses.org ([66.93.2.214]:53421 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757590AbYDWSTy (ORCPT ); Wed, 23 Apr 2008 14:19:54 -0400 In-Reply-To: <1208960443.7459.9.camel-rJ7iovZKK19ZJLDQqaL3InhyD016LWXt@public.gmane.org> Sender: linux-nfs-owner@vger.kernel.org List-ID: On Wed, Apr 23, 2008 at 10:20:43AM -0400, Trond Myklebust wrote: > > On Tue, 2008-04-22 at 11:11 -0400, Trond Myklebust wrote: > > On Tue, 2008-04-22 at 09:38 -0400, Chuck Lever wrote: > > > > RFC-2203 states that servers are supposed to silently discard requests > > > > that they don't recognise (see section 5.3.3.1 - Context > > > > Management), so > > > > it is correct server behaviour. > > > > > > > > > Dropping the request to destroy a context is fine. Temporarily > > > fencing the client is what I was concerned about. > > > > I'd agree that is somewhat drastic, and have passed the information on > > to the server vendor, however that doesn't change the fact that we have > > a client bug too: we should not be using expired creds. > > > > The client side performance problem was compounded by the fact that the > > RPCSEC_GSS destruction call was sent as a hard RPC call, and the fact > > that we impose the NFSv4 rule that we need to drop the connection before > > resending a request. > > Having thought a bit more about the consequences of this RFC, I think we > also need to drop the credential on (major) timeouts, since we need to > assume that the timeout may be due to the credential being out of > sequence. I'm a little confused. Each resend is done with a new gss sequence number. --b. > > --------------------------------------------- > From: Trond Myklebust > Date: Tue, 22 Apr 2008 16:47:55 -0400 > SUNRPC: Invalidate the RPCSEC_GSS session if the server dropped the request > > RFC 2203 requires the server to drop the request if it believes the > RPCSEC_GSS context is out of sequence. The problem is that we have no way > on the client to know why the server dropped the request. In order to avoid > spinning forever trying to resend the request, the safe approach is > therefore to always invalidate the RPCSEC_GSS context on every major > timeout. > > Signed-off-by: Trond Myklebust > --- > > net/sunrpc/clnt.c | 5 +++++ > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/net/sunrpc/clnt.c b/net/sunrpc/clnt.c > index 2969e84..eb813e9 100644 > --- a/net/sunrpc/clnt.c > +++ b/net/sunrpc/clnt.c > @@ -1169,6 +1169,11 @@ call_timeout(struct rpc_task *task) > clnt->cl_protname, clnt->cl_server); > } > rpc_force_rebind(clnt); > + /* > + * Did our request time out due to an RPCSEC_GSS out-of-sequence > + * event? RFC2203 requires the server to drop all such requests. > + */ > + rpcauth_invalcred(task); > > retry: > clnt->cl_stats->rpcretrans++; > > > -- > Trond Myklebust > Linux NFS client maintainer > > NetApp > Trond.Myklebust@netapp.com > www.netapp.com > -- > To unsubscribe from this list: send the line "unsubscribe linux-nfs" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html