Michael S. Tsirkin wrote: >> Michael S. Tsirkin wrote: >>> Quoting r. Or Gerlitz <[EMAIL PROTECTED]>:
>>> The race happens on module unload - you might be inside the cm callback when >>> the module is unloaded. Nothing the module itself does can help here - you >>> must >>> synchronize with the cm before unloading. >> I think to understand: you say that the CM can call the callback while >> the module unloads. However, my point is that the cm consumer module >> must destroy its cm id before unloading and that the cm id destroy code >> would block till all inflight callbacks on this id are done. Similarly >> to destroy_timer_sync or whatever it is called. >> Am i still missing something? > Yes, you miss the case where you do not destroy cm id explicitly, but rather > return error code from callback instead of destroying the cm_id. 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() ??? 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... Or. _______________________________________________ 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
