From: Boqun Feng <boqun.feng@gmail.com>
To: rcu@vger.kernel.org
Cc: Lai Jiangshan <jiangshanlai@gmail.com>,
"Paul E. McKenney" <paulmck@kernel.org>,
Josh Triplett <josh@joshtriplett.org>,
Steven Rostedt <rostedt@goodmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Frederic Weisbecker <frederic@kernel.org>,
Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
Joel Fernandes <joel@joelfernandes.org>,
Boqun Feng <boqun.feng@gmail.com>,
Uladzislau Rezki <urezki@gmail.com>,
Zqiang <qiang.zhang1211@gmail.com>,
Davidlohr Bueso <dave@stgolabs.net>,
Shuah Khan <shuah@kernel.org>,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
bpf@vger.kernel.org, Alexei Starovoitov <ast@kernel.org>
Subject: [PATCH rcu 20/20] srcu: Make SRCU-fast also be NMI-safe
Date: Sun, 23 Feb 2025 18:22:14 -0800 [thread overview]
Message-ID: <20250224022214.12037-21-boqun.feng@gmail.com> (raw)
In-Reply-To: <20250224022214.12037-1-boqun.feng@gmail.com>
From: "Paul E. McKenney" <paulmck@kernel.org>
BPF uses rcu_read_lock_trace() in NMI context, so srcu_read_lock_fast()
must be NMI-safe if it is to have any chance of addressing RCU Tasks
Trace use cases. This commit therefore causes srcu_read_lock_fast()
and srcu_read_unlock_fast() to use atomic_long_inc() instead of
this_cpu_inc() on architectures that support NMIs but do not have
NMI-safe implementations of this_cpu_inc(). Note that both x86 and
arm64 have NMI-safe implementations of this_cpu_inc(), and thus do not
pay the performance penalty inherent in atomic_inc_long().
It is tempting to use this trick to fold srcu_read_lock_nmisafe()
into srcu_read_lock(), but this would need careful thought, review,
and performance analysis. Though those smp_mb() calls might well make
performance a non-issue.
Reported-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Signed-off-by: Boqun Feng <boqun.feng@gmail.com>
---
include/linux/srcutree.h | 34 ++++++++++++++++++++++++----------
1 file changed, 24 insertions(+), 10 deletions(-)
diff --git a/include/linux/srcutree.h b/include/linux/srcutree.h
index bdc467efce3a..8bed7e6cc4c1 100644
--- a/include/linux/srcutree.h
+++ b/include/linux/srcutree.h
@@ -231,17 +231,24 @@ static inline struct srcu_ctr __percpu *__srcu_ctr_to_ptr(struct srcu_struct *ss
* srcu_struct. Returns a pointer that must be passed to the matching
* srcu_read_unlock_fast().
*
- * Note that this_cpu_inc() is an RCU read-side critical section either
- * because it disables interrupts, because it is a single instruction,
- * or because it is a read-modify-write atomic operation, depending on
- * the whims of the architecture.
+ * Note that both this_cpu_inc() and atomic_long_inc() are RCU read-side
+ * critical sections either because they disables interrupts, because they
+ * are a single instruction, or because they are a read-modify-write atomic
+ * operation, depending on the whims of the architecture.
+ *
+ * This means that __srcu_read_lock_fast() is not all that fast
+ * on architectures that support NMIs but do not supply NMI-safe
+ * implementations of this_cpu_inc().
*/
static inline struct srcu_ctr __percpu *__srcu_read_lock_fast(struct srcu_struct *ssp)
{
struct srcu_ctr __percpu *scp = READ_ONCE(ssp->srcu_ctrp);
RCU_LOCKDEP_WARN(!rcu_is_watching(), "RCU must be watching srcu_read_lock_fast().");
- this_cpu_inc(scp->srcu_locks.counter); /* Y */
+ if (!IS_ENABLED(CONFIG_NEED_SRCU_NMI_SAFE))
+ this_cpu_inc(scp->srcu_locks.counter); /* Y */
+ else
+ atomic_long_inc(raw_cpu_ptr(&scp->srcu_locks)); /* Z */
barrier(); /* Avoid leaking the critical section. */
return scp;
}
@@ -252,15 +259,22 @@ static inline struct srcu_ctr __percpu *__srcu_read_lock_fast(struct srcu_struct
* different CPU than that which was incremented by the corresponding
* srcu_read_lock_fast(), but it must be within the same task.
*
- * Note that this_cpu_inc() is an RCU read-side critical section either
- * because it disables interrupts, because it is a single instruction,
- * or because it is a read-modify-write atomic operation, depending on
- * the whims of the architecture.
+ * Note that both this_cpu_inc() and atomic_long_inc() are RCU read-side
+ * critical sections either because they disables interrupts, because they
+ * are a single instruction, or because they are a read-modify-write atomic
+ * operation, depending on the whims of the architecture.
+ *
+ * This means that __srcu_read_unlock_fast() is not all that fast
+ * on architectures that support NMIs but do not supply NMI-safe
+ * implementations of this_cpu_inc().
*/
static inline void __srcu_read_unlock_fast(struct srcu_struct *ssp, struct srcu_ctr __percpu *scp)
{
barrier(); /* Avoid leaking the critical section. */
- this_cpu_inc(scp->srcu_unlocks.counter); /* Z */
+ if (!IS_ENABLED(CONFIG_NEED_SRCU_NMI_SAFE))
+ this_cpu_inc(scp->srcu_unlocks.counter); /* Z */
+ else
+ atomic_long_inc(raw_cpu_ptr(&scp->srcu_unlocks)); /* Z */
RCU_LOCKDEP_WARN(!rcu_is_watching(), "RCU must be watching srcu_read_unlock_fast().");
}
--
2.39.5 (Apple Git-154)
prev parent reply other threads:[~2025-02-24 2:22 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-24 2:21 [PATCH rcu 00/20] SRCU changes for v6.15 Boqun Feng
2025-02-24 2:21 ` [PATCH rcu 01/20] srcu: Make Tiny SRCU able to operate in preemptible kernels Boqun Feng
2025-02-24 2:21 ` [PATCH rcu 02/20] srcu: Define SRCU_READ_FLAVOR_ALL in terms of symbols Boqun Feng
2025-02-24 2:21 ` [PATCH rcu 03/20] srcu: Use ->srcu_gp_seq for rcutorture reader batch Boqun Feng
2025-02-24 2:21 ` [PATCH rcu 04/20] srcu: Pull ->srcu_{un,}lock_count into a new srcu_ctr structure Boqun Feng
2025-02-24 2:21 ` [PATCH rcu 05/20] srcu: Make SRCU readers use ->srcu_ctrs for counter selection Boqun Feng
2025-02-24 2:22 ` [PATCH rcu 06/20] srcu: Make Tree SRCU updates independent of ->srcu_idx Boqun Feng
2025-02-24 2:22 ` [PATCH rcu 07/20] srcu: Force synchronization for srcu_get_delay() Boqun Feng
2025-02-24 2:22 ` [PATCH rcu 08/20] srcu: Rename srcu_check_read_flavor_lite() to srcu_check_read_flavor_force() Boqun Feng
2025-02-24 2:22 ` [PATCH rcu 09/20] srcu: Add SRCU_READ_FLAVOR_SLOWGP to flag need for synchronize_rcu() Boqun Feng
2025-02-24 2:22 ` [PATCH rcu 10/20] srcu: Pull pointer-to-integer conversion into __srcu_ptr_to_ctr() Boqun Feng
2025-02-24 2:22 ` [PATCH rcu 11/20] srcu: Pull integer-to-pointer conversion into __srcu_ctr_to_ptr() Boqun Feng
2025-02-24 2:22 ` [PATCH rcu 12/20] srcu: Move SRCU Tree/Tiny definitions from srcu.h Boqun Feng
2025-02-24 2:22 ` [PATCH rcu 13/20] srcu: Add SRCU-fast readers Boqun Feng
2025-02-24 2:22 ` [PATCH rcu 14/20] rcutorture: Add ability to test srcu_read_{,un}lock_fast() Boqun Feng
2025-02-24 2:22 ` [PATCH rcu 15/20] refscale: Add srcu_read_lock_fast() support using "srcu-fast" Boqun Feng
2025-02-24 2:22 ` [PATCH rcu 16/20] rcutorture: Make scenario SRCU-P use srcu_read_lock_fast() Boqun Feng
2025-02-24 2:22 ` [PATCH rcu 17/20] srcu: Fix srcu_read_unlock_{lite,nmisafe}() kernel-doc Boqun Feng
2025-02-24 2:22 ` [PATCH rcu 18/20] srcu: Document that srcu_{read_lock,down_read}() can share srcu_struct Boqun Feng
2025-02-24 2:22 ` [PATCH rcu 19/20] srcu: Add srcu_down_read_fast() and srcu_up_read_fast() Boqun Feng
2025-02-24 2:22 ` Boqun Feng [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250224022214.12037-21-boqun.feng@gmail.com \
--to=boqun.feng@gmail.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=dave@stgolabs.net \
--cc=frederic@kernel.org \
--cc=jiangshanlai@gmail.com \
--cc=joel@joelfernandes.org \
--cc=josh@joshtriplett.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=neeraj.upadhyay@kernel.org \
--cc=paulmck@kernel.org \
--cc=qiang.zhang1211@gmail.com \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=shuah@kernel.org \
--cc=urezki@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®