All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: LKML <linux-kernel@vger.kernel.org>
Cc: x86@kernel.org, Ashok Raj <ashok.raj@linux.intel.com>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Tony Luck <tony.luck@intel.com>,
	Arjan van de Veen <arjan@linux.intel.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Eric Biederman <ebiederm@xmission.com>
Subject: [patch 2/6] x86/smp: Acquire stopping_cpu unconditionally
Date: Sat,  3 Jun 2023 22:06:58 +0200 (CEST)	[thread overview]
Message-ID: <20230603200459.717231106@linutronix.de> (raw)
In-Reply-To: 20230603193439.502645149@linutronix.de

There is no reason to acquire the stopping_cpu atomic_t only when there is
more than one online CPU.

Make it unconditional to prepare for fixing the kexec() problem when there
are present but "offline" CPUs which play dead in mwait_play_dead().

They need to be brought out of mwait before kexec() as kexec() can
overwrite text, pagetables, stacks and the monitored cacheline of the
original kernel. The latter causes mwait to resume execution which
obviously causes havoc on the kexec kernel which results usually in triple
faults.

Move the acquire out of the num_online_cpus() > 1 condition so the upcoming
'kick mwait' fixup is properly protected.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
 arch/x86/kernel/smp.c |    8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

--- a/arch/x86/kernel/smp.c
+++ b/arch/x86/kernel/smp.c
@@ -152,6 +152,10 @@ static void native_stop_other_cpus(int w
 	if (reboot_force)
 		return;
 
+	/* Only proceed if this is the first CPU to reach this code */
+	if (atomic_cmpxchg(&stopping_cpu, -1, safe_smp_processor_id()) != -1)
+		return;
+
 	/*
 	 * Use an own vector here because smp_call_function
 	 * does lots of things not suitable in a panic situation.
@@ -167,10 +171,6 @@ static void native_stop_other_cpus(int w
 	 * finish their work before we force them off with the NMI.
 	 */
 	if (num_online_cpus() > 1) {
-		/* did someone beat us here? */
-		if (atomic_cmpxchg(&stopping_cpu, -1, safe_smp_processor_id()) != -1)
-			return;
-
 		apic_send_IPI_allbutself(REBOOT_VECTOR);
 
 		/*


  parent reply	other threads:[~2023-06-03 20:07 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-03 20:06 [patch 0/6] Cure kexec() vs. mwait_play_dead() troubles Thomas Gleixner
2023-06-03 20:06 ` [patch 1/6] x86/smp: Remove pointless wmb() from native_stop_other_cpus() Thomas Gleixner
2023-06-03 20:06 ` Thomas Gleixner [this message]
2023-06-03 20:07 ` [patch 3/6] x86/smp: Use dedicated cache-line for mwait_play_dead() Thomas Gleixner
2023-06-03 20:07 ` [patch 4/6] x86/smp: Cure kexec() vs. mwait_play_dead() breakage Thomas Gleixner
2023-06-03 20:54   ` Ashok Raj
2023-06-04  3:19   ` Ashok Raj
2023-06-05  7:41     ` Thomas Gleixner
2023-06-03 20:07 ` [patch 5/6] x86/smp: Split sending INIT IPI out into a helper function Thomas Gleixner
2023-06-04  4:02   ` Mika Penttilä
2023-06-04 10:24     ` Ashok Raj
2023-06-05  7:54     ` Thomas Gleixner
2023-06-05  8:23   ` [patch v2 " Thomas Gleixner
2023-06-03 20:07 ` [patch 6/6] x86/smp: Put CPUs into INIT on shutdown if possible Thomas Gleixner
2023-06-03 20:57   ` Ashok Raj
2023-06-05 17:41 ` [patch 0/6] Cure kexec() vs. mwait_play_dead() troubles Sean Christopherson
2023-06-05 22:41   ` Thomas Gleixner
2023-06-05 23:08     ` Sean Christopherson
2023-06-06  7:20       ` Thomas Gleixner
2023-06-07 16:21     ` Ashok Raj
2023-06-07 17:33       ` Sean Christopherson
2023-06-07 22:19         ` Ashok Raj
2023-06-08  3:46           ` Sean Christopherson
2023-06-08  4:03             ` Ashok Raj
2023-06-16 15:07             ` Ashok Raj
2023-06-16 19:00               ` Sean Christopherson
2023-06-16 19:03                 ` Ashok Raj
2023-06-16 19:08                   ` Sean Christopherson
2023-06-09  8:40         ` Paolo Bonzini

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=20230603200459.717231106@linutronix.de \
    --to=tglx@linutronix.de \
    --cc=arjan@linux.intel.com \
    --cc=ashok.raj@linux.intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.