* David Miller <[EMAIL PROTECTED]> wrote:
> > that was pretty much the only place in the whole kernel that got hit
> > by some rcu-preempt side-effect - and even this appears to show that
> > it's a real bug that was in hiding.
>
> No, rather, it's the only location that triggered an automated
> debugging check. The very first set of code paths we checked, in
> response to the bug trigger, showed beyond a shadow of a doubt that
> this assumption is pervasive and in many locations that none of the
> automated debugging checks live.
>
> The tree should be fully audited before such a huge semantic change
> gets added into the tree.
i'd like to add more automated checks to the tree. 'naked'
smp_processor_id() use is one telltale sign of such a problem - what
other instances could you suggest me to check? The thing is, in 99% of
the cases the smp_processor_id() check caught such assumptions in other
code because 'preempt off' is inextricably connected to /some/ use of
smp_processor_id() - be it get_cpu_var() or any other derivative
interface. So i'm wondering what other assumptions there are (or can be)
about rcu_read_lock() also being a preempt-off point. Thanks!
(btw., i always argued that neither preempt_disable() nor
rcu_read_lock() is an ideal interface for locking because both hide
critical assumptions and dependencies - and they both are able to create
little versions of the 'big BKL mess' that we had to fight a few years
ago. (and that we still have to fight today, in certain areas of code.))
Ingo
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
