On Mon, 2008-04-21 at 13:50 -0400, Chuck Lever wrote: > Hi Trond- > > On Apr 19, 2008, at 4:40 PM, Trond Myklebust wrote: > > ..and always destroy using a 'soft' RPC call. Destroying GSS > > credentials > > isn't mandatory; the server can always cope with a few credentials not > > getting destroyed in a timely fashion. > > These two changes may have different side-effects, but backing out > this patch will revert both changes. Should these be split into > separate patches to facilitate git bisect? See the comment above. Destroying GSS sessions is _not_ mandatory. If there are any side-effects from not destroying them, then that would be a server bug, not a client issue. > > This actually fixes a hang situation. Basically, some servers will > > decide > > that the client is crazy if it tries to destroy an RPC context for > > which > > they have sent an RPCSEC_GSS_CREDPROBLEM, and so will refuse to talk > > to it > > for a while. > > That seems unfriendly. Is this server-side behavior mandated? Why > wouldn't the server just treat an extraneous context destruction > request as a successful no-op? > > You definitely should include an explanation of this server-side > behavior in the documenting comment for gss_destroying_context. 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. -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- 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
