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.he...@intel.com> --- 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; -- To unsubscribe from this list: send the line "unsubscribe linux-rdma" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html