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

[Sean Hefty]

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