From 55c03a9ae22aa14262a5acca202df33e9c42dcfc Mon Sep 17 00:00:00 2001 From: Karl Mehltretter Date: Sat, 22 Aug 2026 14:16:49 +0200 Subject: [PATCH] docs: this_cpu_ops: Fix SRCU helper names Use the actual srcu_read_lock_nmisafe() and atomic_long_inc() helper names. Fixes: df0cee43114b ("docs: Improve discussion of this_cpu_ptr(), add raw_cpu_ptr()") Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Karl Mehltretter Reviewed-by: Paul E. McKenney Reviewed-by: Randy Dunlap Signed-off-by: Jonathan Corbet Message-ID: <20260822121651.1559-6-kmehltretter@gmail.com> --- Documentation/core-api/this_cpu_ops.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/core-api/this_cpu_ops.rst b/Documentation/core-api/this_cpu_ops.rst index 533ac5dd5750..367706d1714b 100644 --- a/Documentation/core-api/this_cpu_ops.rst +++ b/Documentation/core-api/this_cpu_ops.rst @@ -150,10 +150,10 @@ preemptible code are addressed by raw_cpu_ptr(), but such use cases need to handle cases where two different CPUs are accessing the same per cpu variable, which might well be that of a third CPU. These use cases are typically performance optimizations. For example, SRCU implements a pair -of counters as a pair of per-CPU variables, and rcu_read_lock_nmisafe() +of counters as a pair of per-CPU variables, and srcu_read_lock_nmisafe() uses raw_cpu_ptr() to get a pointer to some CPU's counter, and uses -atomic_inc_long() to handle migration between the raw_cpu_ptr() and -the atomic_inc_long(). +atomic_long_inc() to handle migration between the raw_cpu_ptr() and +the atomic_long_inc(). Per cpu variables and offsets -----------------------------