From: Andrew Morton <akpm@linux-foundation.org>
To: Harry Yoo <harry.yoo@oracle.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
Dave Hansen <dave.hansen@linux.intel.com>,
Andy Lutomirski <luto@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
"H . Peter Anvin" <hpa@zyccr.com>,
Andrey Ryabinin <ryabinin.a.a@gmail.com>,
Arnd Bergmann <arnd@arndb.de>, Dennis Zhou <dennis@kernel.org>,
Tejun Heo <tj@kernel.org>, Christoph Lameter <cl@gentwo.org>,
Alexander Potapenko <glider@google.com>,
Andrey Konovalov <andreyknvl@gmail.com>,
Dmitry Vyukov <dvyukov@google.com>,
Vincenzo Frascino <vincenzo.frascino@arm.com>,
Juergen Gross <jgross@suse.de>,
Kevin Brodsky <kevin.brodsky@arm.com>,
Oscar Salvador <osalvador@suse.de>,
Joao Martins <joao.m.martins@oracle.com>,
Lorenzo Sccakes <lorenzo.stoakes@oracle.com>,
Jane Chu <jane.chu@oracle.com>,
Alistair Popple <apopple@nvidia.com>,
Mike Rapoport <rppt@kernel.org>,
David Hildenbrand <david@redhat.com>,
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>,
"Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>,
Uladzislau Rezki <urezki@gmail.com>,
"Liam R . Howlett" <Liam.Howlett@oracle.com>,
Vlastimil Babka <vbabka@suse.cz>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
Qi Zheng <zhengqi.arch@bytedance.com>,
Ard Biesheuvel <ardb@kernel.org>, Thomas Huth <thuth@redhat.com>,
John Hubbard <jhubbard@nvidia.com>,
Ryan Roberts <ryan.roberts@arm.com>, Peter Xu <peterx@redhat.com>,
Dev Jain <dev.jain@arm.com>, Bibo Mao <maobibo@loongson.cn>,
Anshuman Khandual <anshuman.khandual@arm.com>,
Joerg Roedel <joro@8bytes.org>,
x86@kernel.org, linux-kernel@vger.kernel.org,
linux-arch@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH v3 mm-hotfixes 0/5] mm, arch: a more robust approach to sync top level kernel page tables
Date: Fri, 25 Jul 2025 16:51:01 -0700 [thread overview]
Message-ID: <20250725165101.e636bbe3fa69ad0b73810914@linux-foundation.org> (raw)
In-Reply-To: <20250725012106.5316-1-harry.yoo@oracle.com>
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?
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.
next prev parent reply other threads:[~2025-07-25 23:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-25 1:21 Harry Yoo
2025-07-25 1:21 ` [PATCH v3 mm-hotfixes 1/5] mm: move page table sync declarations to linux/pgtable.h Harry Yoo
2025-07-25 1:21 ` [PATCH v3 mm-hotfixes 2/5] mm: introduce and use {pgd,p4d}_populate_kernel() Harry Yoo
2025-07-29 7:59 ` Harry Yoo
2025-07-25 1:21 ` [PATCH v3 mm-hotfixes 3/5] x86/mm/64: define ARCH_PAGE_TABLE_SYNC_MASK and arch_sync_kernel_mappings() Harry Yoo
2025-07-25 1:21 ` [PATCH v3 mm-hotfixes 4/5] x86/mm/64: convert p*d_populate{,_init} to _kernel variants Harry Yoo
2025-07-25 1:21 ` [PATCH v3 mm-hotfixes 5/5] x86/mm: drop unnecessary calls to sync_global_pgds() and fold into its sole user Harry Yoo
2025-07-25 23:51 ` Andrew Morton [this message]
2025-07-26 0:56 ` [PATCH v3 mm-hotfixes 0/5] mm, arch: a more robust approach to sync top level kernel page tables Harry Yoo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250725165101.e636bbe3fa69ad0b73810914@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=Liam.Howlett@oracle.com \
--cc=andreyknvl@gmail.com \
--cc=aneesh.kumar@linux.ibm.com \
--cc=anshuman.khandual@arm.com \
--cc=apopple@nvidia.com \
--cc=ardb@kernel.org \
--cc=arnd@arndb.de \
--cc=bp@alien8.de \
--cc=cl@gentwo.org \
--cc=dave.hansen@linux.intel.com \
--cc=david@redhat.com \
--cc=dennis@kernel.org \
--cc=dev.jain@arm.com \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=gwan-gyeong.mun@intel.com \
--cc=harry.yoo@oracle.com \
--cc=hpa@zyccr.com \
--cc=jane.chu@oracle.com \
--cc=jgross@suse.de \
--cc=jhubbard@nvidia.com \
--cc=joao.m.martins@oracle.com \
--cc=joro@8bytes.org \
--cc=kevin.brodsky@arm.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=luto@kernel.org \
--cc=maobibo@loongson.cn \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=osalvador@suse.de \
--cc=peterx@redhat.com \
--cc=peterz@infradead.org \
--cc=rppt@kernel.org \
--cc=ryabinin.a.a@gmail.com \
--cc=ryan.roberts@arm.com \
--cc=surenb@google.com \
--cc=tglx@linutronix.de \
--cc=thuth@redhat.com \
--cc=tj@kernel.org \
--cc=urezki@gmail.com \
--cc=vbabka@suse.cz \
--cc=vincenzo.frascino@arm.com \
--cc=x86@kernel.org \
--cc=zhengqi.arch@bytedance.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox