Re: RCU idle CPU detection is broken in linux-next

From: Frederic Weisbecker
Date: Wed Sep 26 2012 - 10:56:47 EST


2012/9/25 Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx>:
> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/