[openib-general] [PATCH] for 2-6-19 rdma/addr: use client registration to fix module unload race
Sean Hefty
mshefty at ichips.intel.com
Tue Oct 31 08:49:05 PST 2006
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
More information about the general
mailing list