linux-kernel - Re: [PATCH 19/34] rcu: Update Requirements.rst for RCU Tasks Trace

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: <e65d2553-88fc-47ee-b0fa-ddfb5515a7e0@paulmck-laptop>
Date: Thu, 25 Sep 2025 11:53:24 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: rcu@...r.kernel.org, linux-kernel@...r.kernel.org, kernel-team@...a.com,
	rostedt@...dmis.org, Andrii Nakryiko <andrii@...nel.org>,
	Alexei Starovoitov <ast@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>, bpf@...r.kernel.org
Subject: Re: [PATCH 19/34] rcu: Update Requirements.rst for RCU Tasks Trace

On Thu, Sep 25, 2025 at 11:40:54AM -0700, Andrii Nakryiko wrote:
> On Tue, Sep 23, 2025 at 7:21 AM Paul E. McKenney <paulmck@...nel.org> wrote:
> >
> > This commit updates the documentation to declare that RCU Tasks Trace
> > is implemented as a thin wrapper around SRCU-fast.
> >
> > Signed-off-by: Paul E. McKenney <paulmck@...nel.org>
> > Cc: Andrii Nakryiko <andrii@...nel.org>
> > Cc: Alexei Starovoitov <ast@...nel.org>
> > Cc: Peter Zijlstra <peterz@...radead.org>
> > Cc: <bpf@...r.kernel.org>
> > ---
> >  .../RCU/Design/Requirements/Requirements.rst         | 12 ++++++------
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> >
> > diff --git a/Documentation/RCU/Design/Requirements/Requirements.rst b/Documentation/RCU/Design/Requirements/Requirements.rst
> > index f24b3c0b9b0dc6..4a116d7a564edc 100644
> > --- a/Documentation/RCU/Design/Requirements/Requirements.rst
> > +++ b/Documentation/RCU/Design/Requirements/Requirements.rst
> > @@ -2779,12 +2779,12 @@ Tasks Trace RCU
> >  ~~~~~~~~~~~~~~~
> >
> >  Some forms of tracing need to sleep in readers, but cannot tolerate
> > -SRCU's read-side overhead, which includes a full memory barrier in both
> > -srcu_read_lock() and srcu_read_unlock().  This need is handled by a
> > -Tasks Trace RCU that uses scheduler locking and IPIs to synchronize with
> > -readers.  Real-time systems that cannot tolerate IPIs may build their
> > -kernels with ``CONFIG_TASKS_TRACE_RCU_READ_MB=y``, which avoids the IPIs at
> > -the expense of adding full memory barriers to the read-side primitives.
> > +SRCU's read-side overhead, which includes a full memory barrier in
> > +both srcu_read_lock() and srcu_read_unlock().  This need is handled by
> > +a Tasks Trace RCU API implemented as thin wrappers around SRCU-fast,
> > +which avoids the read-side memory barriers, at least for architectures
> > +that apply noinstr to kernel entry/exit code (or that build with
> > +``CONFIG_TASKS_TRACE_RCU_NO_MB=y``.
> 
> For my own education (and due to laziness to try to figure this out on
> my own), what's the situation where you'd want to stick to the
> old-school "heavy-weight" SRCU vs SRCU-fast variant?

There are a couple of use cases for old-school non-fast SRCU: (1) You need
to use srcu_read_lock() where RCU is not watching, and/or (2) you cannot
tolerate the latency of a pair of synchronize_rcu() calls and the IPIs
from the synchronize_rcu_expedited() calls in SRCU-fast grace periods.

But who knows?  Perhaps in time everyone will switch to SRCU-fast.

							Thanx, Paul

> >  The tasks-trace-RCU API is also reasonably compact,
> >  consisting of rcu_read_lock_trace(), rcu_read_unlock_trace(),
> > --
> > 2.40.1
> >