From: "Joel Fernandes (Google)" <joel@joelfernandes.org>
To: linux-kernel@vger.kernel.org, frederic@kernel.org,
boqun.feng@gmail.com, urezki@gmail.com, neeraj.iitr10@gmail.com,
joel@joelfernandes.org, rcu@vger.kernel.org, rostedt@goodmis.org,
"Paul E. McKenney" <paulmck@kernel.org>,
Neeraj Upadhyay <neeraj.upadhyay@kernel.org>,
Josh Triplett <josh@joshtriplett.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Lai Jiangshan <jiangshanlai@gmail.com>,
Zqiang <qiang.zhang1211@gmail.com>
Subject: [PATCH v2 rcu/dev 2/2] rcu/tree: Add comments explaining now-offline-CPU QS reports
Date: Fri, 8 Mar 2024 17:44:38 -0500 [thread overview]
Message-ID: <20240308224439.281349-2-joel@joelfernandes.org> (raw)
In-Reply-To: <20240308224439.281349-1-joel@joelfernandes.org>
This a confusing piece of code (rightfully so as the issue it deals with
is complex). Recent discussions brought up a question -- what prevents the
rcu_implicit_dyntick_qs() from warning about QS reports for offline
CPUs.
QS reporting for now-offline CPUs should only happen from:
- gp_init()
- rcutree_cpu_report_dead()
Add some comments to this code explaining how QS reporting is not
missed when these functions are concurrently running.
Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
---
kernel/rcu/tree.c | 36 +++++++++++++++++++++++++++++++++++-
1 file changed, 35 insertions(+), 1 deletion(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index bd29fe3c76bf..f3582f843a05 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1917,7 +1917,22 @@ static noinline_for_stack bool rcu_gp_init(void)
trace_rcu_grace_period_init(rcu_state.name, rnp->gp_seq,
rnp->level, rnp->grplo,
rnp->grphi, rnp->qsmask);
- /* Quiescent states for tasks on any now-offline CPUs. */
+ /*
+ * === Quiescent states for tasks on any now-offline CPUs. ===
+ *
+ * QS reporting for now-offline CPUs should only be performed from
+ * either here, i.e., gp_init() or from rcutree_report_cpu_dead().
+ *
+ * Note that, when reporting quiescent states for now-offline CPUs,
+ * the sequence of code doing those reports while also accessing
+ * ->qsmask and ->qsmaskinitnext, has to be an atomic sequence so
+ * that QS reporting is not missed! Otherwise it possible that
+ * rcu_implicit_dyntick_qs() screams. This is ensured by keeping
+ * the rnp->lock acquired throughout these QS-reporting
+ * sequences, which is also acquired in
+ * rcutree_report_cpu_dead(), so, acquiring ofl_lock is not
+ * necessary here to synchronize with that function.
+ */
mask = rnp->qsmask & ~rnp->qsmaskinitnext;
rnp->rcu_gp_init_mask = mask;
if ((mask || rnp->wait_blkd_tasks) && rcu_is_leaf_node(rnp))
@@ -5116,6 +5131,25 @@ void rcutree_report_cpu_dead(void)
raw_spin_lock_irqsave_rcu_node(rnp, flags); /* Enforce GP memory-order guarantee. */
rdp->rcu_ofl_gp_seq = READ_ONCE(rcu_state.gp_seq);
rdp->rcu_ofl_gp_state = READ_ONCE(rcu_state.gp_state);
+
+ /*
+ * === Quiescent state reporting for now-offline CPUs ===
+ *
+ * QS reporting for now-offline CPUs should only be performed from
+ * either here, i.e. rcutree_report_cpu_dead(), or gp_init().
+ *
+ * Note that, when reporting quiescent states for now-offline CPUs,
+ * the sequence of code doing those reports while also accessing
+ * ->qsmask and ->qsmaskinitnext, has to be an atomic sequence so
+ * that QS reporting is not missed! Otherwise it possible that
+ * rcu_implicit_dyntick_qs() screams. This is ensured by keeping
+ * the rnp->lock acquired throughout these QS-reporting sequences, which
+ * is also acquired in gp_init().
+ * One slight change to this rule is below, where we release and
+ * reacquire the lock after a QS report, but before we clear the
+ * ->qsmaskinitnext bit. That is OK to do, because gp_init() report a
+ * QS again, if it acquired the rnp->lock before we reacquired below.
+ */
if (rnp->qsmask & mask) { /* RCU waiting on outgoing CPU? */
/* Report quiescent state -before- changing ->qsmaskinitnext! */
rcu_disable_urgency_upon_qs(rdp);
--
2.34.1
next prev parent reply other threads:[~2024-03-08 22:44 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-08 22:44 [PATCH v2 rcu/dev 1/2] rcu/tree: Reduce wake up for synchronize_rcu() common case Joel Fernandes (Google)
2024-03-08 22:44 ` Joel Fernandes (Google) [this message]
2024-03-10 19:43 ` [PATCH v2 rcu/dev 2/2] rcu/tree: Add comments explaining now-offline-CPU QS reports Paul E. McKenney
2024-03-11 16:01 ` Joel Fernandes
2024-03-18 18:58 ` [PATCH v2 rcu/dev 1/2] rcu/tree: Reduce wake up for synchronize_rcu() common case Uladzislau Rezki
2024-03-18 21:05 ` Joel Fernandes
2024-03-19 9:53 ` Uladzislau Rezki
2024-03-19 14:29 ` Joel Fernandes
2024-03-19 14:48 ` Uladzislau Rezki
2024-03-19 16:02 ` Joel Fernandes
2024-03-19 16:11 ` Joel Fernandes
2024-03-19 17:26 ` Uladzislau Rezki
2024-03-19 17:29 ` Joel Fernandes
2024-03-19 17:33 ` Joel Fernandes
2024-03-19 18:37 ` Uladzislau Rezki
2024-03-19 18:52 ` Joel Fernandes
2024-03-19 19:07 ` Uladzislau Rezki
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=20240308224439.281349-2-joel@joelfernandes.org \
--to=joel@joelfernandes.org \
--cc=boqun.feng@gmail.com \
--cc=frederic@kernel.org \
--cc=jiangshanlai@gmail.com \
--cc=josh@joshtriplett.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=neeraj.iitr10@gmail.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=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®