Message-ID: <aIQnvFTkQGieHfEh@hyeyoo>
Date: Sat, 26 Jul 2025 09:56:28 +0900
From: Harry Yoo <harry.yoo@...cle.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
        Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Andy Lutomirski <luto@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        "H . Peter Anvin" <hpa@...cr.com>,
        Andrey Ryabinin <ryabinin.a.a@...il.com>,
        Arnd Bergmann <arnd@...db.de>, Dennis Zhou <dennis@...nel.org>,
        Tejun Heo <tj@...nel.org>, Christoph Lameter <cl@...two.org>,
        Alexander Potapenko <glider@...gle.com>,
        Andrey Konovalov <andreyknvl@...il.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Vincenzo Frascino <vincenzo.frascino@....com>,
        Juergen Gross <jgross@...e.de>, Kevin Brodsky <kevin.brodsky@....com>,
        Oscar Salvador <osalvador@...e.de>,
        Joao Martins <joao.m.martins@...cle.com>,
        Lorenzo Sccakes <lorenzo.stoakes@...cle.com>,
        Jane Chu <jane.chu@...cle.com>, Alistair Popple <apopple@...dia.com>,
        Mike Rapoport <rppt@...nel.org>, David Hildenbrand <david@...hat.com>,
        Gwan-gyeong Mun <gwan-gyeong.mun@...el.com>,
        "Aneesh Kumar K . V" <aneesh.kumar@...ux.ibm.com>,
        Uladzislau Rezki <urezki@...il.com>,
        "Liam R . Howlett" <Liam.Howlett@...cle.com>,
        Vlastimil Babka <vbabka@...e.cz>,
        Suren Baghdasaryan <surenb@...gle.com>, Michal Hocko <mhocko@...e.com>,
        Qi Zheng <zhengqi.arch@...edance.com>,
        Ard Biesheuvel <ardb@...nel.org>, Thomas Huth <thuth@...hat.com>,
        John Hubbard <jhubbard@...dia.com>,
        Ryan Roberts <ryan.roberts@....com>, Peter Xu <peterx@...hat.com>,
        Dev Jain <dev.jain@....com>, Bibo Mao <maobibo@...ngson.cn>,
        Anshuman Khandual <anshuman.khandual@....com>,
        Joerg Roedel <joro@...tes.org>, x86@...nel.org,
        linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
        linux-mm@...ck.org
Subject: Re: [PATCH v3 mm-hotfixes 0/5] mm, arch: a more robust approach to
 sync top level kernel page tables

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

Powered by blists - more mailing lists