A few weeks ago I reported a problem with calling rpcauth_create() in a loop to serially replace an RPC transport's with different flavors. When the loop gets up to the GSS flavors, the second GSS flavor in the list can't be created. rpcauth_create() fails with -EEXIST. See: http://marc.info/?t=134073471800002&r=1&w=2 rpcauth_create() invokes the rpc_auth ->create operation first then releases the old rpc_auth. But the old rpc_auth is holding onto upcall pipes, which prevents the new GSS rpc_auth from creating its own upcall pipes. This breaks our client's SECINFO implementation, and will also break UCS server trunking discovery when it appears. Trond proposed a solution in the same e-mail thread, but it was archived uuencoded. Here is his suggestion in human-readable form: > The solution here would be to create a per-rpc_client, per-pipename > shared 'rpcsec_gss_pipe' object that holds the upcall pipe data. Here's my crack at this idea. This post is a request for comments; more testing is needed. --- Chuck Lever (3): SUNRPC: Share upcall pipes among an rpc_clnt's rpc_auth objects SUNRPC: Insert a shim under gss_create() SUNRPC: Prepare gss_pipes_dentries_create() for sharing pipe data include/linux/sunrpc/clnt.h | 1 net/sunrpc/auth_gss/auth_gss.c | 232 ++++++++++++++++++++++++++++++++-------- net/sunrpc/clnt.c | 1 3 files changed, 189 insertions(+), 45 deletions(-) -- Chuck Lever -- 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
