On Mon, Apr 23, 2018 at 4:51 PM, Balbir Singh wrote: > On Mon, Apr 23, 2018 at 2:59 PM, Mahesh J Salgaonkar > wrote: >> From: Mahesh Salgaonkar >> >> 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.