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

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

On Thu, Apr 24, 2008 at 01:48:29PM -0400, Trond Myklebust wrote:
> 
> On Wed, 2008-04-23 at 14:19 -0400, J. Bruce Fields wrote:
> > 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.
> 
> The point is that if the _server_ gets confused, then it may not tell us
> that our context is invalid: it will just start dropping all the
> requests that we send it.

So the server miscalculates and thinks the next sequence number should
be millions higher than what we think it should be, for example?  OK,
sure.

--b.