Re: RCU-Task[-Trace] VS EQS (was Re: [PATCH v3 13/25] context_tracking, rcu: Rename rcu_dynticks_task*() into rcu_task*())

[Frederic Weisbecker <frederic@kernel.org>]

Le Tue, Jul 30, 2024 at 07:23:58AM -0700, Paul E. McKenney a écrit :
> On Thu, Jul 25, 2024 at 04:32:46PM +0200, Frederic Weisbecker wrote:
> > Le Wed, Jul 24, 2024 at 04:43:13PM +0200, Valentin Schneider a écrit :
> > > -/* Turn on heavyweight RCU tasks trace readers on idle/user entry. */
> > > -static __always_inline void rcu_dynticks_task_trace_enter(void)
> > > +/* Turn on heavyweight RCU tasks trace readers on kernel exit. */
> > > +static __always_inline void rcu_task_trace_exit(void)
> > 
> > Before I proceed on this last one, a few questions for Paul and others:
> > 
> > 1) Why is rcu_dynticks_task_exit() not called while entering in NMI?
> >    Does that mean that NMIs aren't RCU-Task read side critical sections?
> 
> Because Tasks RCU Rude handles that case currently.  So good catch,
> because this might need adjustment when we get rid of Tasks RCU Rude.
> And both rcu_dynticks_task_enter() and rcu_dynticks_task_exit() look safe
> to invoke from NMI handlers.  Memory ordering needs checking, of course.
> 
> Except that on architectures defining CONFIG_ARCH_WANTS_NO_INSTR, Tasks
> RCU should instead check the ct_kernel_enter_state(RCU_DYNTICKS_IDX)
> state, right?  And on those architectures, I believe that
> rcu_dynticks_task_enter() and rcu_dynticks_task_exit() can just be no-ops.
> Or am I missing something here?

I think rcu_dynticks_task_enter() and rcu_dynticks_task_exit() are
still needed anyway because the target task can migrate. So unless the rq is locked,
it's hard to match a stable task_cpu() with the corresponding RCU_DYNTICKS_IDX.

> 
> > 2) Looking further into CONFIG_TASKS_TRACE_RCU_READ_MB=y, it seems to
> >    allow for uses of rcu_read_[un]lock_trace() while RCU is not watching
> >    (EQS). Is it really a good idea to support that? Are we aware of any
> >    such potential usecase?
> 
> I hope that in the longer term, there will be no reason to support this.
> Right now, architectures not defining CONFIG_ARCH_WANTS_NO_INSTR must
> support this because tracers really can attach probes where RCU is
> not watching.
> 
> And even now, in architectures defining CONFIG_ARCH_WANTS_NO_INSTR, I
> am not convinced that the early incoming and late outgoing CPU-hotplug
> paths are handled correctly.  RCU is not watching them, but I am not so
> sure that they are all marked noinstr as needed.

Ok I see...

Thanks.