[openib-general] [PATCH] for 2-6-19 rdma/addr: use client registration to fix module unload race

[Or Gerlitz]

Michael S. Tsirkin wrote:
>> Michael S. Tsirkin wrote:
>>> Quoting r. Or Gerlitz <ogerlitz at voltaire.com>:

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