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
_______________________________________________
general mailing list
[email protected]
http://lists.openfabrics.org/cgi-bin/mailman/listinfo/general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
