Messages in this thread | | | Date | Wed, 26 Sep 2012 16:56:55 +0200 | Subject | Re: RCU idle CPU detection is broken in linux-next | From | Frederic Weisbecker <> |
| |
2012/9/25 Paul E. McKenney <paulmck@linux.vnet.ibm.com>: > On Tue, Sep 25, 2012 at 01:59:26PM +0200, Frederic Weisbecker wrote: >> Given that we have: >> >> rcu_irq_enter() >> rcu_user_exit() >> rcu_user_enter() >> rcu_irq_exit() > > Indeed, the code to deal with irq misnestings won't like that at all. > And we are in the kernel between rcu_user_exit() and rcu_user_enter() > (right?), so we could in fact see irq misnestings.
Exactly.
> >> And we already have rcu_user_exit_after_irq(), this starts to be confusing >> if we allow that nesting. Although if we find a solution that, in the end, >> merge rcu_user_exit() with rcu_user_exit_after_irq() and same for the enter version, >> this would probably be a good thing. Provided this doesn't involve some more >> complicated rdtp->dyntick_nesting trickies nor more overhead. >> >> Otherwise we could avoid to call rcu_user_* when we are in an irq. When we'll have >> the user_hooks layer, we can perhaps manage that from that place. For >> now may be we can return after in_interrupt() in the rcu user apis. > > This last sounds best.
Ok.
> > My main concern is irq misnesting. We might need to do something ugly > like record the interrupt nesting level at rcu_user_exit() and restore > it at rcu_user_enter(). Sigh!!!
Right, but that doesn't seem to apply in x86? I suggest we start simple and think about some wider solution when more architecture implement this.
| |