From: Thomas Gleixner <tglx@linutronix.de>
To: LKML <linux-kernel@vger.kernel.org>
Cc: x86@kernel.org, Mario Limonciello <mario.limonciello@amd.com>,
Tom Lendacky <thomas.lendacky@amd.com>,
Tony Battersby <tonyb@cybernetics.com>,
Ashok Raj <ashok.raj@linux.intel.com>,
Tony Luck <tony.luck@intel.com>,
Arjan van de Veen <arjan@linux.intel.com>,
Eric Biederman <ebiederm@xmission.com>,
Ashok Raj <ashok.raj@intel.com>
Subject: [patch V2 4/8] x86/smp: Acquire stopping_cpu unconditionally
Date: Tue, 13 Jun 2023 14:17:59 +0200 (CEST) [thread overview]
Message-ID: <20230613121615.820042015@linutronix.de> (raw)
In-Reply-To: 20230613115353.599087484@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>
Reviewed-by: Ashok Raj <ashok.raj@intel.com>
---
arch/x86/kernel/smp.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
--- a/arch/x86/kernel/smp.c
+++ b/arch/x86/kernel/smp.c
@@ -153,6 +153,12 @@ 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;
+
+ atomic_set(&stop_cpus_count, num_online_cpus() - 1);
+
/*
* Use an own vector here because smp_call_function
* does lots of things not suitable in a panic situation.
@@ -167,13 +173,7 @@ static void native_stop_other_cpus(int w
* code. By syncing, we give the cpus up to one second to
* 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;
-
- atomic_set(&stop_cpus_count, num_online_cpus() - 1);
-
+ if (atomic_read(&stop_cpus_count) > 0) {
apic_send_IPI_allbutself(REBOOT_VECTOR);
/*
next prev parent reply other threads:[~2023-06-13 12:18 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-13 12:17 [patch V2 0/8] x86/smp: Cure stop_other_cpus() and kexec() troubles Thomas Gleixner
2023-06-13 12:17 ` [patch V2 1/8] x86/smp: Make stop_other_cpus() more robust Thomas Gleixner
2023-06-14 19:42 ` Ashok Raj
2023-06-14 19:53 ` Thomas Gleixner
2023-06-14 20:47 ` Ashok Raj
2023-06-14 22:40 ` Thomas Gleixner
2023-06-13 12:17 ` [patch V2 2/8] x86/smp: Dont access non-existing CPUID leaf Thomas Gleixner
2023-06-13 12:17 ` [patch V2 3/8] x86/smp: Remove pointless wmb() from native_stop_other_cpus() Thomas Gleixner
2023-06-15 8:58 ` Peter Zijlstra
2023-06-15 10:57 ` Thomas Gleixner
2023-06-13 12:17 ` Thomas Gleixner [this message]
2023-06-15 9:02 ` [patch V2 4/8] x86/smp: Acquire stopping_cpu unconditionally Peter Zijlstra
2023-06-13 12:18 ` [patch V2 5/8] x86/smp: Use dedicated cache-line for mwait_play_dead() Thomas Gleixner
2023-06-13 12:18 ` [patch V2 6/8] x86/smp: Cure kexec() vs. mwait_play_dead() breakage Thomas Gleixner
2023-06-13 12:18 ` [patch V2 7/8] x86/smp: Split sending INIT IPI out into a helper function Thomas Gleixner
2023-06-13 12:18 ` [patch V2 8/8] x86/smp: Put CPUs into INIT on shutdown if possible Thomas Gleixner
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=20230613121615.820042015@linutronix.de \
--to=tglx@linutronix.de \
--cc=arjan@linux.intel.com \
--cc=ashok.raj@intel.com \
--cc=ashok.raj@linux.intel.com \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mario.limonciello@amd.com \
--cc=thomas.lendacky@amd.com \
--cc=tony.luck@intel.com \
--cc=tonyb@cybernetics.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox