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. -- 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
