[PATCH] [for-2.6.33] rdma/cm: revert associating an RDMA device when binding to loopback

Sean Hefty
2010-02-09T00:41:15Z

Revert the following change from commit
6f8372b69c3198e06cecb1df2cb9682d0c55e657:

The defined behavior of rdma_bind_addr is to associate an RDMA
device with an rdma_cm_id, as long as the user specified a non-
zero address. (ie they weren't just trying to reserve a port)
Currently, if the loopback address is passed to rdma_bind_addr,
no device is associated with the rdma_cm_id. Fix this.

It turns out that openmpi depends on rdma_bind_addr NOT associating
any RDMA device when binding to a loopback address. Openmpi is
being updated to correct this, but until a new openmpi release is
available, maintain the previous behavior: allow rdma_bind_addr to
succeed, but do not bind to a device.

Signed-off-by: Sean Hefty <sean.hefty-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
---
I believe this patch comes the closest to matching the behavior of
rdma_bind_addr from 2.6.32 and before without completely reverting
all support for loopback connections. Loopback connections will
work, but rdma_bind_addr will not automatically select an RDMA
device if given a loopback address.

Steve, can you test this with iwarp and openmpi, and ack it if it
works for you?

drivers/infiniband/core/cma.c | 4 +---
1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/drivers/infiniband/core/cma.c b/drivers/infiniband/core/cma.c
index cc9b594..875e34e 100644
--- a/drivers/infiniband/core/cma.c
+++ b/drivers/infiniband/core/cma.c
@@ -2115,9 +2115,7 @@ int rdma_bind_addr(struct rdma_cm_id *id, struct sockaddr *addr)
if (ret)
goto err1;

- if (cma_loopback_addr(addr)) {
- ret = cma_bind_loopback(id_priv);
- } else if (!cma_zero_addr(addr)) {
+ if (!cma_any_addr(addr)) {
ret = rdma_translate_ip(addr, &id->route.addr.dev_addr);
if (ret)
goto err1;