On Tue, Jun 16, 2020 at 10:40:04AM +0200, Thomas Gleixner wrote: > Joel, > > Joel Fernandes <joel@xxxxxxxxxxxxxxxxx> writes: > > On Fri, Jun 12, 2020 at 03:55:00PM +0200, Thomas Gleixner wrote: > >> This is also correct vs. user mode entries in NOHZ full scenarios because > >> user mode entries bring RCU out of EQS and force the RCU irq nesting state > > > > I had to re-read this sentence a couple of times. The 'user mode entries' > > sounds like 'entry into user mode'. It would be good to reword it to 'IRQ > > entry in user mode'. > > :) > > > My knowledge predates the rcu-watching reworks so apologies on the below > > question but I still didn't fully follow why when the idle task behaves > > differently from being in user mode. Even with user mode we should have: > > > > <user mode> (in EQS) > > <irq entry> <---------- exits EQS so now rcu is watching > > <softirq entry in the exit path> > > <timer tick irq entry> <-- the buggy !watching logic prevents rcu_irq_enter > > -> report QS since tick thinks it is first level. > > > > Is there a subtlety here I'm missing? I checked the RCU code and I did not > > see anywhere that rcu_user_enter() makes it behave differently. Both > > rcu_user_enter() and rcu_idle_enter() call rcu_eqs_enter(). > > The interrupt hit user mode entry does: > > idtentry_enter_cond_rcu() > if (user_mode(regs)) > enter_from_user_mode() > user_exit_irqoff() > __context_tracking_exit(CONTEXT_USER) > rcu_user_exit() > rcu_eqs_exit(1) > ... > WRITE_ONCE(rdp->dynticks_nmi_nesting, > DYNTICK_IRQ_NONIDLE); > > i.e. for interrupts which enter from user mode we are not invoking > rcu_irq_enter() at all. > > The return from interrupt path has nothing to do with that because > that's an entry in kernel mode. Hi Thomas, Ah, IRQ entry in user mode triggers the context-tracking path. Makes sense now, thanks. This will help me when I have to propose to get rid of dynticks_nmi_nesting again :) Reviewed-by: Joel Fernandes (Google) <joel@xxxxxxxxxxxxxxxxx> thanks, - Joel
