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

Roland Dreier rdreier at cisco.com
Wed Nov 1 14:08:13 PST 2006


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

Unfortunately I don't think this solves the module unloading race at
all: there is still a window where code in the client module callback
is running, but the callback has dropped all references etc. so the
client module will happily proceed to unload.

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

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.

But I don't see a way to reconcile that with letting callbacks destroy
CM IDs.

 - R.




More information about the general mailing list