On Wed, Sep 26, 2012 at 04:56:55PM +0200, Frederic Weisbecker wrote: > 2012/9/25 Paul E. McKenney <paul...@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.
Fair enough -- for one thing, we will better understand what is required when the problems are actually encountered. Which will hopefully be sooner rather than later. ;-) Thanx, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/