![]() | ||||||||||
Messages in this thread |
Alan Stern wrote: > Has anyone been bothered by the fact that notifier chains are not safe > with regard to registration and unregistration while the chain is in use? > The notifier_chain_register and notifier_chain_unregister routines have > writelock protections, but the corresponding readlock is never taken! > > It shouldn't be hard to make this work safely, even allowing such things > as notifier routines unregistering themselves as they run. The patch > below contains an example implementation, showing one way to do it. > > But doing this correctly requires knowing how notifier chains are used. > > Are they always called in process context, with interrupts enabled? > > Or do some get called in interrupt context? > > Are there any notifier chains invoked on a critical fast path? > (I hope not...) > > How many different threads are likely to call a particular > notifier chain at one time? > > Feedback is requested. > > Alan Stern > [...] It's not clear how you are making this safe. You aren't using one of the known solutions to this problem. For GC lock-free based solutions, you can't use RCU since notify_call can sleep. You could use a form of reference counting but you'd have to implement it yourself. Ditto on RCU+SMR or some other form of proxy GC. Not implemented. You could use COR (Copy On Read). Make a copy of the list while holding a lock, release the lock, do the notifications, and then delete the copy of the list. The non-blocking schemes can do notify_calls after unregistration so you need to take this into account. Whatever you're calling against still has to be there and has to be in a meaningful state. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | |||||||||
| Last update: 2005-10-25 17:09 [from the cache] ©2003-2008 | ||||||||||