The patch titled
Subject: riscv: handle VM_FAULT_[HWPOISON|HWPOISON_LARGE] faults instead of panicking
has been added to the -mm mm-hotfixes-unstable branch. Its filename is
riscv-handle-vm_fault_-faults-instead-of-panicking.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/riscv-handle-vm_fault_-faults-instead-of-panicking.patch
This patch will later appear in the mm-hotfixes-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
Subject: riscv: handle VM_FAULT_[HWPOISON|HWPOISON_LARGE] faults instead of panicking
Date: Thu, 28 Sep 2023 17:18:45 +0200
Patch series "Fix set_huge_pte_at()".
A recent report [1] from Ryan for arm64 revealed that we do not handle
swap entries when setting a hugepage backed by a NAPOT region (the contpte
riscv equivalent).
As explained in [1], the issue was discovered by a new test in kselftest
which uses poison entries, but the symptoms are different from arm64 though:
- the riscv kernel bugs because we do not handle VM_FAULT_HWPOISON*,
this is fixed by patch 1,
- after that, the test passes because the first pte_napot() fails (the
poison entry does not have the N bit set), and then we only set the
first page table entry covering the NAPOT hugepage, which is enough
for hugetlb_fault() to correctly raise a VM_FAULT_HWPOISON wherever we
write in this mapping since only this first page table entry is
checked
(see https://elixir.bootlin.com/linux/v6.6-rc3/source/mm/hugetlb.c#L6071).
But this seems fragile so patch 2 sets all page table entries of a
NAPOT mapping.
[1]: https://lore.kernel.org/linux-arm-kernel/20230922115804.2043771-1-ryan.roberts@xxxxxxx/
This patch (of 2):
We used to panic when such faults were encountered but we should handle
those faults gracefully for userspace by sending a SIGBUS to the process,
like most architectures do.
Link: https://lkml.kernel.org/r/20230928151846.8229-1-alexghiti@xxxxxxxxxxxx
Link: https://lkml.kernel.org/r/20230928151846.8229-2-alexghiti@xxxxxxxxxxxx
Signed-off-by: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx>
Cc: Albert Ou <aou@xxxxxxxxxxxxxxxxx>
Cc: Andrew Jones <ajones@xxxxxxxxxxxxxxxx>
Cc: Conor Dooley <conor@xxxxxxxxxx>
Cc: Palmer Dabbelt <palmer@xxxxxxxxxxx>
Cc: Paul Walmsley <paul.walmsley@xxxxxxxxxx>
Cc: Qinglin Pan <panqinglin2020@xxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
---
arch/riscv/mm/fault.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/arch/riscv/mm/fault.c~riscv-handle-vm_fault_-faults-instead-of-panicking
+++ a/arch/riscv/mm/fault.c
@@ -72,7 +72,7 @@ static inline void mm_fault_error(struct
}
pagefault_out_of_memory();
return;
- } else if (fault & VM_FAULT_SIGBUS) {
+ } else if (fault & (VM_FAULT_SIGBUS | VM_FAULT_HWPOISON | VM_FAULT_HWPOISON_LARGE)) {
/* Kernel mode? Handle exceptions or die */
if (!user_mode(regs)) {
no_context(regs, addr);
_
Patches currently in -mm which might be from alexghiti@xxxxxxxxxxxx are
riscv-handle-vm_fault_-faults-instead-of-panicking.patch
riscv-fix-set_huge_pte_at-for-napot-mappings-when-a-swap-entry-is-set.patch
