SUNRPC: Don't attempt to destroy expired RPCSEC_GSS credentials..
authorTrond Myklebust <Trond.Myklebust@netapp.com>
Sat, 19 Apr 2008 18:22:31 +0000 (14:22 -0400)
committerTrond Myklebust <Trond.Myklebust@netapp.com>
Sat, 19 Apr 2008 20:52:54 +0000 (16:52 -0400)
..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.

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.
The regression therefor probably was introduced by commit
0df7fb74fbb709591301871a38aac7735a1d6583.

Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
net/sunrpc/auth_gss/auth_gss.c

index d34f6dfc75162fca06d07c120ceab8e67a350f22..55948cd5ea5555206644fee20ca259fc189e3ae6 100644 (file)
@@ -710,7 +710,7 @@ gss_destroying_context(struct rpc_cred *cred)
        struct rpc_task *task;
 
        if (gss_cred->gc_ctx == NULL ||
-                       gss_cred->gc_ctx->gc_proc == RPC_GSS_PROC_DESTROY)
+           test_and_clear_bit(RPCAUTH_CRED_UPTODATE, &cred->cr_flags) == 0)
                return 0;
 
        gss_cred->gc_ctx->gc_proc = RPC_GSS_PROC_DESTROY;
@@ -720,7 +720,7 @@ gss_destroying_context(struct rpc_cred *cred)
         * by the RPC call or by the put_rpccred() below */
        get_rpccred(cred);
 
-       task = rpc_call_null(gss_auth->client, cred, RPC_TASK_ASYNC);
+       task = rpc_call_null(gss_auth->client, cred, RPC_TASK_ASYNC|RPC_TASK_SOFT);
        if (!IS_ERR(task))
                rpc_put_task(task);