Or Gerlitz wrote: > So the only case for which all this registration api/code at the ib_sa > ib_cm and ib_addr (is it also in the ib_mad) protects against is where > the consumer wants to destroy its ID by returning non zero from a > callback and not by an explicit call to XXX_destory_id()
ib_sa and ib_addr are similar. Both simply callback the user, and once the callback completes, the module can unload. Users of those modules cannot protect against a thread running in their callback. ib_mad already requires registration, so does not have this issue. > If yes, this seems to me as one big over-doing, assuming the consumer > always either call XXX_destory_id() OR returns non zero from a callback > on this ID, there must be away to avoid the race within the ID provider > module, so at least the api can be saved... As long as the user can destroy a cm_id from their callback, the ib_cm and rdma_cm have this issue. This feature ends up being fairly useful, so I'm hesitant to remove it. The alternative is that a user must always call xxx_destroy_id(), but that cannot be done from within the callback thread itself. This would require a user to schedule a thread to call destroy, which may not always be possible. (Consider the case where the cm creates a new id as part of a connection request. For the user to schedule the destruction, it would need to queue the new cm_id somewhere, which may not be possible.) - Sean _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general