[lkml]   [2005]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Notifier chains are unsafe
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
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-10-25 19:09    [W:0.132 / U:0.220 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site