Re: [PATCH 03/33] SUNRPC: Don't attempt to destroy expired RPCSEC_GSS credentials..

["J. Bruce Fields" <bfields@fieldses.org>]

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 <Trond.Myklebust@netapp.com>
> 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 <Trond.Myklebust@netapp.com>
> ---
> 
>  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