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: <CAEf4BzazpB6XHL+HRO0HaegiwCUpXaTi+QSnPAxsW9BHBL=50Q@mail.gmail.com>
Date: Thu, 25 Sep 2025 11:40:54 -0700
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: "Paul E. McKenney" <paulmck@...nel.org>
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 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?

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ