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

Michael S. Tsirkin mst at mellanox.co.il
Thu Nov 2 00:14:53 PST 2006


Quoting r. Sean Hefty <mshefty at ichips.intel.com>:
> Subject: Re: [PATCH] for 2-6-19 rdma/addr: use client registration to fix module unload race
> 
> >>I think this is actually a good point for the CM case at least.
> >>Clients already have something registered with the CM (namely the CM
> >>ID itself), so if we required all consumers to destroy their IDs
> >>explicitly, then there's no reason to add additional client
> >>registration.
> > 
> > The issue is more related to cm_id's that are created when a new connection 
> > request arrives.  For the user to destroy the new id's, they either need to be 
> > able to queue them somewhere for later destruction, call destroy from the 
> > callback, or indicate that the id's should be destroyed when the callback returns.
> 
> I should add that the point is taken though.  If we only allow new cm_id's to be 
> destroyed this way, then we avoid the issue.
> 
> I _think_ that all users of the ib_cm and rdma_cm behave this way, but I need to 
> verify this to be sure.

All active side users are fine I think.  But any client on the passive side
currently might destroy the new ID by returning error from the callback, and I
like this interface since it frees the resources immediately.

Since all such passive side users currently are out of tree, I don't think
it's urgent for us to do anything about the passive side race - but please do
not at least break code that uses passive side in major ways just yet.

Once there are in-tree passive side users, I think registration at module load/unload
time would be the best approach.


-- 
MST




More information about the general mailing list