On Jan 30, 2013, at 2:55 PM, "Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx> wrote: >> diff --git a/net/sunrpc/auth.c b/net/sunrpc/auth.c index 32e305b..0cfffbc >> 100644 >> --- a/net/sunrpc/auth.c >> +++ b/net/sunrpc/auth.c >> @@ -157,6 +157,41 @@ rpcauth_lookup_gss_pseudoflavor(struct >> rpcsec_gss_info *info) >> EXPORT_SYMBOL_GPL(rpcauth_lookup_gss_pseudoflavor); >> >> /** >> + * rpcauth_lookup_gss_info - find GSS tuple matching a pseudoflavor >> + * @pseudoflavor: GSS pseudoflavor to match >> + * @info: rpcsec_gss_info structure to fill in >> + * >> + * Returns zero and fills in "info" if pseudoflavor matches a >> + * supported mechanism. >> + */ >> +int >> +rpcauth_lookup_gss_info(rpc_authflavor_t pseudoflavor, struct >> +rpcsec_gss_info *info) { >> + const struct rpc_authops *ops; >> + int result; >> + >> + if ((ops = auth_flavors[pseudoflavor]) == NULL) >> + request_module("rpc-auth-%u", RPC_AUTH_GSS); >> + spin_lock(&rpc_authflavor_lock); >> + ops = auth_flavors[pseudoflavor]; >> + if (ops == NULL || !try_module_get(ops->owner)) { >> + spin_unlock(&rpc_authflavor_lock); >> + dprintk("RPC: %s: failed to pin module\n", __func__); >> + return -ENOMEM; > > Wouldn't ENOENT make more sense? This isn't a memory allocation issue. I wasn't sure what to return here. -ENOENT is fine by me. -- Chuck Lever chuck[dot]lever[at]oracle[dot]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