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

[Or Gerlitz]

Sean Hefty wrote:
> Or Gerlitz wrote:
>> 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 

Assuming it is indeed useful and nice feature which we don't want to 
remove (does someone is aware to any similar example in the kernel where 
you can delete a resource from its associated callback? ie i am quite 
sure you are **not** allowed to delete a timer or destroy a socket from 
within their callbacks).

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

what about enhancing xxx_destory_id() to sense that it was called from 
this id callback context so the xxx module code defers the destory_id() 
  execution to run after the callback is over. This can be done by 
writing at the id the pid of the thread running the callback before 
going to the consumer and deleting it when the callback returns. Then if 
in_callback(id) holds, have the destory_id() call schedule itself to 
later stage, where it checks again etc.

At the bottom line, users must call xxx_destory_id() explicitly the xxx 
module would be able to handle in_callback situations.

Or.