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
