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

[Harry Yoo <harry.yoo@oracle.com>]

On Fri, Jul 25, 2025 at 04:51:01PM -0700, Andrew Morton wrote:
> On Fri, 25 Jul 2025 10:21:01 +0900 Harry Yoo <harry.yoo@oracle.com> 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?

In theory, any architecture that does not share a kernel page table between
tasks can be affected if they forgot to sync page tables properly.
e.g., arm64 uses a single page table for kernel address space which
is shared between tasks, so it should not be affected.

But I'm not aware of any other architectures that are _actually_ known to
have this flaw. Even on x86, it was quite hard to trigger without
hot-plugging a large amount of memory. But if it turns out other
architectures are affected, they can be fixed later in the same way as
x86-64.

> 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.

Yes. It's quite late and that makes sense.

> 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.

Yes, that makes sense and I'll post it as two series (one for backporting
and the other not for backporting but as a follow-up) unless someone
speaks up and argues that it should be backported as a whole.

> 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?

I thought technically patch 1 and 2 are not fixing any bugs but they
are prequisites of patch 3. But I think you're right that it only
confuses -stable maintainers. I'll add Fixes: tags (the same one as
patch 3) to patch 1 and 2 in future revisions.

> 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.

It touches both x86/mm and general mm code so I was unsure which tree
is the right one :) I don't have a strong opinion and I'm fine with both.
Let's wait to hear opinions from the x86/mm maintainers.

> 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.

Yeah, the Cc list got quite long since it touches many files..

Thanks a lot, Andrew!

-- 
Cheers,
Harry / Hyeonggon