linux-kernel - Re: [PATCH v2 02/21] rcu: Re-implement RCU Tasks Trace in terms of SRCU-fast

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: <d24f3987-48de-43e3-a841-2a116ac6d5c7@paulmck-laptop>
Date: Sat, 4 Oct 2025 02:47:08 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Frederic Weisbecker <frederic@...nel.org>
Cc: rcu@...r.kernel.org, linux-kernel@...r.kernel.org, kernel-team@...a.com,
	rostedt@...dmis.org, kernel test robot <oliver.sang@...el.com>,
	Andrii Nakryiko <andrii@...nel.org>,
	Alexei Starovoitov <ast@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>, bpf@...r.kernel.org
Subject: Re: [PATCH v2 02/21] rcu: Re-implement RCU Tasks Trace in terms of
 SRCU-fast

On Thu, Oct 02, 2025 at 05:46:10PM +0200, Frederic Weisbecker wrote:
> Le Wed, Oct 01, 2025 at 07:48:13AM -0700, Paul E. McKenney a écrit :
> > This commit saves more than 500 lines of RCU code by re-implementing
> > RCU Tasks Trace in terms of SRCU-fast.  Follow-up work will remove
> > more code that does not cause problems by its presence, but that is no
> > longer required.
> > 
> > This variant places smp_mb() in rcu_read_{,un}lock_trace(), which will
> > be removed on common-case architectures in a later commit.
> 
> The changelog doesn't mention what this is ordering :-)

"The ordering that dare not be named"?  ;-)

How about like this for that second paragraph?

	This variant places smp_mb() in rcu_read_{,un}lock_trace(),
	which will be removed on common-case architectures in a
	later commit.  In the meantime, it serves to enforce ordering
	between the underlying srcu_read_{,un}lock_fast() markers and
	the intervening critical section, even on architectures that
	permit attaching tracepoints on regions of code not watched
	by RCU.  Such architectures defeat SRCU-fast's use of implicit
	single-instruction, interrupts-disabled, and atomic-operation
	RCU read-side critical sections, which have no effect when RCU is
	not watching.  The aforementioned later commit will insert these
	smp_mb() calls only on architectures that have not used noinstr to
	prevent attaching tracepoints to code where RCU is not watching.

> > [ paulmck: Apply kernel test robot, Boqun Feng, and Zqiang feedback. ]
> > [ paulmck: Split out Tiny SRCU fixes per Andrii Nakryiko feedback. ]
> > 
> > Signed-off-by: Paul E. McKenney <paulmck@...nel.org>
> > Tested-by: kernel test robot <oliver.sang@...el.com>
> > Cc: Andrii Nakryiko <andrii@...nel.org>
> > Cc: Alexei Starovoitov <ast@...nel.org>
> > Cc: Peter Zijlstra <peterz@...radead.org>
> > Cc: <bpf@...r.kernel.org>
> > ---
> [...]
> > @@ -50,12 +50,14 @@ static inline void rcu_read_lock_trace(void)
> >  {
> >  	struct task_struct *t = current;
> >  
> > -	WRITE_ONCE(t->trc_reader_nesting, READ_ONCE(t->trc_reader_nesting) + 1);
> > -	barrier();
> > -	if (IS_ENABLED(CONFIG_TASKS_TRACE_RCU_READ_MB) &&
> > -	    t->trc_reader_special.b.need_mb)
> > -		smp_mb(); // Pairs with update-side barriers
> > -	rcu_lock_acquire(&rcu_trace_lock_map);
> > +	if (t->trc_reader_nesting++) {
> > +		// In case we interrupted a Tasks Trace RCU reader.
> > +		rcu_try_lock_acquire(&rcu_tasks_trace_srcu_struct.dep_map);
> > +		return;
> > +	}
> > +	barrier();  // nesting before scp to protect against interrupt handler.
> > +	t->trc_reader_scp = srcu_read_lock_fast(&rcu_tasks_trace_srcu_struct);
> > +	smp_mb(); // Placeholder for more selective ordering
> 
> Mysterious :-)

Does the reworked commit-log paragraph help clear up this mystery?

> >  }
> >  
> >  /**
> > @@ -69,26 +71,75 @@ static inline void rcu_read_lock_trace(void)
> >   */
> >  static inline void rcu_read_unlock_trace(void)
> >  {
> > -	int nesting;
> > +	struct srcu_ctr __percpu *scp;
> >  	struct task_struct *t = current;
> >  
> > -	rcu_lock_release(&rcu_trace_lock_map);
> > -	nesting = READ_ONCE(t->trc_reader_nesting) - 1;
> > -	barrier(); // Critical section before disabling.
> > -	// Disable IPI-based setting of .need_qs.
> > -	WRITE_ONCE(t->trc_reader_nesting, INT_MIN + nesting);
> > -	if (likely(!READ_ONCE(t->trc_reader_special.s)) || nesting) {
> > -		WRITE_ONCE(t->trc_reader_nesting, nesting);
> > -		return;  // We assume shallow reader nesting.
> > -	}
> > -	WARN_ON_ONCE(nesting != 0);
> > -	rcu_read_unlock_trace_special(t);
> > +	smp_mb(); // Placeholder for more selective ordering
> 
> Bizarre :-)

And this bizarreness?  ;-)

> > +	scp = t->trc_reader_scp;
> > +	barrier();  // scp before nesting to protect against interrupt handler.
> 
> What is it protecting against interrupt?

The incrementing of ->trc_reader_nesting vs the fetch of ->trc_reader_scp.

							Thanx, Paul

> > +	if (!--t->trc_reader_nesting)
> > +		srcu_read_unlock_fast(&rcu_tasks_trace_srcu_struct, scp);
> > +	else
> > +		srcu_lock_release(&rcu_tasks_trace_srcu_struct.dep_map);
> > +}
> 
> Thanks (very happy to see all the rest of the code going away!)
> 
> -- 
> Frederic Weisbecker
> SUSE Labs