Re: [PATCH 5/7] docs: this_cpu_ops: Fix SRCU helper names

[Randy Dunlap]

On 8/22/26 5:16 AM, Karl Mehltretter wrote:
> 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 <kmehltretter@xxxxxxxxx>

Reviewed-by: Randy Dunlap <rdunlap@xxxxxxxxxxxxx>
Thanks.

> ---
>  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 533ac5dd57507..367706d1714b1 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
>  -----------------------------

-- 
~Randy