From: tip-bot for Borislav Petkov <tipbot@zytor.com>
To: linux-tip-commits@vger.kernel.org
Cc: mingo@kernel.org, linux-kernel@vger.kernel.org, bp@suse.de,
tglx@linutronix.de, hpa@zytor.com
Subject: [tip:ras/core] x86/mce: Carve out the crashing_cpu check
Date: Fri, 22 Jun 2018 05:41:12 -0700 [thread overview]
Message-ID: <tip-d3d6923cd1ae61a493a405f2f001293ab62eb092@git.kernel.org> (raw)
In-Reply-To: <20180622095428.626-4-bp@alien8.de>
Commit-ID: d3d6923cd1ae61a493a405f2f001293ab62eb092
Gitweb: https://git.kernel.org/tip/d3d6923cd1ae61a493a405f2f001293ab62eb092
Author: Borislav Petkov <bp@suse.de>
AuthorDate: Fri, 22 Jun 2018 11:54:24 +0200
Committer: Thomas Gleixner <tglx@linutronix.de>
CommitDate: Fri, 22 Jun 2018 14:37:22 +0200
x86/mce: Carve out the crashing_cpu check
Carve out the rendezvous handler timeout avoidance check into a separate
function in order to simplify the #MC handler.
No functional changes.
Signed-off-by: Borislav Petkov <bp@suse.de>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lkml.kernel.org/r/20180622095428.626-4-bp@alien8.de
---
arch/x86/kernel/cpu/mcheck/mce.c | 64 +++++++++++++++++++++++-----------------
1 file changed, 37 insertions(+), 27 deletions(-)
diff --git a/arch/x86/kernel/cpu/mcheck/mce.c b/arch/x86/kernel/cpu/mcheck/mce.c
index d62201e40027..18804834dbc0 100644
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1104,6 +1104,34 @@ static void mce_unmap_kpfn(unsigned long pfn)
}
#endif
+
+/*
+ * Cases where we avoid rendezvous handler timeout:
+ * 1) If this CPU is offline.
+ *
+ * 2) If crashing_cpu was set, e.g. we're entering kdump and we need to
+ * skip those CPUs which remain looping in the 1st kernel - see
+ * crash_nmi_callback().
+ *
+ * Note: there still is a small window between kexec-ing and the new,
+ * kdump kernel establishing a new #MC handler where a broadcasted MCE
+ * might not get handled properly.
+ */
+static bool __mc_check_crashing_cpu(int cpu)
+{
+ if (cpu_is_offline(cpu) ||
+ (crashing_cpu != -1 && crashing_cpu != cpu)) {
+ u64 mcgstatus;
+
+ mcgstatus = mce_rdmsrl(MSR_IA32_MCG_STATUS);
+ if (mcgstatus & MCG_STATUS_RIPV) {
+ mce_wrmsrl(MSR_IA32_MCG_STATUS, 0);
+ return true;
+ }
+ }
+ return false;
+}
+
/*
* The actual machine check handler. This only handles real
* exceptions when something got corrupted coming in through int 18.
@@ -1118,60 +1146,42 @@ static void mce_unmap_kpfn(unsigned long pfn)
*/
void do_machine_check(struct pt_regs *regs, long error_code)
{
+ DECLARE_BITMAP(valid_banks, MAX_NR_BANKS);
+ DECLARE_BITMAP(toclear, MAX_NR_BANKS);
struct mca_config *cfg = &mca_cfg;
+ int cpu = smp_processor_id();
+ char *msg = "Unknown";
struct mce m, *final;
- int i;
int worst = 0;
int severity;
+ int i;
/*
* Establish sequential order between the CPUs entering the machine
* check handler.
*/
int order = -1;
+
/*
* If no_way_out gets set, there is no safe way to recover from this
* MCE. If mca_cfg.tolerant is cranked up, we'll try anyway.
*/
int no_way_out = 0;
+
/*
* If kill_it gets set, there might be a way to recover from this
* error.
*/
int kill_it = 0;
- DECLARE_BITMAP(toclear, MAX_NR_BANKS);
- DECLARE_BITMAP(valid_banks, MAX_NR_BANKS);
- char *msg = "Unknown";
/*
* MCEs are always local on AMD. Same is determined by MCG_STATUS_LMCES
* on Intel.
*/
int lmce = 1;
- int cpu = smp_processor_id();
-
- /*
- * Cases where we avoid rendezvous handler timeout:
- * 1) If this CPU is offline.
- *
- * 2) If crashing_cpu was set, e.g. we're entering kdump and we need to
- * skip those CPUs which remain looping in the 1st kernel - see
- * crash_nmi_callback().
- *
- * Note: there still is a small window between kexec-ing and the new,
- * kdump kernel establishing a new #MC handler where a broadcasted MCE
- * might not get handled properly.
- */
- if (cpu_is_offline(cpu) ||
- (crashing_cpu != -1 && crashing_cpu != cpu)) {
- u64 mcgstatus;
- mcgstatus = mce_rdmsrl(MSR_IA32_MCG_STATUS);
- if (mcgstatus & MCG_STATUS_RIPV) {
- mce_wrmsrl(MSR_IA32_MCG_STATUS, 0);
- return;
- }
- }
+ if (__mc_check_crashing_cpu(cpu))
+ return;
ist_enter(regs);
next prev parent reply other threads:[~2018-06-22 12:41 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-22 9:54 [PATCH 0/7] RAS queue Borislav Petkov
2018-06-22 9:54 ` [PATCH 1/7] x86/mce: Always use 64-bit timestamps Borislav Petkov
2018-06-22 9:54 ` [PATCH 2/7] x86/mce: Fix incorrect "Machine check from unknown source" message Borislav Petkov
2018-06-22 9:54 ` [PATCH 3/7] x86/mce: Carve out the crashing_cpu check Borislav Petkov
2018-06-22 12:41 ` tip-bot for Borislav Petkov [this message]
2018-06-22 9:54 ` [PATCH 4/7] x86/mce: Remove !banks check Borislav Petkov
2018-06-22 12:41 ` [tip:ras/core] " tip-bot for Borislav Petkov
2018-06-22 9:54 ` [PATCH 5/7] x86/mce: Carve out bank scanning code Borislav Petkov
2018-06-22 12:42 ` [tip:ras/core] " tip-bot for Borislav Petkov
2018-06-22 9:54 ` [PATCH 6/7] x86/mce: Cleanup __mc_scan_banks() Borislav Petkov
2018-06-22 12:42 ` [tip:ras/core] " tip-bot for Borislav Petkov
2018-06-22 9:54 ` [PATCH 7/7] x86/mce: Do not overwrite MCi_STATUS in mce_no_way_out() Borislav Petkov
2018-06-22 12:39 ` [tip:ras/core] " tip-bot for Borislav Petkov
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=tip-d3d6923cd1ae61a493a405f2f001293ab62eb092@git.kernel.org \
--to=tipbot@zytor.com \
--cc=bp@suse.de \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tip-commits@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=tglx@linutronix.de \
/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).