Alan Stern <[email protected]> wrote:
>
> A high percentage of the existing notifier chains are of the blocking sort
> (the callouts are allowed to sleep). They are well served by a simple
> rw-semaphore, as in our patch. It seems foolish to force the duplication
> of this locking code in all the places that would need it.
>
> Likewise, the atomic-type chains (where the callouts must run in an atomic
> context) are generally well served by the RCU mechanism, especially in
> cases where callouts are never unregistered.
>
> So I propose that, in addition to those two types of chains, we define a
> third type: raw notifiers. These will be implemented with no protection
> at all. No rw-semaphore, no spinlock, no RCU, no need to avoid
> self-unregistration, nothing -- all protection will be up to the users.
> In other words, just what you asked for.
>
> This gives us the best of both worlds. The common cases can benefit from
> the centralized locking and protection, while anyone who has special needs
> can easily provide for them.
>
> If you think this would be okay, I'll rewrite the notifier patch to
> include the raw type.
The default version of notifier chains should be the lockless version -
just like list_head, radix_tree, etc. (idr tries to provide its own
locking and has turned out to be a classic case of why we shouldn't do
that).
And sure, it makes sense to provide additional, higher-level data
structures and APIs which layer on top of that, purely as a code
consolidation exercise. But they shouldn't be called notifier_chains.
Call them notifier_chain_mutex_locked and notifier_chain_rwlocked and
notifier_chain_spinlocked or whatever.
As for the NMIs and RCU: I suspect it was simply a mistake to try to use
notifier chains for NMI registration in the first place - they are simply
too complex a data structure for this. I think I previously suggested
removing that code and using just a fixed-size array of function pointers.
But if the RCUified notifier chain solution is less-than-totally-gross then
that might be OK as well.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
