Re: [PATCH v3 mm-hotfixes 0/5] mm, arch: a more robust approach to sync top level kernel page tables

From: Andrew Morton
Date: Fri Jul 25 2025 - 19:51:19 EST


On Fri, 25 Jul 2025 10:21:01 +0900 Harry Yoo <harry.yoo@xxxxxxxxxx> wrote:

> During our internal testing, we started observing intermittent boot
> failures when the machine uses 4-level paging and has a large amount
> of persistent memory:
>
> BUG: unable to handle page fault for address: ffffe70000000034
> #PF: supervisor write access in kernel mode
> #PF: error_code(0x0002) - not-present page
> PGD 0 P4D 0
> Oops: 0002 [#1] SMP NOPTI
> RIP: 0010:__init_single_page+0x9/0x6d
> Call Trace:
> <TASK>
> __init_zone_device_page+0x17/0x5d
> memmap_init_zone_device+0x154/0x1bb
> pagemap_range+0x2e0/0x40f
> memremap_pages+0x10b/0x2f0
> devm_memremap_pages+0x1e/0x60
> dev_dax_probe+0xce/0x2ec [device_dax]
> dax_bus_probe+0x6d/0xc9
> [... snip ...]
> </TASK>
>
> ...
>
> arch/x86/include/asm/pgalloc.h | 20 +++++++++++++
> arch/x86/include/asm/pgtable_64_types.h | 3 ++
> arch/x86/mm/init_64.c | 37 ++++++++++++++-----------
> arch/x86/mm/kasan_init_64.c | 8 +++---
> include/asm-generic/pgalloc.h | 16 +++++++++++
> include/linux/pgtable.h | 17 ++++++++++++
> include/linux/vmalloc.h | 16 -----------
> mm/kasan/init.c | 10 +++----
> mm/percpu.c | 4 +--
> mm/sparse-vmemmap.c | 4 +--
> 10 files changed, 90 insertions(+), 45 deletions(-)

Are any other architectures likely to be affected by this flaw?

It's late for 6.16. I'd propose that this series target 6.17 and once
merged, the cc:stable tags will take care of 6.16.x and earlier.

It's regrettable that the series contains some patches which are
cc:stable and some which are not. Because 6.16.x and earlier will end
up getting only some of these patches, so we're backporting an untested
patch combination. It would be better to prepare all this as two
series: one for backporting and the other not.

It's awkward that some of the cc:stable patches have a Fixes: and
others do not. Exactly which kernel version(s) are we asking the
-stable maintainers to merge these patches into?

This looks somewhat more like an x86 series than an MM one. I can take
it via mm.git with suitable x86 acks. Or drop it from mm.git if it
goes into the x86 tree. We can discuss that.


For now, I'll add this to mm.git's mm-new branch. There it will get a
bit of exposure but it will be withheld from linux-next. Once 6.17-rc1
is released I can move this into mm.git's mm-unstable branch to expose
it to linux-next testers.

Thanks. I'll suppress the usual added-to-mm emails, save a few electrons.