[openib-general] possible CMA bug

[Steve Wise]

Hi,

I'm using the new rdma cma interface and i've perhaps stumbled onto a bug.  I'm trying to bind to port 9999 on both IB ports of a 
mthca device.  The IPoIB interfaces for the HCA are configured as two seperate subnets.  The second rdma_listen() always fails with 
EBUSY.  Maybe this is a limitation in the CMA design, but TCP stacks allow binding to the same port on different ip addresses.  And 
the CMA interface allows it too as long as the two ip addresses map to different IB devices.   Whether this should work or not, I am 
seeing a crash when I try to destroy the cm_id after the rdma_listen() failure.

Here is a log of the event (printks from my krping module in branches/iwarp/utils/src/linux-kernel/infiniband/krping).  It seems as 
though the cm_id is being destroyed twice, but I don't think the krping module is doing it...


krping: proc write |verbose,server,addr=192.168.80.154,port=9999|
krping: verbose
krping: server
krping: ipaddr (192.168.80.154), nbo 0x(9a50a8c0)
krping: port hbo 0x270f nbo 0xf27
krping: created cm_id ffff81003f376800
krping: rdma_bind_addr worked
krping: created pd ffff81003feac600
krping: created cq ffff81007a1df080
krping: create listener
krping: rdma_listen error -16
krping: listen error -16
krping: destroying cq ffff81007a1df080
krping: dealloc pd ffff81003feac600
krping: destroy cm_id ffff81003f376800
idr_remove called for id=2 which is not allocated.

Call Trace:<ffffffff801fdc04>{idr_remove+244} <ffffffff88238a88>{:ib_cm:ib_destroy_cm_id+408}
       <ffffffff8013768d>{printk+141} <ffffffff8825f116>{:rdma_cm:cma_exch+70}
       <ffffffff8825f939>{:rdma_cm:rdma_destroy_id+57} <ffffffff880fc4ac>{:ib_mthca:mthca_free+44}
       <ffffffff88100155>{:ib_mthca:mthca_free_mr+213} <ffffffff88268961>{:ib_krping:krping_write_proc+6657}
       <ffffffff8019c739>{__d_lookup+297} <ffffffff8019b556>{dput+54}
       <ffffffff80190dd4>{__follow_mount+52} <ffffffff80190fd4>{do_lookup+100}
       <ffffffff801c0327>{proc_file_write+39} <ffffffff80182659>{vfs_write+233}
       <ffffffff801827f3>{sys_write+83} <ffffffff8010dc76>{system_call+126}