On Wed, Oct 02, 2019 at 06:38:59PM -0700, [email protected] wrote: > From: "Paul E. McKenney" <[email protected]> > > CPUs running for long time periods in the kernel in nohz_full mode > might leave the scheduling-clock interrupt disabled for then full > duration of their in-kernel execution. This can (among other things) > delay grace periods. This commit therefore forces the tick back on > for any nohz_full CPU that is failing to pass through a quiescent state > upon return from interrupt, which the resched_cpu() will induce. > > Reported-by: Joel Fernandes <[email protected]> > [ paulmck: Clear ->rcu_forced_tick as reported by Joel Fernandes testing. ] > [ paulmck: Apply Joel Fernandes TICK_DEP_MASK_RCU->TICK_DEP_BIT_RCU fix. ] > Signed-off-by: Paul E. McKenney <[email protected]> > --- > kernel/rcu/tree.c | 38 +++++++++++++++++++++++++++++++------- > kernel/rcu/tree.h | 1 + > 2 files changed, 32 insertions(+), 7 deletions(-) > > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c > index 74bf5c65..621cc06 100644 > --- a/kernel/rcu/tree.c > +++ b/kernel/rcu/tree.c > @@ -650,6 +650,12 @@ static __always_inline void rcu_nmi_exit_common(bool irq) > */ > if (rdp->dynticks_nmi_nesting != 1) { > trace_rcu_dyntick(TPS("--="), rdp->dynticks_nmi_nesting, > rdp->dynticks_nmi_nesting - 2, rdp->dynticks); > + if (tick_nohz_full_cpu(rdp->cpu) && > + rdp->dynticks_nmi_nesting == 2 && > + rdp->rcu_urgent_qs && !rdp->rcu_forced_tick) { > + rdp->rcu_forced_tick = true; > + tick_dep_set_cpu(rdp->cpu, TICK_DEP_MASK_RCU);
I understand rdp->cpu is always smp_processor_id() here, right? Because calling tick_dep_set_cpu() to a remote CPU while in NMI wouldn't be safe. It would warn anyway.
