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

[Kanoj Sarcar]

Sean Hefty wrote:

>> 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?
>
>
> yep - the destruction of the id is controlled by the user
>
Ok, one last thing while we are here.

cma_process_remove() -> cma_remove_id_dev() generates the event for 
device removal. This is ok to do as long as it can be guaranteed that a 
racing rdma_destroy_id() has not returned back to caller, correct?

IE, the caller must be willing to accept device removal events until its 
rdma_destroy_id() returns.

If so, why is cma_remove_id_dev() trying so hard to not generate the 
event when rdma_destroy_id() has gotten to the point of setting 
CMA_DESTROYING? Could it not just generate the event, happy in the 
knowledge that the refcount bump done by cma_process_remove() will 
prevent the rdma_destroy_id() call from returning?

If it could, that could mean all the cma_exch() code can be deleted from 
cma.c, and the CMA_DESTROYING state can also go away (your patch has 
taken out the only other reason CMA_DESTROYING was needed).

Kanoj