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? > 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. Or am I missing some implicit reason why this all works? Thanx, Paul
