[ofa-general] Re: [PATCH 2.6.24] rdma/cm: fix deadlock destroyinglisten requests

[Kanoj Sarcar]

Sean Hefty wrote:

>>I don't understand your response. ucma.c for example can call
>>rdma_create_id() and rdma_destroy_id(), correct? What says that when
>>ucma.c does a rdma_destroy_id() on a nonwildcard listener, a device
>>removal is not attempting to do the same on the listener? If this is
>>possible, the code paths I mentioned above can still trigger a double
>>destruct on a listener, correct?
>>    
>>
>
>Device removal only automatically destroys internal listens, and a non-wildcard
>listen would never generate an internal listen.  Internal listens are used to
>  
>
Oh, ok.

I must be missing something though. cma_process_remove() goes thru the 
device's id_list, and non-wildcard listeners do show up on this list 
(say thru rdma_bind_addr() -> cma_acquire_dev() -> cma_attach_to_dev()). 
So, cma_process_remove() would end up attempting a rdma_destroy_id(), no?

Wait, I see ... cma_remove_id_dev() would return 0 from the 
event_handler, ensuring cma_process_remove() does not invoke 
rdma_destroy_id(), is that it?

Kanoj

>map wildcard listens across multiple RDMA devices.  Their creation and
>destruction is contained to the cma.  From the viewpoint of the device removal
>code, a nonwildcard listen is treated the same as a connected id.
>
>The ucma only destroys id's from an event callback if the id is for a new
>connection which it can't handle.
>
>Hope this makes sense.
>
>- Sean
>
>  
>