nfs4_proc_exchange_id() can return -EINVAL if the server reported NFS4INVAL (which I have seen in a packet trace), or nfs4_check_cl_exchange_flags() exchange flags detects a problem. Each of these mean that NFSv4.1 later cannot be use, but they should not prevent fallback to NFSv4.0. Currently this EINVAL error is returned by nfs4_proc_exchange_id() to nfs41_discover_server_trunking(), and thence to nfs4_discover_server_trunking(). nfs4_discover_server_trunking() doesn't understand EINVAL, so converts it to EIO which causes mount.nfs to think something is horribly wrong and to give up. It would be a more graceful failure if nfs4_discover_server_trunking() mapped -EINVAL to -EPROTONOSUPPORT - a failure to negotiate a client ID clearly shows that NFSv4.1 cannot be supported, but isn't as general a failure as EIO. Signed-off-by: NeilBrown <neilb@xxxxxxxx> --- fs/nfs/nfs4state.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/nfs/nfs4state.c b/fs/nfs/nfs4state.c index 91a4d4eeb235..7e237bb9c699 100644 --- a/fs/nfs/nfs4state.c +++ b/fs/nfs/nfs4state.c @@ -2219,6 +2219,8 @@ int nfs4_discover_server_trunking(struct nfs_client *clp, clnt = clp->cl_rpcclient; goto again; + case -NFS4INVAL: + /* Server confused - assume this minor isn't supported */ case -NFS4ERR_MINOR_VERS_MISMATCH: status = -EPROTONOSUPPORT; break; -- 2.14.0.rc0.dirty
Attachment:
signature.asc
Description: PGP signature
