[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