On Mon, Apr 23, 2018 at 4:51 PM, Balbir Singh <bsinghar...@gmail.com> wrote:
> On Mon, Apr 23, 2018 at 2:59 PM, Mahesh J Salgaonkar
> <mah...@linux.vnet.ibm.com> wrote:
>> From: Mahesh Salgaonkar <mah...@linux.vnet.ibm.com>
>>
>> The current code extracts the physical address for UE errors and then
>> hooks it up into memory failure infrastructure. On successful extraction
>> of physical address it wrongly sets "handled = 1" which means this UE error
>> has been recovered. Since MCE handler gets return value as handled = 1, it
>> assumes that error has been recovered and goes back to same NIP. This causes
>> MCE interrupt again and again in a loop leading to hard lockup.
>>
>> Also, initialize phys_addr to ULONG_MAX so that we don't end up queuing
>> undesired page to hwpoison.
>>
>> Without this patch we see:
>> [ 1476.541984] Severe Machine check interrupt [Recovered]
>> [ 1476.541985] NIP: [000000001002588c] PID: 7109 Comm: find
>> [ 1476.541986] Initiator: CPU
>> [ 1476.541987] Error type: UE [Load/Store]
>> [ 1476.541988] Effective address: 00007fffd2755940
>> [ 1476.541989] Physical address: 000020181a080000
>> [...]
>> [ 1476.542003] Severe Machine check interrupt [Recovered]
>> [ 1476.542004] NIP: [000000001002588c] PID: 7109 Comm: find
>> [ 1476.542005] Initiator: CPU
>> [ 1476.542006] Error type: UE [Load/Store]
>> [ 1476.542006] Effective address: 00007fffd2755940
>> [ 1476.542007] Physical address: 000020181a080000
>> [ 1476.542010] Severe Machine check interrupt [Recovered]
>> [ 1476.542012] NIP: [000000001002588c] PID: 7109 Comm: find
>> [ 1476.542013] Initiator: CPU
>> [ 1476.542014] Error type: UE [Load/Store]
>> [ 1476.542015] Effective address: 00007fffd2755940
>> [ 1476.542016] Physical address: 000020181a080000
>> [ 1476.542448] Memory failure: 0x20181a08: recovery action for dirty LRU
>> page: Recovered
>> [ 1476.542452] Memory failure: 0x20181a08: already hardware poisoned
>> [ 1476.542453] Memory failure: 0x20181a08: already hardware poisoned
>> [ 1476.542454] Memory failure: 0x20181a08: already hardware poisoned
>> [ 1476.542455] Memory failure: 0x20181a08: already hardware poisoned
>> [ 1476.542456] Memory failure: 0x20181a08: already hardware poisoned
>> [ 1476.542457] Memory failure: 0x20181a08: already hardware poisoned
>> [...]
>> [ 1490.972174] Watchdog CPU:38 Hard LOCKUP
>>
>> After this patch we see:
>>
>> [ 325.384336] Severe Machine check interrupt [Not recovered]
>
> How did you test for this? If the error was recovered, shouldn't the
> process have gotten
> a SIGBUS and we should have prevented further access as a part of the handling
> (memory_failure()). Do we just need a MF_MUST_KILL in the flags?
>
> Why shouldn't we treat it as handled if we isolate the page?
Not yet signed-off-by patch attached for testing, Mahesh, please check/confirm
Thanks,
Balbir
>
> Thanks,
> Balbir Singh.
From b297f2ad8473eea7755bcc239e7de21227438065 Mon Sep 17 00:00:00 2001
From: Balbir Singh <bsinghar...@gmail.com>
Date: Mon, 23 Apr 2018 19:21:27 +1000
Subject: [PATCH] powerpc/mce: force a KILL on user page MCE
Experimental fix for MCE error, force a kill
because that's our current recovery mechanism
Not tested/compiled yet
Signed-off-by: Balbir Singh <bsinghar...@gmail.com>
---
arch/powerpc/kernel/mce.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/mce.c b/arch/powerpc/kernel/mce.c
index efdd16a79075..a8441f75861e 100644
--- a/arch/powerpc/kernel/mce.c
+++ b/arch/powerpc/kernel/mce.c
@@ -273,7 +273,7 @@ static void machine_process_ue_event(struct work_struct *work)
pfn = evt->u.ue_error.physical_address >>
PAGE_SHIFT;
- memory_failure(pfn, 0);
+ memory_failure(pfn, MF_MUST_KILL);
} else
pr_warn("Failed to identify bad address from "
"where the uncorrectable error (UE) "
--
2.17.0
