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: <31d78183-4526-41e8-90df-d03c95fdb9b2@paulmck-laptop>
Date: Tue, 30 Jul 2024 07:23:58 -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 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