linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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>,
	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>, rcu <rcu@vger.kernel.org>,
	Zqiang <qiang.zhang1211@gmail.com>,
	Lai Jiangshan <jiangshanlai@gmail.com>,
	"Liam R . Howlett" <Liam.Howlett@oracle.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Sebastian Siewior <bigeasy@linutronix.de>,
	Thomas Gleixner <tglx@linutronix.de>
Subject: [PATCH 4/4] Revert "kernel/sched: Modify initial boot task idle setup"
Date: Fri, 20 Oct 2023 01:35:43 +0200	[thread overview]
Message-ID: <20231019233543.1243121-5-frederic@kernel.org> (raw)
In-Reply-To: <20231019233543.1243121-1-frederic@kernel.org>

Now that rcutiny can deal with early boot PF_IDLE setting, revert
commit cff9b2332ab762b7e0586c793c431a8f2ea4db04.

This fixes several subtle issues introduced on RCU-tasks(-trace):

1) RCU-tasks stalls when:

   1.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.

   1.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.

   1.3 Similar to 1.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 all the smpboot
       kthreads and the hotplug AP thread that must run to bring the
       CPU up.

2) Spurious warning on RCU task trace that assumes offline CPU's idle
   task is always PF_IDLE.

More issues have been found in RCU-tasks related to PF_IDLE which should
be fixed with later changes as those are not regressions:

3) The RCU-Tasks semantics consider the idle loop as a quiescent state,
   however:

   3.1 The boot code preceding the idle entry is included in this
       quiescent state. Especially after the completion of kthreadd_done
       after which init/1 can launch userspace concurrently. The window
       is tiny before PF_IDLE is set but it exists.

   3.2 Similarly, the boot code preceding the idle entry on secondary
       CPUs is wrongly accounted as RCU tasks quiescent state.

Fixes: cff9b2332ab7 ("kernel/sched: Modify initial boot task idle setup")
Cc: Liam R. Howlett <Liam.Howlett@oracle.com>
Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
Cc: Sebastian Siewior <bigeasy@linutronix.de>
Cc: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Frederic Weisbecker <frederic@kernel.org>
---
 kernel/sched/core.c | 2 +-
 kernel/sched/idle.c | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index ad960f97e4e1..b02dcbe98024 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -9269,7 +9269,7 @@ void __init init_idle(struct task_struct *idle, int cpu)
 	 * PF_KTHREAD should already be set at this point; regardless, make it
 	 * look like a proper per-CPU kthread.
 	 */
-	idle->flags |= PF_KTHREAD | PF_NO_SETAFFINITY;
+	idle->flags |= PF_IDLE | PF_KTHREAD | PF_NO_SETAFFINITY;
 	kthread_set_per_cpu(idle, cpu);
 
 #ifdef CONFIG_SMP
diff --git a/kernel/sched/idle.c b/kernel/sched/idle.c
index 5007b25c5bc6..342f58a329f5 100644
--- a/kernel/sched/idle.c
+++ b/kernel/sched/idle.c
@@ -373,7 +373,6 @@ EXPORT_SYMBOL_GPL(play_idle_precise);
 
 void cpu_startup_entry(enum cpuhp_state state)
 {
-	current->flags |= PF_IDLE;
 	arch_cpu_idle_prepare();
 	cpuhp_online_idle(state);
 	while (1)
-- 
2.34.1


  parent reply	other threads:[~2023-10-19 23:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-19 23:35 [PATCH 0/4] rcu: Fix PF_IDLE related issues, part. 1 Frederic Weisbecker
2023-10-19 23:35 ` [PATCH 1/4] softirq: Rename __raise_softirq_irqoff() to raise_softirq_no_wake() Frederic Weisbecker
2023-10-19 23:35 ` [PATCH 2/4] softirq: Introduce raise_ksoftirqd_irqoff() Frederic Weisbecker
2023-10-19 23:35 ` [PATCH 3/4] rcu: Make tiny RCU use ksoftirqd to trigger a QS from idle Frederic Weisbecker
2023-10-20  0:49   ` Paul E. McKenney
2023-10-19 23:35 ` Frederic Weisbecker [this message]
2023-10-20  8:25   ` [PATCH 4/4] Revert "kernel/sched: Modify initial boot task idle setup" Peter Zijlstra
2023-10-20 12:31     ` Frederic Weisbecker
2023-10-20 13:48       ` Peter Zijlstra
2023-10-20 15:05         ` 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=20231019233543.1243121-5-frederic@kernel.org \
    --to=frederic@kernel.org \
    --cc=Liam.Howlett@oracle.com \
    --cc=bigeasy@linutronix.de \
    --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=tglx@linutronix.de \
    --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;
as well as URLs for NNTP newsgroup(s).