On Wed, Jul 28, 2021 at 02:23:05PM -0400, Mathieu Desnoyers wrote:
> ----- On Jul 28, 2021, at 1:37 PM, paulmck paulmck@xxxxxxxxxx wrote:
> [...]
> >
> > diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
> > index 42a0032dd99f7..c87b3a271d65b 100644
> > --- a/kernel/rcu/tree.c
> > +++ b/kernel/rcu/tree.c
> > @@ -251,6 +251,15 @@ void rcu_softirq_qs(void)
> > rcu_tasks_qs(current, false);
> > }
> >
> > +/*
> > + * Increment the current CPU's rcu_data structure's ->dynticks field
> > + * with ordering. Return the new value.
> > + */
> > +static noinstr unsigned long rcu_dynticks_inc(int incby)
> > +{
> > + return arch_atomic_add_return(incby, this_cpu_ptr(&rcu_data.dynticks));
> > +}
> > +
>
> [...]
>
> > @@ -308,7 +317,7 @@ static void rcu_dynticks_eqs_online(void)
> >
> > if (atomic_read(&rdp->dynticks) & 0x1)
> > return;
>
> Can the thread be migrated at this point ? If yes, then
> the check and the increment may happen on different cpu's rdps. Is
> that OK ?
Good point! Actually, it can be migrated, but it does not matter.
In fact, it so completely fails to matter that is is totally useless. :-/
The incoming CPU is still offline, so this is run from some other
completely-online CPU. Because this CPU is executing in non-idle
kernel context, that "if" condition must evaluate to true, so that the
rcu_dynticks_inc() below is dead code.
Maybe I should move the call to rcu_dynticks_eqs_online() to
rcu_cpu_starting(), which is pinned to the incoming CPU. Yes, I
could remove it completely, but then small changes in the offline
process could cause great mischief.
Good catch, thank you!
Thanx, Paul
> > - atomic_inc(&rdp->dynticks);
> > + rcu_dynticks_inc(1);
> > }
>
> Thanks,
>
> Mathieu
>
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com
