From: Frederic Weisbecker <frederic@kernel.org>
To: LKML <linux-kernel@vger.kernel.org>
Cc: Frederic Weisbecker <frederic@kernel.org>,
Boqun Feng <boqun.feng@gmail.com>,
Joel Fernandes <joel@joelfernandes.org>,
Josh Triplett <josh@joshtriplett.org>,
Lai Jiangshan <jiangshanlai@gmail.com>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
Neeraj Upadhyay <neeraj.upadhyay@amd.com>,
"Paul E . McKenney" <paulmck@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Uladzislau Rezki <urezki@gmail.com>,
Zqiang <qiang.zhang1211@gmail.com>, rcu <rcu@vger.kernel.org>,
"Liam R . Howlett" <Liam.Howlett@oracle.com>,
Peter Zijlstra <peterz@infradead.org>
Subject: [PATCH 2/4] rcu/tasks: Handle new PF_IDLE semantics
Date: Tue, 24 Oct 2023 23:46:23 +0200 [thread overview]
Message-ID: <20231024214625.6483-3-frederic@kernel.org> (raw)
In-Reply-To: <20231024214625.6483-1-frederic@kernel.org>
The commit:
cff9b2332ab7 ("kernel/sched: Modify initial boot task idle setup")
has changed the semantics of what is to be considered an idle task in
such a way that CPU boot code preceding the actual idle loop is excluded
from it.
This has however introduced new potential RCU-tasks stalls when either:
1) Grace period is started before init/0 had a chance to set PF_IDLE,
keeping it stuck in the holdout list until idle ever schedules.
2) Grace period is started when some possible CPUs have never been
online, keeping their idle tasks stuck in the holdout list until the
CPU ever boots up.
3) Similar to 1) but with secondary CPUs: Grace period is started
concurrently with secondary CPU booting, putting its idle task in
the holdout list because PF_IDLE isn't yet observed on it. It stays
then stuck in the holdout list until that CPU ever schedules. The
effect is mitigated here by the hotplug AP thread that must run to
bring the CPU up.
Fix this with handling the new semantics of PF_IDLE, keeping in mind
that it may or may not be set on an idle task. Take advantage of that to
strengthen the coverage of an RCU-tasks quiescent state within an idle
task, excluding the CPU boot code from it. Only the code running within
the idle loop is now a quiescent state, along with offline CPUs.
Fixes: cff9b2332ab7 ("kernel/sched: Modify initial boot task idle setup")
Suggested-by: Joel Fernandes <joel@joelfernandes.org>
Suggested-by: Paul E . McKenney" <paulmck@kernel.org>
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
---
kernel/rcu/tasks.h | 31 +++++++++++++++++++++++++++++--
1 file changed, 29 insertions(+), 2 deletions(-)
diff --git a/kernel/rcu/tasks.h b/kernel/rcu/tasks.h
index bf5f178fe723..acf81efe5eff 100644
--- a/kernel/rcu/tasks.h
+++ b/kernel/rcu/tasks.h
@@ -895,10 +895,37 @@ static void rcu_tasks_pregp_step(struct list_head *hop)
synchronize_rcu();
}
+/* Check for quiescent states since the pregp's synchronize_rcu() */
+static bool rcu_tasks_is_holdout(struct task_struct *t)
+{
+ int cpu;
+
+ /* Has the task been seen voluntarily sleeping? */
+ if (!READ_ONCE(t->on_rq))
+ return false;
+
+ cpu = task_cpu(t);
+
+ /*
+ * Idle tasks within the idle loop or offline CPUs are RCU-tasks
+ * quiescent states. But CPU boot code performed by the idle task
+ * isn't a quiescent state.
+ */
+ if (t == idle_task(cpu)) {
+ if (is_idle_task(t))
+ return false;
+
+ if (!rcu_cpu_online(cpu))
+ return false;
+ }
+
+ return true;
+}
+
/* Per-task initial processing. */
static void rcu_tasks_pertask(struct task_struct *t, struct list_head *hop)
{
- if (t != current && READ_ONCE(t->on_rq) && !is_idle_task(t)) {
+ if (t != current && rcu_tasks_is_holdout(t)) {
get_task_struct(t);
t->rcu_tasks_nvcsw = READ_ONCE(t->nvcsw);
WRITE_ONCE(t->rcu_tasks_holdout, true);
@@ -947,7 +974,7 @@ static void check_holdout_task(struct task_struct *t,
if (!READ_ONCE(t->rcu_tasks_holdout) ||
t->rcu_tasks_nvcsw != READ_ONCE(t->nvcsw) ||
- !READ_ONCE(t->on_rq) ||
+ !rcu_tasks_is_holdout(t) ||
(IS_ENABLED(CONFIG_NO_HZ_FULL) &&
!is_idle_task(t) && READ_ONCE(t->rcu_tasks_idle_cpu) >= 0)) {
WRITE_ONCE(t->rcu_tasks_holdout, false);
--
2.41.0
next prev parent reply other threads:[~2023-10-24 21:46 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-24 21:46 [PATCH 0/4] rcu: Fix PF_IDLE related issues v2 Frederic Weisbecker
2023-10-24 21:46 ` [PATCH 1/4] rcu: Introduce rcu_cpu_online() Frederic Weisbecker
2023-10-25 2:29 ` Z qiang
2023-10-25 10:32 ` Frederic Weisbecker
2023-10-24 21:46 ` Frederic Weisbecker [this message]
2023-10-25 8:40 ` [PATCH 2/4] rcu/tasks: Handle new PF_IDLE semantics Peter Zijlstra
2023-10-25 10:31 ` Frederic Weisbecker
2023-10-26 12:15 ` Z qiang
2023-10-26 14:34 ` Frederic Weisbecker
2023-10-24 21:46 ` [PATCH 3/4] rcu/tasks-trace: " Frederic Weisbecker
2023-10-24 21:46 ` [PATCH 4/4] sched: Exclude CPU boot code from PF_IDLE area Frederic Weisbecker
2023-10-25 8:48 ` Peter Zijlstra
2023-10-25 11:25 ` Frederic Weisbecker
[not found] <20231027144050.110601-1-frederic@kernel.org>
[not found] ` <20231027144050.110601-3-frederic@kernel.org>
2023-10-27 19:20 ` [PATCH 2/4] rcu/tasks: Handle new PF_IDLE semantics Peter Zijlstra
2023-10-27 21:23 ` Paul E. McKenney
2023-10-27 22:46 ` Peter Zijlstra
2023-10-27 23:41 ` Paul E. McKenney
2023-10-30 8:21 ` Peter Zijlstra
2023-10-30 20:11 ` Paul E. McKenney
2023-10-31 9:52 ` Peter Zijlstra
2023-10-31 14:16 ` Michael Matz
2023-10-31 14:43 ` Paul E. McKenney
2023-10-31 15:16 ` Peter Zijlstra
2023-10-31 15:55 ` Michael Matz
2023-10-31 16:23 ` Peter Zijlstra
2023-10-31 16:49 ` Michael Matz
2023-10-31 17:10 ` Paul E. McKenney
2023-10-31 14:24 ` Paul E. McKenney
2023-10-31 15:20 ` Peter Zijlstra
2023-10-31 18:12 ` Paul E. McKenney
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=20231024214625.6483-3-frederic@kernel.org \
--to=frederic@kernel.org \
--cc=Liam.Howlett@oracle.com \
--cc=boqun.feng@gmail.com \
--cc=jiangshanlai@gmail.com \
--cc=joel@joelfernandes.org \
--cc=josh@joshtriplett.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=neeraj.upadhyay@amd.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.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