On Apr 4, 2013, at 1:55 PM, "Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx> wrote: > On Thu, 2013-04-04 at 13:29 -0700, Chuck Lever wrote: >> On Apr 4, 2013, at 1:17 PM, Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> wrote: >> >>> If the rpcsec_gss_krb5 module cannot be loaded, the attempt to create >>> an rpc_client in nfs4_init_client will currently fail with an EINVAL. >>> Fix is to retry with AUTH_NULL. >>> >>> Regression introduced by the commit "NFS: Use "krb5i" to establish NFSv4 >>> state whenever possible" >>> >>> Signed-off-by: Trond Myklebust <Trond.Myklebust@xxxxxxxxxx> >>> Cc: Chuck Lever <chuck.lever@xxxxxxxxxx> >>> Cc: Bryan Schumaker <bjschuma@xxxxxxxxxx> >>> --- >>> fs/nfs/nfs4client.c | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/fs/nfs/nfs4client.c b/fs/nfs/nfs4client.c >>> index bb9789e..a4f2100 100644 >>> --- a/fs/nfs/nfs4client.c >>> +++ b/fs/nfs/nfs4client.c >>> @@ -200,6 +200,8 @@ struct nfs_client *nfs4_init_client(struct nfs_client *clp, >>> >>> __set_bit(NFS_CS_DISCRTRY, &clp->cl_flags); >>> error = nfs_create_rpc_client(clp, timeparms, RPC_AUTH_GSS_KRB5I); >> >> The parameters passed to nfs_create_rpc_client() are all valid here, so -EINVAL is not a good error value in this situation. >> >> rpcauth_create(), I think, should return -EACCES in this case, rather than -EINVAL. > > I disagree. This isn't an issue of something being denied permission to > access a resource: it is that the flavour does not correspond to > anything in the kernel's list of valid auth flavours. > > Either way, that is a separate issue that shouldn't affect this patch. Fair enough. -ENOENT might be a stronger choice in this case. But yes, changing the API contract of rpcauth_auth() can be done later in an independent change. However -EACCES is returned in some cases from the flavor's create method. Instead of checking for -EINVAL in particular, how about retrying nfs_create_rpc_client() with AUTH_NULL if error < 0 ? > > -- > 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
