Re: [PATCH 2/3] mm/memory-failure.c: support reset PTE during unpoison
From: David Hildenbrand <hidden>
Date: 2022-05-30 06:50:45
Also in:
linux-mm, lkml, qemu-devel
On 20.05.22 09:06, zhenwei pi wrote:
Origianlly, unpoison_memory() is only used by hwpoison-inject, and unpoisons a page which is poisoned by hwpoison-inject too. The kernel PTE entry has no change during software poison/unpoison. On a virtualization platform, it's possible to fix hardware corrupted page by hypervisor, typically the hypervisor remaps the error HVA(host virtual address). So add a new parameter 'const char *reason' to show the reason called by. Once the corrupted page gets fixed, the guest kernel needs put page to buddy. Reuse the page and hit the following issue(Intel Platinum 8260): BUG: unable to handle page fault for address: ffff888061646000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 2c01067 P4D 2c01067 PUD 61aaa063 PMD 10089b063 PTE 800fffff9e9b9062 Oops: 0002 [#1] PREEMPT SMP NOPTI CPU: 2 PID: 31106 Comm: stress Kdump: loaded Tainted: G M OE 5.18.0-rc6.bm.1-amd64 #6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:clear_page_erms+0x7/0x10 The kernel PTE entry of the fixed page is still uncorrected, kernel hits page fault during prep_new_page. So add 'bool reset_kpte' to get a change to fix the PTE entry if the page is fixed by hypervisor.
Why don't we want to do that for the hwpoison case?
quoted hunk ↗ jump to hunk
Signed-off-by: zhenwei pi <redacted> --- include/linux/mm.h | 2 +- mm/hwpoison-inject.c | 2 +- mm/memory-failure.c | 26 +++++++++++++++++++------- 3 files changed, 21 insertions(+), 9 deletions(-)diff --git a/include/linux/mm.h b/include/linux/mm.h index 665873c2788c..7ba210e86401 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h@@ -3191,7 +3191,7 @@ enum mf_flags { extern int memory_failure(unsigned long pfn, int flags); extern void memory_failure_queue(unsigned long pfn, int flags); extern void memory_failure_queue_kick(int cpu); -extern int unpoison_memory(unsigned long pfn); +extern int unpoison_memory(unsigned long pfn, bool reset_kpte, const char *reason); extern int sysctl_memory_failure_early_kill; extern int sysctl_memory_failure_recovery; extern void shake_page(struct page *p);diff --git a/mm/hwpoison-inject.c b/mm/hwpoison-inject.c index 5c0cddd81505..0dd17ba98ade 100644 --- a/mm/hwpoison-inject.c +++ b/mm/hwpoison-inject.c@@ -57,7 +57,7 @@ static int hwpoison_unpoison(void *data, u64 val) if (!capable(CAP_SYS_ADMIN)) return -EPERM; - return unpoison_memory(val); + return unpoison_memory(val, false, "hwpoison-inject");
s/hwpoison-inject/hwpoison/ or maybe s/hwpoison-inject/debugfs/
quoted hunk ↗ jump to hunk
} DEFINE_DEBUGFS_ATTRIBUTE(hwpoison_fops, NULL, hwpoison_inject, "%lli\n");diff --git a/mm/memory-failure.c b/mm/memory-failure.c index 95c218bb0a37..a46de3be1dd7 100644 --- a/mm/memory-failure.c +++ b/mm/memory-failure.c@@ -2132,21 +2132,26 @@ core_initcall(memory_failure_init); /** * unpoison_memory - Unpoison a previously poisoned page * @pfn: Page number of the to be unpoisoned page + * @reset_kpte: Reset the PTE entry for kmap + * @reason: The callers tells why unpoisoning the page * - * Software-unpoison a page that has been poisoned by - * memory_failure() earlier. + * Unpoison a page that has been poisoned by memory_failure() earlier. * - * This is only done on the software-level, so it only works - * for linux injected failures, not real hardware failures + * For linux injected failures, there is no need to reset PTE entry. + * It's possible to fix hardware memory failure on a virtualization platform, + * once hypervisor fixes the failure, guest needs put page back to buddy and + * reset the PTE entry in kernel.
Why can't we do this unconditionally? Just check if the PTE is poisoned, and if so, reset it. -- Thanks, David / dhildenb _______________________________________________ Virtualization mailing list Virtualization@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/virtualization