OSDN Git Service

xprtrdma: Try to fail quickly if proto=rdma
authorChuck Lever <chuck.lever@oracle.com>
Fri, 4 May 2018 19:34:37 +0000 (15:34 -0400)
committerAnna Schumaker <Anna.Schumaker@Netapp.com>
Mon, 7 May 2018 13:20:03 +0000 (09:20 -0400)
commit52d28fe4f61350baf7e84b3f3f3e34f0fc077ec1
treece19bf117d1a0b4c70b93b3f18d23c5014f3fe37
parenta2268cfbf599e7f55d4ee68193f08b4f44535fac
xprtrdma: Try to fail quickly if proto=rdma

rdma_resolve_addr(3) says:

> This call is used to map a given destination IP address to a
> usable RDMA address. The IP to RDMA address mapping is done
> using the local routing tables, or via ARP.

If this can't be done, there's no local device that can be used
to establish an RDMA-capable network path to the remote. In this
case, the RDMA CM very quickly posts an RDMA_CM_EVENT_ADDR_ERROR
upcall.

Currently rpcrdma_conn_upcall() converts RDMA_CM_EVENT_ADDR_ERROR
to EHOSTUNREACH. mount.nfs seems to want to retry EHOSTUNREACH
forever, thinking that this is a temporary situation. This makes
mount.nfs appear to hang if I try to mount with proto=rdma through,
say, a conventional Ethernet device.

If the admin has specified proto=rdma along with a server IP address
that requires a network path that does not support RDMA, instead
let's fail with a permanent error. -EPROTONOSUPPORT is returned when
NFSv4 or one of its minor versions is not supported.

-EPROTO is not (currently) retried by mount.nfs.

There are potentially other similar cases where -EPROTO is an
appropriate return code.

Signed-off-by: Chuck Lever <chuck.lever@oracle.com>
Tested-by: Olga Kornievskaia <kolga@netapp.com>
Tested-by: Anna Schumaker <Anna.Schumaker@netapp.com>
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
net/sunrpc/xprtrdma/verbs.c