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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <30c6d4aa-7598-4dc1-8592-7533d64714c2@paulmck-laptop>
Date: Tue, 30 Jul 2024 15:39:44 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Frederic Weisbecker <frederic@...nel.org>
Cc: Valentin Schneider <vschneid@...hat.com>, rcu@...r.kernel.org,
	linux-kernel@...r.kernel.org, Peter Zijlstra <peterz@...radead.org>,
	Neeraj Upadhyay <quic_neeraju@...cinc.com>,
	Joel Fernandes <joel@...lfernandes.org>,
	Josh Triplett <josh@...htriplett.org>,
	Boqun Feng <boqun.feng@...il.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Lai Jiangshan <jiangshanlai@...il.com>,
	Zqiang <qiang.zhang1211@...il.com>
Subject: Re: RCU-Task[-Trace] VS EQS (was Re: [PATCH v3 13/25]
 context_tracking, rcu: Rename rcu_dynticks_task*() into rcu_task*())

On Wed, Jul 31, 2024 at 12:17:49AM +0200, Frederic Weisbecker wrote:
> 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.

Can it really migrate while in entry/exit or deep idle code?  Or am I
missing a trick 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.
> 
> Ok I see...

If need be, the outgoing-CPU transition to RCU-not-watching could be
delayed into arch-specific code.  We already allow this for the incoming
transition.

							Thanx, Paul