Quoting r. Sean Hefty <[EMAIL PROTECTED]>: > 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 _______________________________________________ openib-general mailing list openib-general@openib.org http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
