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
_______________________________________________
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
