From: Boqun Feng <boqun.feng@gmail.com>
To: linux-kernel@vger.kernel.org, rcu@vger.kernel.org,
linux-doc@vger.kernel.org
Cc: Jonathan Corbet <corbet@lwn.net>,
"Paul E. McKenney" <paulmck@kernel.org>,
Frederic Weisbecker <frederic@kernel.org>,
Neeraj Upadhyay <neeraj.iitr10@gmail.com>,
Joel Fernandes <joel@joelfernandes.org>,
Josh Triplett <josh@joshtriplett.org>,
Boqun Feng <boqun.feng@gmail.com>,
Steven Rostedt <rostedt@goodmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Lai Jiangshan <jiangshanlai@gmail.com>,
Zqiang <qiang.zhang1211@gmail.com>
Subject: [PATCH 8/8] doc: Update checklist.rst discussion of callback execution
Date: Thu, 25 Jan 2024 19:58:11 -0800 [thread overview]
Message-ID: <20240126035816.3129296-9-boqun.feng@gmail.com> (raw)
In-Reply-To: <20240126035816.3129296-1-boqun.feng@gmail.com>
From: "Paul E. McKenney" <paulmck@kernel.org>
This commit completes the list of call_rcu*() functions that are not
guaranteed to have their callbacks executing on the same CPU. While in
the area, fix an unrelated typo.
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
---
Documentation/RCU/checklist.rst | 21 +++++++++++----------
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/Documentation/RCU/checklist.rst b/Documentation/RCU/checklist.rst
index addd5c1547a4..3e6407de231c 100644
--- a/Documentation/RCU/checklist.rst
+++ b/Documentation/RCU/checklist.rst
@@ -383,16 +383,17 @@ over a rather long period of time, but improvements are always welcome!
must use whatever locking or other synchronization is required
to safely access and/or modify that data structure.
- Do not assume that RCU callbacks will be executed on the same
- CPU that executed the corresponding call_rcu() or call_srcu().
- For example, if a given CPU goes offline while having an RCU
- callback pending, then that RCU callback will execute on some
- surviving CPU. (If this was not the case, a self-spawning RCU
- callback would prevent the victim CPU from ever going offline.)
- Furthermore, CPUs designated by rcu_nocbs= might well *always*
- have their RCU callbacks executed on some other CPUs, in fact,
- for some real-time workloads, this is the whole point of using
- the rcu_nocbs= kernel boot parameter.
+ Do not assume that RCU callbacks will be executed on
+ the same CPU that executed the corresponding call_rcu(),
+ call_srcu(), call_rcu_tasks(), call_rcu_tasks_rude(), or
+ call_rcu_tasks_trace(). For example, if a given CPU goes offline
+ while having an RCU callback pending, then that RCU callback
+ will execute on some surviving CPU. (If this was not the case,
+ a self-spawning RCU callback would prevent the victim CPU from
+ ever going offline.) Furthermore, CPUs designated by rcu_nocbs=
+ might well *always* have their RCU callbacks executed on some
+ other CPUs, in fact, for some real-time workloads, this is the
+ whole point of using the rcu_nocbs= kernel boot parameter.
In addition, do not assume that callbacks queued in a given order
will be invoked in that order, even if they all are queued on the
--
2.43.0
prev parent reply other threads:[~2024-01-26 3:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-26 3:58 [PATCH 0/8] RCU doc updates for v6.9 Boqun Feng
2024-01-26 3:58 ` [PATCH 1/8] doc: Spinlocks are implied RCU readers Boqun Feng
2024-01-26 3:58 ` [PATCH 2/8] doc: Make whatisRCU.rst note that spinlocks are " Boqun Feng
2024-01-26 3:58 ` [PATCH 3/8] doc: Make checklist.rst note that spinlocks are implied " Boqun Feng
2024-01-26 3:58 ` [PATCH 4/8] doc: Add CONFIG_RCU_STRICT_GRACE_PERIOD to checklist.rst Boqun Feng
2024-01-26 3:58 ` [PATCH 5/8] doc: Add EARLY flag to early-parsed kernel boot parameters Boqun Feng
2024-01-26 3:58 ` [PATCH 6/8] context_tracking: Fix kerneldoc headers for __ct_user_{enter,exit}() Boqun Feng
2024-01-26 3:58 ` [PATCH 7/8] doc: Clarify use of slab constructors and SLAB_TYPESAFE_BY_RCU Boqun Feng
2024-01-26 3:58 ` 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=20240126035816.3129296-9-boqun.feng@gmail.com \
--to=boqun.feng@gmail.com \
--cc=corbet@lwn.net \
--cc=frederic@kernel.org \
--cc=jiangshanlai@gmail.com \
--cc=joel@joelfernandes.org \
--cc=josh@joshtriplett.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=neeraj.iitr10@gmail.com \
--cc=paulmck@kernel.org \
--cc=qiang.zhang1211@gmail.com \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
/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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).