From: "Joel Fernandes (Google)" <joel@joelfernandes.org>
To: linux-kernel@vger.kernel.org
Cc: "Joel Fernandes (Google)" <joel@joelfernandes.org>,
Davidlohr Bueso <dave@stgolabs.net>,
Jonathan Corbet <corbet@lwn.net>,
Josh Triplett <josh@joshtriplett.org>,
Lai Jiangshan <jiangshanlai@gmail.com>,
linux-doc@vger.kernel.org,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Mauro Carvalho Chehab <mchehab+samsung@kernel.org>,
neeraju@codeaurora.org, "Paul E. McKenney" <paulmck@kernel.org>,
peterz@infradead.org, Randy Dunlap <rdunlap@infradead.org>,
rcu@vger.kernel.org, Steven Rostedt <rostedt@goodmis.org>,
tglx@linutronix.de, vineethrp@gmail.com
Subject: [PATCH v4 3/5] rcu/tree: Make FQS complaining about offline CPU more aggressive
Date: Fri, 7 Aug 2020 13:07:20 -0400 [thread overview]
Message-ID: <20200807170722.2897328-4-joel@joelfernandes.org> (raw)
In-Reply-To: <20200807170722.2897328-1-joel@joelfernandes.org>
The FQS loop detecting that an offline CPU has not yet reported a
quiescent state, is a serious problem. The current interaction between
RCU quiescent-state reporting and CPU-hotplug operations means that the
FQS loop should never find that an offline CPU (by RCU's understanding
of what is offline or not) has not yet reported a quiescent state.
First, the outgoing CPU explicitly reports a quiescent state if needed
in rcu_report_dead(). Second, the race where the CPU is leaving just as
RCU is initializing a new grace period is handled by an explicit check
for this condition in rcu_gp_init(). Third, the CPU's leaf rcu_node
structure's ->lock serializes these modifications and checks.
At the moment, the FQS loop detections this anomaly but only reports it
after a second has elapsed.
This commit therefore makes the warning more aggressive such that we fail
immediately when the FQS loop scan happens and bring the problem to
everyone's attention.
Light testing with TREE03 and hotplug shows no warnings. Converted the
warning as well to WARN_ON_ONCE() to reduce log spam.
Signed-off-by: Joel Fernandes (Google) <joel@joelfernandes.org>
---
kernel/rcu/tree.c | 22 ++++++++++++++++++----
1 file changed, 18 insertions(+), 4 deletions(-)
diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 2fb66cdbfa25..850628aba813 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -1208,13 +1208,27 @@ static int rcu_implicit_dynticks_qs(struct rcu_data *rdp)
return 1;
}
- /* If waiting too long on an offline CPU, complain. */
- if (!(rdp->grpmask & rcu_rnp_online_cpus(rnp)) &&
- time_after(jiffies, rcu_state.gp_start + HZ)) {
+ /*
+ * Complain if an offline CPU by RCU's hotplug bookkeeping has not
+ * reported a quiescent state yet.
+ *
+ * Either a quiescent state for the offline CPU should have been
+ * reported during CPU offlining, or during rcu_gp_init() if it
+ * detected a race with either CPU offlining or task unblocking on a
+ * node with all of its CPUs previously offlined. If neither of these
+ * happened, we have a problem.
+ *
+ * The node lock is held here, ensuring exclusion from the
+ * modification/checking of RCU's hotplug books by RCU's hotplug
+ * notifier hooks and grace period initialization code.
+ *
+ * Refer to RCU's Requirements documentation about hotplug requirements
+ * as well.
+ */
+ if (WARN_ON_ONCE(!(rdp->grpmask & rcu_rnp_online_cpus(rnp)))) {
bool onl;
struct rcu_node *rnp1;
- WARN_ON(1); /* Offline CPUs are supposed to report QS! */
pr_info("%s: grp: %d-%d level: %d ->gp_seq %ld ->completedqs %ld\n",
__func__, rnp->grplo, rnp->grphi, rnp->level,
(long)rnp->gp_seq, (long)rnp->completedqs);
--
2.28.0.236.gb10cc79966-goog
next prev parent reply other threads:[~2020-08-07 17:08 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-07 17:07 [PATCH v4 0/5] option-subject: RCU and CPU hotplug checks and docs Joel Fernandes (Google)
2020-08-07 17:07 ` [PATCH v4 1/5] rcu/tree: Add a warning if CPU being onlined did not report QS already Joel Fernandes (Google)
2020-08-10 15:46 ` Paul E. McKenney
2020-08-10 17:39 ` Joel Fernandes
2020-08-10 17:57 ` Paul E. McKenney
2020-08-10 19:25 ` Joel Fernandes
2020-08-10 20:20 ` Paul E. McKenney
2020-08-07 17:07 ` [PATCH v4 2/5] rcu/tree: Clarify comments about FQS loop reporting quiescent states Joel Fernandes (Google)
2020-08-10 18:06 ` Paul E. McKenney
2020-08-10 19:22 ` Joel Fernandes
2020-08-07 17:07 ` Joel Fernandes (Google) [this message]
2020-08-10 20:56 ` [PATCH v4 3/5] rcu/tree: Make FQS complaining about offline CPU more aggressive Paul E. McKenney
2020-08-07 17:07 ` [PATCH v4 4/5] rcutorture: Force synchronizing of RCU flavor from hotplug notifier Joel Fernandes (Google)
2020-08-10 16:19 ` Paul E. McKenney
2020-08-10 17:31 ` Joel Fernandes
2020-08-10 17:54 ` Paul E. McKenney
2020-08-10 19:41 ` Joel Fernandes
2020-08-07 17:07 ` [PATCH v4 5/5] docs: Update RCU's hotplug requirements with a bit about design Joel Fernandes (Google)
2020-08-08 2:10 ` Randy Dunlap
2020-08-10 17:41 ` Joel Fernandes
2020-08-07 18:31 ` [PATCH v4 0/5] option-subject: RCU and CPU hotplug checks and docs Joel Fernandes
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=20200807170722.2897328-4-joel@joelfernandes.org \
--to=joel@joelfernandes.org \
--cc=corbet@lwn.net \
--cc=dave@stgolabs.net \
--cc=jiangshanlai@gmail.com \
--cc=josh@joshtriplett.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mchehab+samsung@kernel.org \
--cc=neeraju@codeaurora.org \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=rcu@vger.kernel.org \
--cc=rdunlap@infradead.org \
--cc=rostedt@goodmis.org \
--cc=tglx@linutronix.de \
--cc=vineethrp@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