[openib-general] possible CMA bug

[Steve Wise]

I've traced it down to cma_ib_listen().  It destroys the cm_id if the 
listen fails.  It probably shouldn't, correct?  IE the cm_id is owned by 
the ULP who called rdma_create_id() and should be destroyed by that 
ULP...

Steve.

--- snipit from cma_ib_listen() ---

        ret = ib_cm_listen(id_priv->cm_id, svc_id, 0);
        if (ret)
                ib_destroy_cm_id(id_priv->cm_id);



----- Original Message ----- 
From: "Steve Wise" <swise at opengridcomputing.com>
To: <openib-general at openib.org>
Sent: Monday, October 31, 2005 2:35 PM
Subject: [openib-general] possible CMA bug


> 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}
>
>
> _______________________________________________
> openib-general mailing list
> openib-general at openib.org
> http://openib.org/mailman/listinfo/openib-general
>
> To unsubscribe, please visit 
> http://openib.org/mailman/listinfo/openib-general
>