This patch series includes some improvement to Machine check handler
for pseries. Patch 1 fixes a buffer overrun issue if rtas extended error
log size is greater than RTAS_ERROR_LOG_MAX.
Patch 2 fixes an issue where machine check handler crashes
kernel while accessing vmalloc-ed buffer while in nmi context.
Patch 3 fixes endain bug while restoring of r3 in MCE handler.
Patch 5 implements a real mode mce handler and flushes the SLBs on SLB error.
Patch 6 display's the MCE error details on console.
Patch 7 saves and dumps the SLB contents on SLB MCE errors to improve the
debugability.
Patch 8 adds sysctl knob for recovery action on recovered MCEs.
Patch 9 consolidates mce early real mode handling code.
Change in V7:
- Fold Michal's patch into patch 5
- Handle MSR_RI=0 and evil context case in MC handler in patch 5.
- Patch 7: Print slb cache ptr value and slb cache data.
- Move patch 8 to patch 9.
- Introduce patch 8 add sysctl knob for recovery action on recovered MCEs.
Change in V6:
- Introduce patch 8 to consolidate early real mode handling code.
- Address Nick's comment on erroneous hunk.
Change in V5:
- Use min_t instead of max_t.
- Fix an issue reported by kbuild test robot and address review comments.
Change in V4:
- Flush the SLBs in real mode mce handler to handle SLB errors for entry 0.
- Allocate buffers per cpu to hold rtas error log and old slb contents.
- Defer the logging of rtas error log to irq work queue.
Change in V3:
- Moved patch 5 to patch 2
Change in V2:
- patch 3: Display additional info (NIP and task info) in MCE error details.
- patch 5: Fix endain bug while restoring of r3 in MCE handler.
---
Mahesh Salgaonkar (9):
powerpc/pseries: Avoid using the size greater than RTAS_ERROR_LOG_MAX.
powerpc/pseries: Defer the logging of rtas error to irq work queue.
powerpc/pseries: Fix endainness while restoring of r3 in MCE handler.
powerpc/pseries: Define MCE error event section.
powerpc/pseries: flush SLB contents on SLB MCE errors.
powerpc/pseries: Display machine check error details.
powerpc/pseries: Dump the SLB contents on SLB MCE errors.
powerpc/mce: Add sysctl control for recovery action on MCE.
powernv/pseries: consolidate code for mce early handling.
arch/powerpc/include/asm/book3s/64/mmu-hash.h | 8 +
arch/powerpc/include/asm/machdep.h | 1
arch/powerpc/include/asm/mce.h | 2
arch/powerpc/include/asm/paca.h | 7 +
arch/powerpc/include/asm/rtas.h | 116 ++++++++++++
arch/powerpc/kernel/exceptions-64s.S | 42 ++++
arch/powerpc/kernel/mce.c | 73 +++++++-
arch/powerpc/kernel/traps.c | 3
arch/powerpc/mm/slb.c | 79 ++++++++
arch/powerpc/platforms/powernv/setup.c | 15 ++
arch/powerpc/platforms/pseries/pseries.h | 1
arch/powerpc/platforms/pseries/ras.c | 242 +++++++++++++++++++++++--
arch/powerpc/platforms/pseries/setup.c | 27 +++
13 files changed, 588 insertions(+), 28 deletions(-)
--
Signature
From: Mahesh Salgaonkar <redacted>
The global mce data buffer that used to copy rtas error log is of 2048
(RTAS_ERROR_LOG_MAX) bytes in size. Before the copy we read
extended_log_length from rtas error log header, then use max of
extended_log_length and RTAS_ERROR_LOG_MAX as a size of data to be copied.
Ideally the platform (phyp) will never send extended error log with
size > 2048. But if that happens, then we have a risk of buffer overrun
and corruption. Fix this by using min_t instead.
Fixes: d368514c3097 ("powerpc: Fix corruption when grabbing FWNMI data")
Reported-by: Michal Suchanek <redacted>
Signed-off-by: Mahesh Salgaonkar <redacted>
---
arch/powerpc/platforms/pseries/ras.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Mahesh Salgaonkar <redacted>
On pseries, the machine check error details are part of RTAS extended
event log passed under Machine check exception section. This patch adds
the definition of rtas MCE event section and related helper
functions.
Signed-off-by: Mahesh Salgaonkar <redacted>
---
arch/powerpc/include/asm/rtas.h | 111 +++++++++++++++++++++++++++++++++++++++
1 file changed, 111 insertions(+)
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2018-08-08 14:42:12
Hi Mahesh,
A few nitpicks.
Mahesh J Salgaonkar [off-list ref] writes:
From: Mahesh Salgaonkar <redacted>
On pseries, the machine check error details are part of RTAS extended
event log passed under Machine check exception section. This patch adds
the definition of rtas MCE event section and related helper
functions.
Signed-off-by: Mahesh Salgaonkar <redacted>
---
arch/powerpc/include/asm/rtas.h | 111 +++++++++++++++++++++++++++++++++++++++
1 file changed, 111 insertions(+)
AFIACS none of this ever gets used outside of ras.c, should it should
just go in there.
Hi Mahesh,
A few nitpicks.
Mahesh J Salgaonkar [off-list ref] writes:
quoted
From: Mahesh Salgaonkar <redacted>
On pseries, the machine check error details are part of RTAS extended
event log passed under Machine check exception section. This patch adds
the definition of rtas MCE event section and related helper
functions.
Signed-off-by: Mahesh Salgaonkar <redacted>
---
arch/powerpc/include/asm/rtas.h | 111 +++++++++++++++++++++++++++++++++++++++
1 file changed, 111 insertions(+)
AFIACS none of this ever gets used outside of ras.c, should it should
just go in there.
Since it was all rtas specific I thought rtas.h is better place. But
yes, I can move this into ras.c
+ union {
+ struct {
+ uint8_t ue_err_type;
+ /* XXXXXXXX
+ * X 1: Permanent or Transient UE.
+ * X 1: Effective address provided.
+ * X 1: Logical address provided.
+ * XX 2: Reserved.
+ * XXX 3: Type of UE error.
+ */
But which bit is bit 0? And is that the LSB or MSB?
RTAS errorlog data in BE format, the leftmost bit is MSB 0 (1: Permanent
or Transient UE.). I Will update the comment above that properly points
out which one is MSB 0.
Because when used __packed it added 1 byte extra padding between
reserved_1[6] and effective_address. That caused wrong effective address
to be printed on the console. Hence I switched to #pragma pack to force
1 byte alignment for this structure alone.
+ union {
+ struct {
+ uint8_t ue_err_type;
+ /* XXXXXXXX
+ * X 1: Permanent or Transient UE.
+ * X 1: Effective address provided.
+ * X 1: Logical address provided.
+ * XX 2: Reserved.
+ * XXX 3: Type of UE error.
+ */
But which bit is bit 0? And is that the LSB or MSB?
RTAS errorlog data in BE format, the leftmost bit is MSB 0 (1: Permanent
or Transient UE.). I Will update the comment above that properly points
out which one is MSB 0.
Because when used __packed it added 1 byte extra padding between
reserved_1[6] and effective_address. That caused wrong effective address
to be printed on the console. Hence I switched to #pragma pack to force
1 byte alignment for this structure alone.
OK, that's weird.
Do we really need to bother with all the union stuff? The only
difference is the field names, and whether logical address has a value
or not. What about:
struct pseries_mc_errorlog {
__be32 fru_id;
__be32 proc_id;
u8 error_type;
u8 sub_error_type;
u8 reserved_1[6];
__be64 effective_address;
__be64 logical_address;
} __packed;
cheers
Because when used __packed it added 1 byte extra padding between
reserved_1[6] and effective_address. That caused wrong effective address
to be printed on the console. Hence I switched to #pragma pack to force
1 byte alignment for this structure alone.
OK, that's weird.
Yes, if that is true, then please open a GCC bugzilla report.
Segher
+ union {
+ struct {
+ uint8_t ue_err_type;
+ /* XXXXXXXX
+ * X 1: Permanent or Transient UE.
+ * X 1: Effective address provided.
+ * X 1: Logical address provided.
+ * XX 2: Reserved.
+ * XXX 3: Type of UE error.
+ */
But which bit is bit 0? And is that the LSB or MSB?
RTAS errorlog data in BE format, the leftmost bit is MSB 0 (1: Permanent
or Transient UE.). I Will update the comment above that properly points
out which one is MSB 0.
Because when used __packed it added 1 byte extra padding between
reserved_1[6] and effective_address. That caused wrong effective address
to be printed on the console. Hence I switched to #pragma pack to force
1 byte alignment for this structure alone.
OK, that's weird.
Do we really need to bother with all the union stuff? The only
difference is the field names, and whether logical address has a value
Also the bit fields for UE and other sub errors differ. Yeah but we can
do away with union stuff.
From: Mahesh Salgaonkar <redacted>
On pseries, as of today system crashes if we get a machine check
exceptions due to SLB errors. These are soft errors and can be fixed by
flushing the SLBs so the kernel can continue to function instead of
system crash. We do this in real mode before turning on MMU. Otherwise
we would run into nested machine checks. This patch now fetches the
rtas error log in real mode and flushes the SLBs on SLB errors.
Signed-off-by: Mahesh Salgaonkar <redacted>
Signed-off-by: Michal Suchanek <redacted>
---
Changes in V7:
- Fold Michal's patch into this patch.
- Handle MSR_RI=0 and evil context case in MC handler.
---
arch/powerpc/include/asm/book3s/64/mmu-hash.h | 1
arch/powerpc/include/asm/machdep.h | 1
arch/powerpc/kernel/exceptions-64s.S | 112 +++++++++++++++++++++++++
arch/powerpc/kernel/mce.c | 15 +++
arch/powerpc/mm/slb.c | 6 +
arch/powerpc/platforms/powernv/setup.c | 11 ++
arch/powerpc/platforms/pseries/pseries.h | 1
arch/powerpc/platforms/pseries/ras.c | 51 +++++++++++
arch/powerpc/platforms/pseries/setup.c | 1
9 files changed, 195 insertions(+), 4 deletions(-)
@@ -108,6 +108,7 @@ struct machdep_calls {/* Early exception handlers called in realmode */int(*hmi_exception_early)(structpt_regs*regs);+long(*machine_check_early)(structpt_regs*regs);/* Called during machine check exception to retrive fixup address. */bool(*mce_check_early_recovery)(structpt_regs*regs);
@@ -431,6 +431,16 @@ static unsigned long pnv_get_proc_freq(unsigned int cpu)returnret_freq;}+staticlongpnv_machine_check_early(structpt_regs*regs)+{+longhandled=0;++if(cur_cpu_spec&&cur_cpu_spec->machine_check_early)+handled=cur_cpu_spec->machine_check_early(regs);++returnhandled;+}+define_machine(powernv){.name="PowerNV",.probe=pnv_probe,
@@ -427,6 +427,35 @@ int pSeries_system_reset_exception(struct pt_regs *regs)return0;/* need to perform reset */}+staticintmce_handle_error(structrtas_error_log*errp)+{+structpseries_errorlog*pseries_log;+structpseries_mc_errorlog*mce_log;+intdisposition=rtas_error_disposition(errp);+uint8_terror_type;++if(!rtas_error_extended(errp))+gotoout;++pseries_log=get_pseries_errorlog(errp,PSERIES_ELOG_SECT_ID_MCE);+if(pseries_log==NULL)+gotoout;++mce_log=(structpseries_mc_errorlog*)pseries_log->data;+error_type=rtas_mc_error_type(mce_log);++if((disposition==RTAS_DISP_NOT_RECOVERED)&&+(error_type==PSERIES_MC_ERROR_TYPE_SLB)){+/* Store the old slb content someplace. */+slb_flush_and_rebolt_realmode();+disposition=RTAS_DISP_FULLY_RECOVERED;+rtas_set_disposition_recovered(errp);+}++out:+returndisposition;+}+/**ProcessMCErtaserrlogevent.*/
@@ -503,11 +532,31 @@ int pSeries_machine_check_exception(struct pt_regs *regs)structrtas_error_log*errp;if(fwnmi_active){-errp=fwnmi_get_errinfo(regs);fwnmi_release_errinfo();+errp=fwnmi_get_errlog();if(errp&&recover_mce(regs,errp))return1;}return0;}++longpSeries_machine_check_realmode(structpt_regs*regs)+{+structrtas_error_log*errp;+intdisposition;++if(fwnmi_active){+errp=fwnmi_get_errinfo(regs);+/*+*Calltofwnmi_release_errinfo()inrealmodecauseskernel+*topanic.Hencewewillcallitassoonaswegointo+*virtualmode.+*/+disposition=mce_handle_error(errp);+if(disposition==RTAS_DISP_FULLY_RECOVERED)+return1;+}++return0;+}
From: Michal Suchánek <hidden> Date: 2018-08-07 16:54:48
Hello,
On Tue, 07 Aug 2018 19:47:14 +0530
"Mahesh J Salgaonkar" [off-list ref] wrote:
quoted hunk
From: Mahesh Salgaonkar <redacted>
On pseries, as of today system crashes if we get a machine check
exceptions due to SLB errors. These are soft errors and can be fixed
by flushing the SLBs so the kernel can continue to function instead of
system crash. We do this in real mode before turning on MMU. Otherwise
we would run into nested machine checks. This patch now fetches the
rtas error log in real mode and flushes the SLBs on SLB errors.
Signed-off-by: Mahesh Salgaonkar <redacted>
Signed-off-by: Michal Suchanek <redacted>
---
Changes in V7:
- Fold Michal's patch into this patch.
- Handle MSR_RI=0 and evil context case in MC handler.
---
arch/powerpc/include/asm/book3s/64/mmu-hash.h | 1
arch/powerpc/include/asm/machdep.h | 1
arch/powerpc/kernel/exceptions-64s.S | 112
+++++++++++++++++++++++++
arch/powerpc/kernel/mce.c | 15 +++
arch/powerpc/mm/slb.c | 6 +
arch/powerpc/platforms/powernv/setup.c | 11 ++
arch/powerpc/platforms/pseries/pseries.h | 1
arch/powerpc/platforms/pseries/ras.c | 51 +++++++++++
arch/powerpc/platforms/pseries/setup.c | 1 9 files changed,
195 insertions(+), 4 deletions(-)
b/arch/powerpc/include/asm/machdep.h index a47de82fb8e2..b4831f1338db
100644 --- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -108,6 +108,7 @@ struct machdep_calls {/* Early exception handlers called in realmode */int(*hmi_exception_early)(structpt_regs
*regs);
+ long (*machine_check_early)(struct pt_regs
*regs);
/* Called during machine check exception to retrive fixup
address. */ bool (*mce_check_early_recovery)(struct
pt_regs *regs); diff --git a/arch/powerpc/kernel/exceptions-64s.S
b/arch/powerpc/kernel/exceptions-64s.S index
285c6465324a..cb06f219570a 100644 ---
a/arch/powerpc/kernel/exceptions-64s.S +++
b/arch/powerpc/kernel/exceptions-64s.S @@ -332,6 +332,9 @@
TRAMP_REAL_BEGIN(machine_check_pSeries) machine_check_fwnmi:
SET_SCRATCH0(r13) /* save r13 */
EXCEPTION_PROLOG_0(PACA_EXMC)
+BEGIN_FTR_SECTION
+ b machine_check_pSeries_early
+END_FTR_SECTION_IFCLR(CPU_FTR_HVMODE)
machine_check_pSeries_0:
EXCEPTION_PROLOG_1(PACA_EXMC, KVMTEST_PR, 0x200)
/*
@@ -343,6 +346,90 @@ machine_check_pSeries_0: TRAMP_KVM_SKIP(PACA_EXMC, 0x200)+TRAMP_REAL_BEGIN(machine_check_pSeries_early)+BEGIN_FTR_SECTION+ EXCEPTION_PROLOG_1(PACA_EXMC, NOTEST, 0x200)+ mr r10,r1 /* Save r1 */+ ld r1,PACAMCEMERGSP(r13) /* Use MC emergency
stack */
+ subi r1,r1,INT_FRAME_SIZE /* alloc stack
frame */
+ mfspr r11,SPRN_SRR0 /* Save SRR0 */
+ mfspr r12,SPRN_SRR1 /* Save SRR1 */
+ EXCEPTION_PROLOG_COMMON_1()
+ EXCEPTION_PROLOG_COMMON_2(PACA_EXMC)
+ EXCEPTION_PROLOG_COMMON_3(0x200)
+ addi r3,r1,STACK_FRAME_OVERHEAD
+ BRANCH_LINK_TO_FAR(machine_check_early) /* Function call ABI
*/
+ ld r12,_MSR(r1)
+ andi. r11,r12,MSR_PR /* See if coming
from user. */
+ bne 2f /* continue in V mode
if we are. */ +
+ /*
+ * At this point we are not sure about what context we come
from.
+ * We may be in the middle of swithing stack. r1 may not be
valid.
+ * Hence stay on emergency stack, call
machine_check_exception and
+ * return from the interrupt.
+ * But before that, check if this is an un-recoverable
exception.
+ * If yes, then stay on emergency stack and panic.
+ */
+ andi. r11,r12,MSR_RI
+ bne 1f
+
+ /*
+ * Check if we have successfully handled/recovered from
error, if not
+ * then stay on emergency stack and panic.
+ */
+ cmpdi r3,0 /* see if we handled MCE
successfully */
+ bne 1f /* if handled then return from
interrupt */ +
+ LOAD_HANDLER(r10,unrecover_mce)
+ mtspr SPRN_SRR0,r10
+ ld r10,PACAKMSR(r13)
+ /*
+ * We are going down. But there are chances that we might
get hit by
+ * another MCE during panic path and we may run into
unstable state
+ * with no way out. Hence, turn ME bit off while going down,
so that
+ * when another MCE is hit during panic path, hypervisor will
+ * power cycle the lpar, instead of getting into MCE loop.
+ */
+ li r3,MSR_ME
+ andc r10,r10,r3 /* Turn off MSR_ME */
+ mtspr SPRN_SRR1,r10
+ RFI_TO_KERNEL
+ b .
+
+ /* Stay on emergency stack and return from interrupt. */
+1: LOAD_HANDLER(r10,mce_return)
+ mtspr SPRN_SRR0,r10
+ ld r10,PACAKMSR(r13)
+ mtspr SPRN_SRR1,r10
+ RFI_TO_KERNEL
+ b .
I think that the logic should be inverted here. That is we should check
for unrecoverable and unhandled exceptions and jump to unrecov_mce if
found, fallthrough to mce_return otherwise.
Thanks
Michal
quoted hunk
+
+ /* Move original SRR0 and SRR1 into the respective regs */
+2: ld r9,_MSR(r1)
+ mtspr SPRN_SRR1,r9
+ ld r3,_NIP(r1)
+ mtspr SPRN_SRR0,r3
+ ld r9,_CTR(r1)
+ mtctr r9
+ ld r9,_XER(r1)
+ mtxer r9
+ ld r9,_LINK(r1)
+ mtlr r9
+ REST_GPR(0, r1)
+ REST_8GPRS(2, r1)
+ REST_GPR(10, r1)
+ ld r11,_CCR(r1)
+ mtcr r11
+ REST_GPR(11, r1)
+ REST_2GPRS(12, r1)
+ /* restore original r1. */
+ ld r1,GPR1(r1)
+ SET_SCRATCH0(r13) /* save r13 */
+ EXCEPTION_PROLOG_0(PACA_EXMC)
+ b machine_check_pSeries_0
+END_FTR_SECTION_IFCLR(CPU_FTR_HVMODE)
+
EXC_COMMON_BEGIN(machine_check_common)
/*
* Machine check is different because we use a different
@@ -536,6 +623,31 @@ EXC_COMMON_BEGIN(unrecover_mce) bl unrecoverable_exception b 1b+EXC_COMMON_BEGIN(mce_return)+ /* Invoke machine_check_exception to print MCE event and
@@ -488,10 +488,19 @@ long machine_check_early(struct pt_regs *regs){longhandled=0;-__this_cpu_inc(irq_stat.mce_exceptions);+/*+*ForpSerieswecountmcewhenwegointovirtualmode
machine
+ * check handler. Hence skip it. Also, We can't access per
cpu
+ * variables in real mode for LPAR.
+ */
+ if (early_cpu_has_feature(CPU_FTR_HVMODE))
+ __this_cpu_inc(irq_stat.mce_exceptions);
- if (cur_cpu_spec && cur_cpu_spec->machine_check_early)
- handled = cur_cpu_spec->machine_check_early(regs);
+ /*
+ * See if platform is capable of handling machine check.
+ */
+ if (ppc_md.machine_check_early)
+ handled = ppc_md.machine_check_early(regs);
return handled;
}
Hello,
On Tue, 07 Aug 2018 19:47:14 +0530
"Mahesh J Salgaonkar" [off-list ref] wrote:
quoted
From: Mahesh Salgaonkar <redacted>
On pseries, as of today system crashes if we get a machine check
exceptions due to SLB errors. These are soft errors and can be fixed
by flushing the SLBs so the kernel can continue to function instead of
system crash. We do this in real mode before turning on MMU. Otherwise
we would run into nested machine checks. This patch now fetches the
rtas error log in real mode and flushes the SLBs on SLB errors.
Signed-off-by: Mahesh Salgaonkar <redacted>
Signed-off-by: Michal Suchanek <redacted>
---
Changes in V7:
- Fold Michal's patch into this patch.
- Handle MSR_RI=0 and evil context case in MC handler.
---
arch/powerpc/include/asm/book3s/64/mmu-hash.h | 1
arch/powerpc/include/asm/machdep.h | 1
arch/powerpc/kernel/exceptions-64s.S | 112
+++++++++++++++++++++++++
arch/powerpc/kernel/mce.c | 15 +++
arch/powerpc/mm/slb.c | 6 +
arch/powerpc/platforms/powernv/setup.c | 11 ++
arch/powerpc/platforms/pseries/pseries.h | 1
arch/powerpc/platforms/pseries/ras.c | 51 +++++++++++
arch/powerpc/platforms/pseries/setup.c | 1 9 files changed,
195 insertions(+), 4 deletions(-)
b/arch/powerpc/include/asm/machdep.h index a47de82fb8e2..b4831f1338db
100644 --- a/arch/powerpc/include/asm/machdep.h
+++ b/arch/powerpc/include/asm/machdep.h
@@ -108,6 +108,7 @@ struct machdep_calls {/* Early exception handlers called in realmode */int(*hmi_exception_early)(structpt_regs
*regs);
+ long (*machine_check_early)(struct pt_regs
*regs);
/* Called during machine check exception to retrive fixup
address. */ bool (*mce_check_early_recovery)(struct
pt_regs *regs); diff --git a/arch/powerpc/kernel/exceptions-64s.S
b/arch/powerpc/kernel/exceptions-64s.S index
285c6465324a..cb06f219570a 100644 ---
a/arch/powerpc/kernel/exceptions-64s.S +++
b/arch/powerpc/kernel/exceptions-64s.S @@ -332,6 +332,9 @@
TRAMP_REAL_BEGIN(machine_check_pSeries) machine_check_fwnmi:
SET_SCRATCH0(r13) /* save r13 */
EXCEPTION_PROLOG_0(PACA_EXMC)
+BEGIN_FTR_SECTION
+ b machine_check_pSeries_early
+END_FTR_SECTION_IFCLR(CPU_FTR_HVMODE)
machine_check_pSeries_0:
EXCEPTION_PROLOG_1(PACA_EXMC, KVMTEST_PR, 0x200)
/*
@@ -343,6 +346,90 @@ machine_check_pSeries_0: TRAMP_KVM_SKIP(PACA_EXMC, 0x200)+TRAMP_REAL_BEGIN(machine_check_pSeries_early)+BEGIN_FTR_SECTION+ EXCEPTION_PROLOG_1(PACA_EXMC, NOTEST, 0x200)+ mr r10,r1 /* Save r1 */+ ld r1,PACAMCEMERGSP(r13) /* Use MC emergency
stack */
+ subi r1,r1,INT_FRAME_SIZE /* alloc stack
frame */
+ mfspr r11,SPRN_SRR0 /* Save SRR0 */
+ mfspr r12,SPRN_SRR1 /* Save SRR1 */
+ EXCEPTION_PROLOG_COMMON_1()
+ EXCEPTION_PROLOG_COMMON_2(PACA_EXMC)
+ EXCEPTION_PROLOG_COMMON_3(0x200)
+ addi r3,r1,STACK_FRAME_OVERHEAD
+ BRANCH_LINK_TO_FAR(machine_check_early) /* Function call ABI
*/
+ ld r12,_MSR(r1)
+ andi. r11,r12,MSR_PR /* See if coming
from user. */
+ bne 2f /* continue in V mode
if we are. */ +
+ /*
+ * At this point we are not sure about what context we come
from.
+ * We may be in the middle of swithing stack. r1 may not be
valid.
+ * Hence stay on emergency stack, call
machine_check_exception and
+ * return from the interrupt.
+ * But before that, check if this is an un-recoverable
exception.
+ * If yes, then stay on emergency stack and panic.
+ */
+ andi. r11,r12,MSR_RI
+ bne 1f
+
+ /*
+ * Check if we have successfully handled/recovered from
error, if not
+ * then stay on emergency stack and panic.
+ */
+ cmpdi r3,0 /* see if we handled MCE
successfully */
+ bne 1f /* if handled then return from
interrupt */ +
+ LOAD_HANDLER(r10,unrecover_mce)
+ mtspr SPRN_SRR0,r10
+ ld r10,PACAKMSR(r13)
+ /*
+ * We are going down. But there are chances that we might
get hit by
+ * another MCE during panic path and we may run into
unstable state
+ * with no way out. Hence, turn ME bit off while going down,
so that
+ * when another MCE is hit during panic path, hypervisor will
+ * power cycle the lpar, instead of getting into MCE loop.
+ */
+ li r3,MSR_ME
+ andc r10,r10,r3 /* Turn off MSR_ME */
+ mtspr SPRN_SRR1,r10
+ RFI_TO_KERNEL
+ b .
+
+ /* Stay on emergency stack and return from interrupt. */
+1: LOAD_HANDLER(r10,mce_return)
+ mtspr SPRN_SRR0,r10
+ ld r10,PACAKMSR(r13)
+ mtspr SPRN_SRR1,r10
+ RFI_TO_KERNEL
+ b .
I think that the logic should be inverted here. That is we should check
for unrecoverable and unhandled exceptions and jump to unrecov_mce if
found, fallthrough to mce_return otherwise.
sure. will make that change in next revision.
Thanks,
-Mahesh.
Thanks
Michal
quoted
+
+ /* Move original SRR0 and SRR1 into the respective regs */
+2: ld r9,_MSR(r1)
+ mtspr SPRN_SRR1,r9
+ ld r3,_NIP(r1)
+ mtspr SPRN_SRR0,r3
+ ld r9,_CTR(r1)
+ mtctr r9
+ ld r9,_XER(r1)
+ mtxer r9
+ ld r9,_LINK(r1)
+ mtlr r9
+ REST_GPR(0, r1)
+ REST_8GPRS(2, r1)
+ REST_GPR(10, r1)
+ ld r11,_CCR(r1)
+ mtcr r11
+ REST_GPR(11, r1)
+ REST_2GPRS(12, r1)
+ /* restore original r1. */
+ ld r1,GPR1(r1)
+ SET_SCRATCH0(r13) /* save r13 */
+ EXCEPTION_PROLOG_0(PACA_EXMC)
+ b machine_check_pSeries_0
+END_FTR_SECTION_IFCLR(CPU_FTR_HVMODE)
+
EXC_COMMON_BEGIN(machine_check_common)
/*
* Machine check is different because we use a different
@@ -536,6 +623,31 @@ EXC_COMMON_BEGIN(unrecover_mce) bl unrecoverable_exception b 1b+EXC_COMMON_BEGIN(mce_return)+ /* Invoke machine_check_exception to print MCE event and
@@ -488,10 +488,19 @@ long machine_check_early(struct pt_regs *regs){longhandled=0;-__this_cpu_inc(irq_stat.mce_exceptions);+/*+*ForpSerieswecountmcewhenwegointovirtualmode
machine
+ * check handler. Hence skip it. Also, We can't access per
cpu
+ * variables in real mode for LPAR.
+ */
+ if (early_cpu_has_feature(CPU_FTR_HVMODE))
+ __this_cpu_inc(irq_stat.mce_exceptions);
- if (cur_cpu_spec && cur_cpu_spec->machine_check_early)
- handled = cur_cpu_spec->machine_check_early(regs);
+ /*
+ * See if platform is capable of handling machine check.
+ */
+ if (ppc_md.machine_check_early)
+ handled = ppc_md.machine_check_early(regs);
return handled;
}
From: Nicholas Piggin <npiggin@gmail.com> Date: 2018-08-08 09:05:10
On Tue, 07 Aug 2018 19:47:14 +0530
Mahesh J Salgaonkar [off-list ref] wrote:
From: Mahesh Salgaonkar <redacted>
On pseries, as of today system crashes if we get a machine check
exceptions due to SLB errors. These are soft errors and can be fixed by
flushing the SLBs so the kernel can continue to function instead of
system crash. We do this in real mode before turning on MMU. Otherwise
we would run into nested machine checks. This patch now fetches the
rtas error log in real mode and flushes the SLBs on SLB errors.
Signed-off-by: Mahesh Salgaonkar <redacted>
Signed-off-by: Michal Suchanek <redacted>
---
Changes in V7:
- Fold Michal's patch into this patch.
- Handle MSR_RI=0 and evil context case in MC handler.
---
On Tue, 07 Aug 2018 19:47:14 +0530
Mahesh J Salgaonkar [off-list ref] wrote:
quoted
From: Mahesh Salgaonkar <redacted>
On pseries, as of today system crashes if we get a machine check
exceptions due to SLB errors. These are soft errors and can be fixed by
flushing the SLBs so the kernel can continue to function instead of
system crash. We do this in real mode before turning on MMU. Otherwise
we would run into nested machine checks. This patch now fetches the
rtas error log in real mode and flushes the SLBs on SLB errors.
Signed-off-by: Mahesh Salgaonkar <redacted>
Signed-off-by: Michal Suchanek <redacted>
---
Changes in V7:
- Fold Michal's patch into this patch.
- Handle MSR_RI=0 and evil context case in MC handler.
---
@@ -254,6 +254,10 @@ struct paca_struct {#endif#ifdef CONFIG_PPC_PSERIESu8*mce_data_buf;/* buffer to hold per cpu rtas errlog */++/* Capture SLB related old contents in MCE handler. */+structslb_entry*mce_faulty_slbs;+u16slb_save_cache_ptr;#endif /* CONFIG_PPC_PSERIES */}____cacheline_aligned;
@@ -575,7 +579,11 @@ static int mce_handle_error(struct rtas_error_log *errp)if((disposition==RTAS_DISP_NOT_RECOVERED)&&(error_type==PSERIES_MC_ERROR_TYPE_SLB)){-/* Store the old slb content someplace. */+/*+*Storetheoldslbcontentinpacabeforeflushing.Print+*thiswhenwegotovirtualmode.+*/+slb_save_contents(local_paca->mce_faulty_slbs);slb_flush_and_rebolt_realmode();disposition=RTAS_DISP_FULLY_RECOVERED;rtas_set_disposition_recovered(errp);
@@ -130,6 +133,13 @@ static void __init fwnmi_init(void)paca_ptrs[i]->mce_data_buf=mce_data_buf+(RTAS_ERROR_LOG_MAX*i);}++/* Allocate per cpu slb area to save old slb contents during MCE */+size=sizeof(structslb_entry)*mmu_slb_size*nr_cpus;+slb_ptr=__va(memblock_alloc_base(size,sizeof(structslb_entry),+ppc64_rma_size));+for_each_possible_cpu(i)+paca_ptrs[i]->mce_faulty_slbs=slb_ptr+(mmu_slb_size*i);}staticvoidpseries_8259_cascade(structirq_desc*desc)
@@ -254,6 +254,10 @@ struct paca_struct {#endif#ifdef CONFIG_PPC_PSERIESu8*mce_data_buf;/* buffer to hold per cpu rtas errlog */++/* Capture SLB related old contents in MCE handler. */+structslb_entry*mce_faulty_slbs;+u16slb_save_cache_ptr;#endif /* CONFIG_PPC_PSERIES */
@@ -151,6 +151,79 @@ void slb_flush_and_rebolt_realmode(void)get_paca()->slb_cache_ptr=0;}+voidslb_save_contents(structslb_entry*slb_ptr)+{+inti;+unsignedlonge,v;++/* Save slb_cache_ptr value. */+get_paca()->slb_save_cache_ptr=get_paca()->slb_cache_ptr;
This isn't inside CONFIG_PPC_PSERIES which breaks lots of configs, eg
powernv.
arch/powerpc/mm/slb.c:160:12: error: 'struct paca_struct' has no member named 'slb_save_cache_ptr'
arch/powerpc/mm/slb.c:218:27: error: 'struct paca_struct' has no member named 'slb_save_cache_ptr'
arch/powerpc/mm/slb.c:216:49: error: 'struct paca_struct' has no member named 'slb_save_cache_ptr'
http://kisskb.ozlabs.ibm.com/kisskb/head/219f20e490add009194d94fdeb480da2e385f1c6/
cheers
@@ -254,6 +254,10 @@ struct paca_struct {#endif#ifdef CONFIG_PPC_PSERIESu8*mce_data_buf;/* buffer to hold per cpu rtas errlog */++/* Capture SLB related old contents in MCE handler. */+structslb_entry*mce_faulty_slbs;+u16slb_save_cache_ptr;#endif /* CONFIG_PPC_PSERIES */
@@ -151,6 +151,79 @@ void slb_flush_and_rebolt_realmode(void)get_paca()->slb_cache_ptr=0;}+voidslb_save_contents(structslb_entry*slb_ptr)+{+inti;+unsignedlonge,v;++/* Save slb_cache_ptr value. */+get_paca()->slb_save_cache_ptr=get_paca()->slb_cache_ptr;
This isn't inside CONFIG_PPC_PSERIES which breaks lots of configs, eg
powernv.
arch/powerpc/mm/slb.c:160:12: error: 'struct paca_struct' has no member named 'slb_save_cache_ptr'
arch/powerpc/mm/slb.c:218:27: error: 'struct paca_struct' has no member named 'slb_save_cache_ptr'
arch/powerpc/mm/slb.c:216:49: error: 'struct paca_struct' has no member named 'slb_save_cache_ptr'
http://kisskb.ozlabs.ibm.com/kisskb/head/219f20e490add009194d94fdeb480da2e385f1c6/
cheers
@@ -254,6 +254,10 @@ struct paca_struct {#endif#ifdef CONFIG_PPC_PSERIESu8*mce_data_buf;/* buffer to hold per cpu rtas errlog */++/* Capture SLB related old contents in MCE handler. */+structslb_entry*mce_faulty_slbs;+u16slb_save_cache_ptr;#endif /* CONFIG_PPC_PSERIES */
^^^^^^^^^^^^^^^^^
I will pull that out of CONFIG_PPC_PSERIES.
I mean will pull 'mce_faulty_slbs' and 'slb_save_cache_ptr' and put it
under CONFIG_PPC_BOOK3S_64.
-Mahesh.
@@ -151,6 +151,79 @@ void slb_flush_and_rebolt_realmode(void)get_paca()->slb_cache_ptr=0;}+voidslb_save_contents(structslb_entry*slb_ptr)+{+inti;+unsignedlonge,v;++/* Save slb_cache_ptr value. */+get_paca()->slb_save_cache_ptr=get_paca()->slb_cache_ptr;
This isn't inside CONFIG_PPC_PSERIES which breaks lots of configs, eg
powernv.
arch/powerpc/mm/slb.c:160:12: error: 'struct paca_struct' has no member named 'slb_save_cache_ptr'
arch/powerpc/mm/slb.c:218:27: error: 'struct paca_struct' has no member named 'slb_save_cache_ptr'
arch/powerpc/mm/slb.c:216:49: error: 'struct paca_struct' has no member named 'slb_save_cache_ptr'
http://kisskb.ozlabs.ibm.com/kisskb/head/219f20e490add009194d94fdeb480da2e385f1c6/
cheers
@@ -254,6 +254,10 @@ struct paca_struct {#endif#ifdef CONFIG_PPC_PSERIESu8*mce_data_buf;/* buffer to hold per cpu rtas errlog */++/* Capture SLB related old contents in MCE handler. */+structslb_entry*mce_faulty_slbs;+u16slb_save_cache_ptr;#endif /* CONFIG_PPC_PSERIES */}____cacheline_aligned;
Does the UM say these instructions can cause machine checks if the SLB
is corrupted? It talks about mfslb instruction causing MCE, but there
seems to be no such instruction so I wonder if that's a typo for slbmf?
Seems like a parity error in the SLB should cause a MCE, at least,
because it can't guarantee valid data for the instruction in that case
(multi-hit may be different because you aren't searching by EA).
You could limit slb saving to a single level of recursion to avoid
the problem.
Thanks,
Nick
@@ -254,6 +254,10 @@ struct paca_struct {#endif#ifdef CONFIG_PPC_PSERIESu8*mce_data_buf;/* buffer to hold per cpu rtas errlog */++/* Capture SLB related old contents in MCE handler. */+structslb_entry*mce_faulty_slbs;+u16slb_save_cache_ptr;#endif /* CONFIG_PPC_PSERIES */}____cacheline_aligned;
Does the UM say these instructions can cause machine checks if the SLB
is corrupted? It talks about mfslb instruction causing MCE, but there
seems to be no such instruction so I wonder if that's a typo for slbmf?
Seems like a parity error in the SLB should cause a MCE, at least,
because it can't guarantee valid data for the instruction in that case
(multi-hit may be different because you aren't searching by EA).
You could limit slb saving to a single level of recursion to avoid
the problem.
Yeah, we could do this OR restrict slb saving only for SLB multi-hit.
Parity errors are anyway hardware errors. If parity error is transient
then saving of SLBs may not trigger another MCE. In that case old SLB
content would look ok even if we dump them on console. What do you say ?
@@ -254,6 +254,10 @@ struct paca_struct {#endif#ifdef CONFIG_PPC_PSERIESu8*mce_data_buf;/* buffer to hold per cpu rtas errlog */++/* Capture SLB related old contents in MCE handler. */+structslb_entry*mce_faulty_slbs;+u16slb_save_cache_ptr;#endif /* CONFIG_PPC_PSERIES */}____cacheline_aligned;
@@ -151,6 +151,79 @@ void slb_flush_and_rebolt_realmode(void)get_paca()->slb_cache_ptr=0;}+voidslb_save_contents(structslb_entry*slb_ptr)+{+inti;+unsignedlonge,v;++/* Save slb_cache_ptr value. */+get_paca()->slb_save_cache_ptr=get_paca()->slb_cache_ptr;
What's the point of saving this?
This is to know how many valid cache entries were present at the time of
SLB mutlihit. We use this index value while dumping the slb cahce entries.
Oh I see you're dumping that thing as well. I don't know if that's
worth doing, it just gives you the first 8 SLB entries installed but
you already have those (or they're overwritten and irrelevat).
quoted
quoted
+
+ if (!slb_ptr)
+ return;
Can this ever happen?
May be Never. We allocate the memory at very early stage. But just added
as sanity check.
Does the UM say these instructions can cause machine checks if the SLB
is corrupted? It talks about mfslb instruction causing MCE, but there
seems to be no such instruction so I wonder if that's a typo for slbmf?
Seems like a parity error in the SLB should cause a MCE, at least,
because it can't guarantee valid data for the instruction in that case
(multi-hit may be different because you aren't searching by EA).
You could limit slb saving to a single level of recursion to avoid
the problem.
Yeah, we could do this OR restrict slb saving only for SLB multi-hit.
Parity errors are anyway hardware errors. If parity error is transient
then saving of SLBs may not trigger another MCE. In that case old SLB
content would look ok even if we dump them on console. What do you say ?
I'm not sure. A parity error I think can cause a multi hit. Can you be
sure of a software caused multi hit? Would be a good idea if you can I
think. It may be a good idea to avoid recursion as well, just in case.
Thanks,
Nick
@@ -254,6 +254,10 @@ struct paca_struct {#endif#ifdef CONFIG_PPC_PSERIESu8*mce_data_buf;/* buffer to hold per cpu rtas errlog */++/* Capture SLB related old contents in MCE handler. */+structslb_entry*mce_faulty_slbs;+u16slb_save_cache_ptr;#endif /* CONFIG_PPC_PSERIES */}____cacheline_aligned;
@@ -151,6 +151,79 @@ void slb_flush_and_rebolt_realmode(void)get_paca()->slb_cache_ptr=0;}+voidslb_save_contents(structslb_entry*slb_ptr)+{+inti;+unsignedlonge,v;++/* Save slb_cache_ptr value. */+get_paca()->slb_save_cache_ptr=get_paca()->slb_cache_ptr;
What's the point of saving this?
This is to know how many valid cache entries were present at the time of
SLB mutlihit. We use this index value while dumping the slb cahce entries.
Oh I see you're dumping that thing as well. I don't know if that's
worth doing, it just gives you the first 8 SLB entries installed but
you already have those (or they're overwritten and irrelevat).
Aneesh, Can you comment on this ?
quoted
quoted
quoted
+
+ if (!slb_ptr)
+ return;
Can this ever happen?
May be Never. We allocate the memory at very early stage. But just added
as sanity check.
Does the UM say these instructions can cause machine checks if the SLB
is corrupted? It talks about mfslb instruction causing MCE, but there
seems to be no such instruction so I wonder if that's a typo for slbmf?
Seems like a parity error in the SLB should cause a MCE, at least,
because it can't guarantee valid data for the instruction in that case
(multi-hit may be different because you aren't searching by EA).
You could limit slb saving to a single level of recursion to avoid
the problem.
Yeah, we could do this OR restrict slb saving only for SLB multi-hit.
Parity errors are anyway hardware errors. If parity error is transient
then saving of SLBs may not trigger another MCE. In that case old SLB
content would look ok even if we dump them on console. What do you say ?
I'm not sure. A parity error I think can cause a multi hit. Can you be
sure of a software caused multi hit? Would be a good idea if you can I
think. It may be a good idea to avoid recursion as well, just in case.
yeah, you are right. Parity errors can also cause multi-hit. Will limit
slb saving to single level of recursion.
Thanks for your review.
-Mahesh.
@@ -254,6 +254,10 @@ struct paca_struct {#endif#ifdef CONFIG_PPC_PSERIESu8*mce_data_buf;/* buffer to hold per cpu rtas errlog */++/* Capture SLB related old contents in MCE handler. */+structslb_entry*mce_faulty_slbs;+u16slb_save_cache_ptr;#endif /* CONFIG_PPC_PSERIES */}____cacheline_aligned;
@@ -151,6 +151,79 @@ void slb_flush_and_rebolt_realmode(void)get_paca()->slb_cache_ptr=0;}+voidslb_save_contents(structslb_entry*slb_ptr)+{+inti;+unsignedlonge,v;++/* Save slb_cache_ptr value. */+get_paca()->slb_save_cache_ptr=get_paca()->slb_cache_ptr;
What's the point of saving this?
This is to know how many valid cache entries were present at the time of
SLB mutlihit. We use this index value while dumping the slb cahce entries.
Oh I see you're dumping that thing as well. I don't know if that's
worth doing, it just gives you the first 8 SLB entries installed but
you already have those (or they're overwritten and irrelevat).
Aneesh, Can you comment on this ?
We never clear slb_cache entries. We just update slb_cache_ptr. Now on
debug we would like to find which entries are the valid
slb_cache_entries for this run. slb_cache_ptr gives us that details.
One of the ways we could end up with a slb multi hit is if we have
slb_cache_ptr corruption. So instead of doing a flush_and_rebolt, we
invalidated a subset of valid slb entries. But I understand that in that
specific case, we context switched out with that corrupted value and the
value we are dumping above really won't help in isolating. But if we are
corrupting paca, we might continue to overwrite it again and we can
compare the slb contents against slb_cache contents and see if there is
any corruption.
-aneesh
From: Mahesh Salgaonkar <redacted>
Introduce recovery action for recovered memory errors (MCEs). There are
soft memory errors like SLB Multihit, which can be a result of a bad
hardware OR software BUG. Kernel can easily recover from these soft errors
by flushing SLB contents. After the recovery kernel can still continue to
function without any issue. But in some scenario's we may keep getting
these soft errors until the root cause is fixed. To be able to analyze and
find the root cause, best way is to gather enough data and system state at
the time of MCE. Hence this patch introduces a sysctl knob where user can
decide either to continue after recovery or panic the kernel to capture the
dump. This will allow one to configure a kernel to capture a dump on MCE
and then toggle back to recovery while dump is being analyzed.
Signed-off-by: Mahesh Salgaonkar <redacted>
---
arch/powerpc/include/asm/mce.h | 2 +
arch/powerpc/kernel/mce.c | 58 ++++++++++++++++++++++++++++++++
arch/powerpc/kernel/traps.c | 3 +-
arch/powerpc/platforms/powernv/setup.c | 4 ++
4 files changed, 66 insertions(+), 1 deletion(-)
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2018-08-08 14:56:01
Mahesh J Salgaonkar [off-list ref] writes:
From: Mahesh Salgaonkar <redacted>
Introduce recovery action for recovered memory errors (MCEs). There are
soft memory errors like SLB Multihit, which can be a result of a bad
hardware OR software BUG. Kernel can easily recover from these soft errors
by flushing SLB contents. After the recovery kernel can still continue to
function without any issue. But in some scenario's we may keep getting
these soft errors until the root cause is fixed. To be able to analyze and
find the root cause, best way is to gather enough data and system state at
the time of MCE. Hence this patch introduces a sysctl knob where user can
decide either to continue after recovery or panic the kernel to capture the
dump.
I'm not convinced we want this.
As we've discovered it's often not possible to reconstruct what happened
based on a dump anyway.
The key thing you need is the content of the SLB and that's not included
in a dump.
So I think we should dump the SLB content when we get the MCE (which
this series does) and any other useful info, and then if we can recover
we should.
cheers
From: Mahesh Salgaonkar <redacted>
Introduce recovery action for recovered memory errors (MCEs). There are
soft memory errors like SLB Multihit, which can be a result of a bad
hardware OR software BUG. Kernel can easily recover from these soft errors
by flushing SLB contents. After the recovery kernel can still continue to
function without any issue. But in some scenario's we may keep getting
these soft errors until the root cause is fixed. To be able to analyze and
find the root cause, best way is to gather enough data and system state at
the time of MCE. Hence this patch introduces a sysctl knob where user can
decide either to continue after recovery or panic the kernel to capture the
dump.
I'm not convinced we want this.
As we've discovered it's often not possible to reconstruct what happened
based on a dump anyway.
The key thing you need is the content of the SLB and that's not included
in a dump.
So I think we should dump the SLB content when we get the MCE (which
this series does) and any other useful info, and then if we can recover
we should.
The reasoning there is what if we got multi-hit due to some corruption
in slb_cache_ptr. ie. some part of kernel is wrongly updating the paca
data structure due to wrong pointer. Now that is far fetched, but then
possible right?. Hence the idea that, if we don't have much insight into
why a slb multi-hit occur from the dmesg which include slb content,
slb_cache contents etc, there should be an easy way to force a dump that
might assist in further debug.
-aneesh
From: Michal Suchánek <hidden> Date: 2018-08-08 16:09:49
On Wed, 8 Aug 2018 21:07:11 +0530
"Aneesh Kumar K.V" [off-list ref] wrote:
On 08/08/2018 08:26 PM, Michael Ellerman wrote:
quoted
Mahesh J Salgaonkar [off-list ref] writes:
quoted
From: Mahesh Salgaonkar <redacted>
Introduce recovery action for recovered memory errors (MCEs).
There are soft memory errors like SLB Multihit, which can be a
result of a bad hardware OR software BUG. Kernel can easily
recover from these soft errors by flushing SLB contents. After the
recovery kernel can still continue to function without any issue.
But in some scenario's we may keep getting these soft errors until
the root cause is fixed. To be able to analyze and find the root
cause, best way is to gather enough data and system state at the
time of MCE. Hence this patch introduces a sysctl knob where user
can decide either to continue after recovery or panic the kernel
to capture the dump.
I'm not convinced we want this.
As we've discovered it's often not possible to reconstruct what
happened based on a dump anyway.
The key thing you need is the content of the SLB and that's not
included in a dump.
So I think we should dump the SLB content when we get the MCE (which
this series does) and any other useful info, and then if we can
recover we should.
The reasoning there is what if we got multi-hit due to some
corruption in slb_cache_ptr. ie. some part of kernel is wrongly
updating the paca data structure due to wrong pointer. Now that is
far fetched, but then possible right?. Hence the idea that, if we
don't have much insight into why a slb multi-hit occur from the dmesg
which include slb content, slb_cache contents etc, there should be an
easy way to force a dump that might assist in further debug.
Nonetheless this turns all MCEs into crashes. Are there any MCEs that
could happen during normal operation and should be handled by default?
Thanks
Michal
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2018-08-10 11:04:30
Michal Such=C3=A1nek [off-list ref] writes:
On Wed, 8 Aug 2018 21:07:11 +0530
"Aneesh Kumar K.V" [off-list ref] wrote:
quoted
On 08/08/2018 08:26 PM, Michael Ellerman wrote:
quoted
Mahesh J Salgaonkar [off-list ref] writes:=20=20
quoted
From: Mahesh Salgaonkar <redacted>
Introduce recovery action for recovered memory errors (MCEs).
There are soft memory errors like SLB Multihit, which can be a
result of a bad hardware OR software BUG. Kernel can easily
recover from these soft errors by flushing SLB contents. After the
recovery kernel can still continue to function without any issue.
But in some scenario's we may keep getting these soft errors until
the root cause is fixed. To be able to analyze and find the root
cause, best way is to gather enough data and system state at the
time of MCE. Hence this patch introduces a sysctl knob where user
can decide either to continue after recovery or panic the kernel
to capture the dump.=20=20
=20
I'm not convinced we want this.
=20
As we've discovered it's often not possible to reconstruct what
happened based on a dump anyway.
=20
The key thing you need is the content of the SLB and that's not
included in a dump.
=20
So I think we should dump the SLB content when we get the MCE (which
this series does) and any other useful info, and then if we can
recover we should.
=20
The reasoning there is what if we got multi-hit due to some
corruption in slb_cache_ptr. ie. some part of kernel is wrongly
updating the paca data structure due to wrong pointer. Now that is
far fetched, but then possible right?. Hence the idea that, if we
don't have much insight into why a slb multi-hit occur from the dmesg
which include slb content, slb_cache contents etc, there should be an
easy way to force a dump that might assist in further debug.
Nonetheless this turns all MCEs into crashes. Are there any MCEs that
could happen during normal operation and should be handled by default?
An MCE should always be an indication of an abnormal condition, but
the exact set of things that are reported as MCEs is CPU specific, and
potentially even configurable at the hardware level.
However we only "handle" certain types of MCEs, so if we get an MCE for
something we don't understand then we'll panic already.
SLB multi-hit / parity error is one that we do handle (on bare metal),
because there is a well defined recovery action.
cheers
From: Michael Ellerman <mpe@ellerman.id.au> Date: 2018-08-09 06:34:08
"Aneesh Kumar K.V" [off-list ref] writes:
On 08/08/2018 08:26 PM, Michael Ellerman wrote:
quoted
Mahesh J Salgaonkar [off-list ref] writes:
quoted
From: Mahesh Salgaonkar <redacted>
Introduce recovery action for recovered memory errors (MCEs). There are
soft memory errors like SLB Multihit, which can be a result of a bad
hardware OR software BUG. Kernel can easily recover from these soft errors
by flushing SLB contents. After the recovery kernel can still continue to
function without any issue. But in some scenario's we may keep getting
these soft errors until the root cause is fixed. To be able to analyze and
find the root cause, best way is to gather enough data and system state at
the time of MCE. Hence this patch introduces a sysctl knob where user can
decide either to continue after recovery or panic the kernel to capture the
dump.
I'm not convinced we want this.
As we've discovered it's often not possible to reconstruct what happened
based on a dump anyway.
The key thing you need is the content of the SLB and that's not included
in a dump.
So I think we should dump the SLB content when we get the MCE (which
this series does) and any other useful info, and then if we can recover
we should.
The reasoning there is what if we got multi-hit due to some corruption
in slb_cache_ptr. ie. some part of kernel is wrongly updating the paca
data structure due to wrong pointer. Now that is far fetched, but then
possible right?. Hence the idea that, if we don't have much insight into
why a slb multi-hit occur from the dmesg which include slb content,
slb_cache contents etc, there should be an easy way to force a dump that
might assist in further debug.
If you're debugging something complex that you can't determine from the
SLB dump then you should be running a debug kernel anyway. And if
anything you want to drop into xmon and sit there, preserving the most
state, rather than taking a dump.
The last SLB multi-hit I debugged was this:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=db7130d63fd8
Which took quite a while to track down, including a bunch of tracing and
so on. A dump would not have helped in the slightest.
cheers
From: Nicholas Piggin <npiggin@gmail.com> Date: 2018-08-09 08:03:03
On Thu, 09 Aug 2018 16:34:07 +1000
Michael Ellerman [off-list ref] wrote:
"Aneesh Kumar K.V" [off-list ref] writes:
quoted
On 08/08/2018 08:26 PM, Michael Ellerman wrote:
quoted
Mahesh J Salgaonkar [off-list ref] writes:
quoted
From: Mahesh Salgaonkar <redacted>
Introduce recovery action for recovered memory errors (MCEs). There are
soft memory errors like SLB Multihit, which can be a result of a bad
hardware OR software BUG. Kernel can easily recover from these soft errors
by flushing SLB contents. After the recovery kernel can still continue to
function without any issue. But in some scenario's we may keep getting
these soft errors until the root cause is fixed. To be able to analyze and
find the root cause, best way is to gather enough data and system state at
the time of MCE. Hence this patch introduces a sysctl knob where user can
decide either to continue after recovery or panic the kernel to capture the
dump.
I'm not convinced we want this.
As we've discovered it's often not possible to reconstruct what happened
based on a dump anyway.
The key thing you need is the content of the SLB and that's not included
in a dump.
So I think we should dump the SLB content when we get the MCE (which
this series does) and any other useful info, and then if we can recover
we should.
The reasoning there is what if we got multi-hit due to some corruption
in slb_cache_ptr. ie. some part of kernel is wrongly updating the paca
data structure due to wrong pointer. Now that is far fetched, but then
possible right?. Hence the idea that, if we don't have much insight into
why a slb multi-hit occur from the dmesg which include slb content,
slb_cache contents etc, there should be an easy way to force a dump that
might assist in further debug.
If you're debugging something complex that you can't determine from the
SLB dump then you should be running a debug kernel anyway. And if
anything you want to drop into xmon and sit there, preserving the most
state, rather than taking a dump.
I'm not saying for a dump specifically, just some form of crash. And we
really should have an option to xmon on panic, but that's another story.
I think HA/failover kind of environments use options like this too. If
anything starts going bad they don't want to try limping along but stop
ASAP.
Thanks,
Nick
From: Ananth N Mavinakayanahalli <hidden> Date: 2018-08-09 08:10:07
On Thu, Aug 09, 2018 at 06:02:53PM +1000, Nicholas Piggin wrote:
On Thu, 09 Aug 2018 16:34:07 +1000
Michael Ellerman [off-list ref] wrote:
quoted
"Aneesh Kumar K.V" [off-list ref] writes:
quoted
On 08/08/2018 08:26 PM, Michael Ellerman wrote:
quoted
Mahesh J Salgaonkar [off-list ref] writes:
quoted
From: Mahesh Salgaonkar <redacted>
Introduce recovery action for recovered memory errors (MCEs). There are
soft memory errors like SLB Multihit, which can be a result of a bad
hardware OR software BUG. Kernel can easily recover from these soft errors
by flushing SLB contents. After the recovery kernel can still continue to
function without any issue. But in some scenario's we may keep getting
these soft errors until the root cause is fixed. To be able to analyze and
find the root cause, best way is to gather enough data and system state at
the time of MCE. Hence this patch introduces a sysctl knob where user can
decide either to continue after recovery or panic the kernel to capture the
dump.
I'm not convinced we want this.
As we've discovered it's often not possible to reconstruct what happened
based on a dump anyway.
The key thing you need is the content of the SLB and that's not included
in a dump.
So I think we should dump the SLB content when we get the MCE (which
this series does) and any other useful info, and then if we can recover
we should.
The reasoning there is what if we got multi-hit due to some corruption
in slb_cache_ptr. ie. some part of kernel is wrongly updating the paca
data structure due to wrong pointer. Now that is far fetched, but then
possible right?. Hence the idea that, if we don't have much insight into
why a slb multi-hit occur from the dmesg which include slb content,
slb_cache contents etc, there should be an easy way to force a dump that
might assist in further debug.
If you're debugging something complex that you can't determine from the
SLB dump then you should be running a debug kernel anyway. And if
anything you want to drop into xmon and sit there, preserving the most
state, rather than taking a dump.
I'm not saying for a dump specifically, just some form of crash. And we
really should have an option to xmon on panic, but that's another story.
That's fine during development or in a lab, not something we could
enforce in a customer environment, could we?
I think HA/failover kind of environments use options like this too. If
anything starts going bad they don't want to try limping along but stop
ASAP.
Right. And in this particular case, can we guarantee no corruption
(leading to or post the multihit recovery) when running a customer workload,
is the question...
Ananth
From: Nicholas Piggin <npiggin@gmail.com> Date: 2018-08-09 08:33:44
On Thu, 9 Aug 2018 13:39:45 +0530
Ananth N Mavinakayanahalli [off-list ref] wrote:
On Thu, Aug 09, 2018 at 06:02:53PM +1000, Nicholas Piggin wrote:
quoted
On Thu, 09 Aug 2018 16:34:07 +1000
Michael Ellerman [off-list ref] wrote:
quoted
"Aneesh Kumar K.V" [off-list ref] writes:
quoted
On 08/08/2018 08:26 PM, Michael Ellerman wrote:
quoted
Mahesh J Salgaonkar [off-list ref] writes:
quoted
From: Mahesh Salgaonkar <redacted>
Introduce recovery action for recovered memory errors (MCEs). There are
soft memory errors like SLB Multihit, which can be a result of a bad
hardware OR software BUG. Kernel can easily recover from these soft errors
by flushing SLB contents. After the recovery kernel can still continue to
function without any issue. But in some scenario's we may keep getting
these soft errors until the root cause is fixed. To be able to analyze and
find the root cause, best way is to gather enough data and system state at
the time of MCE. Hence this patch introduces a sysctl knob where user can
decide either to continue after recovery or panic the kernel to capture the
dump.
I'm not convinced we want this.
As we've discovered it's often not possible to reconstruct what happened
based on a dump anyway.
The key thing you need is the content of the SLB and that's not included
in a dump.
So I think we should dump the SLB content when we get the MCE (which
this series does) and any other useful info, and then if we can recover
we should.
The reasoning there is what if we got multi-hit due to some corruption
in slb_cache_ptr. ie. some part of kernel is wrongly updating the paca
data structure due to wrong pointer. Now that is far fetched, but then
possible right?. Hence the idea that, if we don't have much insight into
why a slb multi-hit occur from the dmesg which include slb content,
slb_cache contents etc, there should be an easy way to force a dump that
might assist in further debug.
If you're debugging something complex that you can't determine from the
SLB dump then you should be running a debug kernel anyway. And if
anything you want to drop into xmon and sit there, preserving the most
state, rather than taking a dump.
I'm not saying for a dump specifically, just some form of crash. And we
really should have an option to xmon on panic, but that's another story.
That's fine during development or in a lab, not something we could
enforce in a customer environment, could we?
xmon on panic? Not something to enforce but IMO (without thinking about
it too much but having encountered it several times) it should probably
be tied xmon on BUG option.
quoted
I think HA/failover kind of environments use options like this too. If
anything starts going bad they don't want to try limping along but stop
ASAP.
Right. And in this particular case, can we guarantee no corruption
(leading to or post the multihit recovery) when running a customer workload,
is the question...
I think that's an element of it. If SLB corruption is caused by
software then we could already have memory corruption. If it's hardware
then presumably we're supposed to have some guarantee of error rates.
But still you would say a machine that has taken no MCEs is less likely
to have a problem than one that has taken some MCEs!
It's not just corruption either, I've run into bugs where we get huge
streams of HMIs for example which all get recovered properly but
performance would have been in the toilet.
Anyway, being policy maybe we could drop this patch out of the SLB MCE
series and introduce it afterwards if we think it's necessary. For
SLB multi hit caused by software bug in slb handling, I'd say Michael's
pretty right about just needing the MCE output with SLB contents.
Thanks,
Nick
From: Michal Suchánek <hidden> Date: 2018-08-09 10:26:53
On Thu, 9 Aug 2018 18:33:33 +1000
Nicholas Piggin [off-list ref] wrote:
On Thu, 9 Aug 2018 13:39:45 +0530
Ananth N Mavinakayanahalli [off-list ref] wrote:
quoted
On Thu, Aug 09, 2018 at 06:02:53PM +1000, Nicholas Piggin wrote:
quoted
On Thu, 09 Aug 2018 16:34:07 +1000
Michael Ellerman [off-list ref] wrote:
quoted
"Aneesh Kumar K.V" [off-list ref] writes:
quoted
On 08/08/2018 08:26 PM, Michael Ellerman wrote:
quoted
Mahesh J Salgaonkar [off-list ref] writes:
quoted
From: Mahesh Salgaonkar <redacted>
Introduce recovery action for recovered memory errors
(MCEs). There are soft memory errors like SLB Multihit,
which can be a result of a bad hardware OR software BUG.
Kernel can easily recover from these soft errors by
flushing SLB contents. After the recovery kernel can still
continue to function without any issue. But in some
scenario's we may keep getting these soft errors until the
root cause is fixed. To be able to analyze and find the
root cause, best way is to gather enough data and system
state at the time of MCE. Hence this patch introduces a
sysctl knob where user can decide either to continue after
recovery or panic the kernel to capture the dump.
I'm not convinced we want this.
As we've discovered it's often not possible to reconstruct
what happened based on a dump anyway.
The key thing you need is the content of the SLB and that's
not included in a dump.
So I think we should dump the SLB content when we get the
MCE (which this series does) and any other useful info, and
then if we can recover we should.
The reasoning there is what if we got multi-hit due to some
corruption in slb_cache_ptr. ie. some part of kernel is
wrongly updating the paca data structure due to wrong
pointer. Now that is far fetched, but then possible right?.
Hence the idea that, if we don't have much insight into why a
slb multi-hit occur from the dmesg which include slb content,
slb_cache contents etc, there should be an easy way to force
a dump that might assist in further debug.
If you're debugging something complex that you can't determine
from the SLB dump then you should be running a debug kernel
anyway. And if anything you want to drop into xmon and sit
there, preserving the most state, rather than taking a dump.
I'm not saying for a dump specifically, just some form of crash.
And we really should have an option to xmon on panic, but that's
another story.
That's fine during development or in a lab, not something we could
enforce in a customer environment, could we?
xmon on panic? Not something to enforce but IMO (without thinking
about it too much but having encountered it several times) it should
probably be tied xmon on BUG option.
You should get that with this patch and xmon=on or am I missing
something?
Thanks
Michal
From: Nicholas Piggin <npiggin@gmail.com> Date: 2018-08-10 07:31:48
On Thu, 9 Aug 2018 12:26:46 +0200
Michal Such=C3=A1nek [off-list ref] wrote:
On Thu, 9 Aug 2018 18:33:33 +1000
Nicholas Piggin [off-list ref] wrote:
=20
quoted
On Thu, 9 Aug 2018 13:39:45 +0530
Ananth N Mavinakayanahalli [off-list ref] wrote:
=20
quoted
On Thu, Aug 09, 2018 at 06:02:53PM +1000, Nicholas Piggin wrote: =20
quoted
On Thu, 09 Aug 2018 16:34:07 +1000
Michael Ellerman [off-list ref] wrote:
=20
quoted
"Aneesh Kumar K.V" [off-list ref] writes: =20
quoted
On 08/08/2018 08:26 PM, Michael Ellerman wrote: =20
quoted
Mahesh J Salgaonkar [off-list ref] writes: =
=20
quoted
quoted
quoted
quoted
quoted
quoted
quoted
From: Mahesh Salgaonkar <redacted>
Introduce recovery action for recovered memory errors
(MCEs). There are soft memory errors like SLB Multihit,
which can be a result of a bad hardware OR software BUG.
Kernel can easily recover from these soft errors by
flushing SLB contents. After the recovery kernel can still
continue to function without any issue. But in some
scenario's we may keep getting these soft errors until the
root cause is fixed. To be able to analyze and find the
root cause, best way is to gather enough data and system
state at the time of MCE. Hence this patch introduces a
sysctl knob where user can decide either to continue after
recovery or panic the kernel to capture the dump. =20
=20
I'm not convinced we want this.
=20
As we've discovered it's often not possible to reconstruct
what happened based on a dump anyway.
=20
The key thing you need is the content of the SLB and that's
not included in a dump.
=20
So I think we should dump the SLB content when we get the
MCE (which this series does) and any other useful info, and
then if we can recover we should. =20
The reasoning there is what if we got multi-hit due to some
corruption in slb_cache_ptr. ie. some part of kernel is
wrongly updating the paca data structure due to wrong
pointer. Now that is far fetched, but then possible right?.
Hence the idea that, if we don't have much insight into why a
slb multi-hit occur from the dmesg which include slb content,
slb_cache contents etc, there should be an easy way to force
a dump that might assist in further debug. =20
=20
If you're debugging something complex that you can't determine
from the SLB dump then you should be running a debug kernel
anyway. And if anything you want to drop into xmon and sit
there, preserving the most state, rather than taking a dump. =
=20
quoted
quoted
quoted
=20
I'm not saying for a dump specifically, just some form of crash.
And we really should have an option to xmon on panic, but that's
another story. =20
=20
That's fine during development or in a lab, not something we could
enforce in a customer environment, could we? =20
=20
xmon on panic? Not something to enforce but IMO (without thinking
about it too much but having encountered it several times) it should
probably be tied xmon on BUG option. =20
=20
You should get that with this patch and xmon=3Don or am I missing
something?
Oh yeah, I just got a bit side tracked and added something not very
relevant -- a panic() call should drop to xmon if we have xmon=3Don. It
doesn't today (or last I looked), but that's nothing to do with this
patch.
Thanks,
Nick
From: Nicholas Piggin <npiggin@gmail.com> Date: 2018-08-09 01:43:44
On Thu, 09 Aug 2018 00:56:00 +1000
Michael Ellerman [off-list ref] wrote:
Mahesh J Salgaonkar [off-list ref] writes:
quoted
From: Mahesh Salgaonkar <redacted>
Introduce recovery action for recovered memory errors (MCEs). There are
soft memory errors like SLB Multihit, which can be a result of a bad
hardware OR software BUG. Kernel can easily recover from these soft errors
by flushing SLB contents. After the recovery kernel can still continue to
function without any issue. But in some scenario's we may keep getting
these soft errors until the root cause is fixed. To be able to analyze and
find the root cause, best way is to gather enough data and system state at
the time of MCE. Hence this patch introduces a sysctl knob where user can
decide either to continue after recovery or panic the kernel to capture the
dump.
I'm not convinced we want this.
As we've discovered it's often not possible to reconstruct what happened
based on a dump anyway.
The key thing you need is the content of the SLB and that's not included
in a dump.
So I think we should dump the SLB content when we get the MCE (which
this series does) and any other useful info, and then if we can recover
we should.
Yeah it's a lot of knobs that administrators can hardly be expected to
tune. Hypervisor or firmware should really eventually make the MCE
unrecoverable if we aren't making progress.
That said, x86 has a bunch of options, and for debugging a rare crash
or specialised installations it might be useful. But we should follow
the normal format, /proc/sys/kernel/panic_on_mce.
Thanks,
Nick
From: Mahesh Salgaonkar <redacted>
Now that other platforms also implements real mode mce handler,
lets consolidate the code by sharing existing powernv machine check
early code. Rename machine_check_powernv_early to
machine_check_common_early and reuse the code.
Signed-off-by: Mahesh Salgaonkar <redacted>
---
arch/powerpc/kernel/exceptions-64s.S | 138 +++++++---------------------------
1 file changed, 28 insertions(+), 110 deletions(-)
From: Mahesh Salgaonkar <redacted>
rtas_log_buf is a buffer to hold RTAS event data that are communicated
to kernel by hypervisor. This buffer is then used to pass RTAS event
data to user through proc fs. This buffer is allocated from vmalloc
(non-linear mapping) area.
On Machine check interrupt, register r3 points to RTAS extended event
log passed by hypervisor that contains the MCE event. The pseries
machine check handler then logs this error into rtas_log_buf. The
rtas_log_buf is a vmalloc-ed (non-linear) buffer we end up taking up a
page fault (vector 0x300) while accessing it. Since machine check
interrupt handler runs in NMI context we can not afford to take any
page fault. Page faults are not honored in NMI context and causes
kernel panic. Apart from that, as Nick pointed out, pSeries_log_error()
also takes a spin_lock while logging error which is not safe in NMI
context. It may endup in deadlock if we get another MCE before releasing
the lock. Fix this by deferring the logging of rtas error to irq work queue.
Current implementation uses two different buffers to hold rtas error log
depending on whether extended log is provided or not. This makes bit
difficult to identify which buffer has valid data that needs to logged
later in irq work. Simplify this using single buffer, one per paca, and
copy rtas log to it irrespective of whether extended log is provided or
not. Allocate this buffer below RMA region so that it can be accessed
in real mode mce handler.
Fixes: b96672dd840f ("powerpc: Machine check interrupt is a non-maskable interrupt")
Cc: stable@vger.kernel.org
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Mahesh Salgaonkar <redacted>
---
arch/powerpc/include/asm/paca.h | 3 ++
arch/powerpc/platforms/pseries/ras.c | 47 ++++++++++++++++++++++----------
arch/powerpc/platforms/pseries/setup.c | 16 +++++++++++
3 files changed, 51 insertions(+), 15 deletions(-)
@@ -252,6 +252,9 @@ struct paca_struct {void*rfi_flush_fallback_area;u64l1d_flush_size;#endif+#ifdef CONFIG_PPC_PSERIES+u8*mce_data_buf;/* buffer to hold per cpu rtas errlog */+#endif /* CONFIG_PPC_PSERIES */}____cacheline_aligned;externvoidcopy_mm_to_paca(structmm_struct*mm);
@@ -349,7 +356,7 @@ static irqreturn_t ras_error_interrupt(int irq, void *dev_id)staticstructrtas_error_log*fwnmi_get_errinfo(structpt_regs*regs){unsignedlong*savep;-structrtas_error_log*h,*errhdr=NULL;+structrtas_error_log*h;/* Mask top two bits */regs->gpr[3]&=~(0x3UL<<62);
@@ -362,22 +369,20 @@ static struct rtas_error_log *fwnmi_get_errinfo(struct pt_regs *regs)savep=__va(regs->gpr[3]);regs->gpr[3]=savep[0];/* restore original r3 */-/* If it isn't an extended log we can use the per cpu 64bit buffer */h=(structrtas_error_log*)&savep[1];+/* Use the per cpu buffer from paca to store rtas error log */+memset(local_paca->mce_data_buf,0,RTAS_ERROR_LOG_MAX);if(!rtas_error_extended(h)){-memcpy(this_cpu_ptr(&mce_data_buf),h,sizeof(__u64));-errhdr=(structrtas_error_log*)this_cpu_ptr(&mce_data_buf);+memcpy(local_paca->mce_data_buf,h,sizeof(__u64));}else{intlen,error_log_length;error_log_length=8+rtas_error_extended_log_length(h);len=min_t(int,error_log_length,RTAS_ERROR_LOG_MAX);-memset(global_mce_data_buf,0,RTAS_ERROR_LOG_MAX);-memcpy(global_mce_data_buf,h,len);-errhdr=(structrtas_error_log*)global_mce_data_buf;+memcpy(local_paca->mce_data_buf,h,len);}-returnerrhdr;+return(structrtas_error_log*)local_paca->mce_data_buf;}/* Call this when done with the data returned by FWNMI_get_errinfo.
@@ -422,6 +427,17 @@ int pSeries_system_reset_exception(struct pt_regs *regs)return0;/* need to perform reset */}+/*+*ProcessMCErtaserrlogevent.+*/+staticvoidmce_process_errlog_event(structirq_work*work)+{+structrtas_error_log*err;++err=fwnmi_get_errlog();+log_error((char*)err,ERR_TYPE_RTAS_LOG,0);+}+/**Seeifwecanrecoverfromamachinecheckexception.*Thisisonlycalledonpower4(orabove)andonlyvia
@@ -466,7 +482,8 @@ static int recover_mce(struct pt_regs *regs, struct rtas_error_log *err)recovered=1;}-log_error((char*)err,ERR_TYPE_RTAS_LOG,0);+/* Queue irq work to log this rtas event later. */+irq_work_queue(&mce_errlog_process_work);returnrecovered;}
From: Mahesh Salgaonkar <redacted>
During Machine Check interrupt on pseries platform, register r3 points
RTAS extended event log passed by hypervisor. Since hypervisor uses r3
to pass pointer to rtas log, it stores the original r3 value at the
start of the memory (first 8 bytes) pointed by r3. Since hypervisor
stores this info and rtas log is in BE format, linux should make
sure to restore r3 value in correct endian format.
Without this patch when MCE handler, after recovery, returns to code that
that caused the MCE may end up with Data SLB access interrupt for invalid
address followed by kernel panic or hang.
[ 62.878965] Severe Machine check interrupt [Recovered]
[ 62.878968] NIP [d00000000ca301b8]: init_module+0x1b8/0x338 [bork_kernel]
[ 62.878969] Initiator: CPU
[ 62.878970] Error type: SLB [Multihit]
[ 62.878971] Effective address: d00000000ca70000
cpu 0xa: Vector: 380 (Data SLB Access) at [c0000000fc7775b0]
pc: c0000000009694c0: vsnprintf+0x80/0x480
lr: c0000000009698e0: vscnprintf+0x20/0x60
sp: c0000000fc777830
msr: 8000000002009033
dar: a803a30c000000d0
current = 0xc00000000bc9ef00
paca = 0xc00000001eca5c00 softe: 3 irq_happened: 0x01
pid = 8860, comm = insmod
[c0000000fc7778b0] c0000000009698e0 vscnprintf+0x20/0x60
[c0000000fc7778e0] c00000000016b6c4 vprintk_emit+0xb4/0x4b0
[c0000000fc777960] c00000000016d40c vprintk_func+0x5c/0xd0
[c0000000fc777980] c00000000016cbb4 printk+0x38/0x4c
[c0000000fc7779a0] d00000000ca301c0 init_module+0x1c0/0x338 [bork_kernel]
[c0000000fc777a40] c00000000000d9c4 do_one_initcall+0x54/0x230
[c0000000fc777b00] c0000000001b3b74 do_init_module+0x8c/0x248
[c0000000fc777b90] c0000000001b2478 load_module+0x12b8/0x15b0
[c0000000fc777d30] c0000000001b29e8 sys_finit_module+0xa8/0x110
[c0000000fc777e30] c00000000000b204 system_call+0x58/0x6c
--- Exception: c00 (System Call) at 00007fff8bda0644
SP (7fffdfbfe980) is in userspace
This patch fixes this issue.
Fixes: a08a53ea4c97 ("powerpc/le: Enable RTAS events support")
Cc: stable@vger.kernel.org
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Mahesh Salgaonkar <redacted>
---
arch/powerpc/platforms/pseries/ras.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
@@ -367,7 +367,7 @@ static struct rtas_error_log *fwnmi_get_errinfo(struct pt_regs *regs)}savep=__va(regs->gpr[3]);-regs->gpr[3]=savep[0];/* restore original r3 */+regs->gpr[3]=be64_to_cpu(savep[0]);/* restore original r3 */h=(structrtas_error_log*)&savep[1];/* Use the per cpu buffer from paca to store rtas error log */
From: Michael Ellerman <hidden> Date: 2018-08-13 14:05:04
On Tue, 2018-08-07 at 14:16:46 UTC, Mahesh J Salgaonkar wrote:
quoted hunk
From: Mahesh Salgaonkar <redacted>
During Machine Check interrupt on pseries platform, register r3 points
RTAS extended event log passed by hypervisor. Since hypervisor uses r3
to pass pointer to rtas log, it stores the original r3 value at the
start of the memory (first 8 bytes) pointed by r3. Since hypervisor
stores this info and rtas log is in BE format, linux should make
sure to restore r3 value in correct endian format.
Without this patch when MCE handler, after recovery, returns to code that
that caused the MCE may end up with Data SLB access interrupt for invalid
address followed by kernel panic or hang.
[ 62.878965] Severe Machine check interrupt [Recovered]
[ 62.878968] NIP [d00000000ca301b8]: init_module+0x1b8/0x338 [bork_kernel]
[ 62.878969] Initiator: CPU
[ 62.878970] Error type: SLB [Multihit]
[ 62.878971] Effective address: d00000000ca70000
cpu 0xa: Vector: 380 (Data SLB Access) at [c0000000fc7775b0]
pc: c0000000009694c0: vsnprintf+0x80/0x480
lr: c0000000009698e0: vscnprintf+0x20/0x60
sp: c0000000fc777830
msr: 8000000002009033
dar: a803a30c000000d0
current = 0xc00000000bc9ef00
paca = 0xc00000001eca5c00 softe: 3 irq_happened: 0x01
pid = 8860, comm = insmod
[c0000000fc7778b0] c0000000009698e0 vscnprintf+0x20/0x60
[c0000000fc7778e0] c00000000016b6c4 vprintk_emit+0xb4/0x4b0
[c0000000fc777960] c00000000016d40c vprintk_func+0x5c/0xd0
[c0000000fc777980] c00000000016cbb4 printk+0x38/0x4c
[c0000000fc7779a0] d00000000ca301c0 init_module+0x1c0/0x338 [bork_kernel]
[c0000000fc777a40] c00000000000d9c4 do_one_initcall+0x54/0x230
[c0000000fc777b00] c0000000001b3b74 do_init_module+0x8c/0x248
[c0000000fc777b90] c0000000001b2478 load_module+0x12b8/0x15b0
[c0000000fc777d30] c0000000001b29e8 sys_finit_module+0xa8/0x110
[c0000000fc777e30] c00000000000b204 system_call+0x58/0x6c
--- Exception: c00 (System Call) at 00007fff8bda0644
SP (7fffdfbfe980) is in userspace
This patch fixes this issue.
Fixes: a08a53ea4c97 ("powerpc/le: Enable RTAS events support")
Cc: stable@vger.kernel.org
Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Signed-off-by: Mahesh Salgaonkar <redacted>