From: Muchun Song <songmuchun@bytedance.com>
To: Ritesh Harjani <ritesh.list@gmail.com>,
Madhavan Srinivasan <maddy@linux.ibm.com>,
Mike Rapoport <rppt@kernel.org>,
David Hildenbrand <david@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Michael Ellerman <mpe@ellerman.id.au>,
Nicholas Piggin <npiggin@gmail.com>,
Christophe Leroy <chleroy@kernel.org>,
Venkat Rao Bagalkote <venkat88@linux.ibm.com>,
Shrikanth Hegde <sshegde@linux.ibm.com>,
Pavithra <pavrampu@linux.ibm.com>,
"Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>,
Muchun Song <muchun.song@linux.dev>,
linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org, stable@vger.kernel.org,
Muchun Song <songmuchun@bytedance.com>
Subject: [PATCH] powerpc/mm: fix uninitialized ZONE_DEVICE struct pages with PMDs
Date: Thu, 29 Oct 2026 14:36:01 +0800 [thread overview]
Message-ID: <20261029063601.1961415-1-songmuchun@bytedance.com> (raw)
PowerPC radix vmemmap population can reuse an existing PMD mapping while
populating a device DAX range whose section is marked as HVO-enabled. The
reused mapping is an ordinary vmemmap mapping: the redundant tail struct
pages are not remapped to the shared tail page.
Leaving the section marked as HVO-enabled makes later ZONE_DEVICE
initialization treat the range as optimized and initialize only the struct
pages that would be backed by a real HVO mapping. The remaining tail struct
pages can then be left uninitialized even though they are still used as
metadata for the device DAX compound page.
This first triggers a zone mismatch warning in __init_single_page(), then
faults while initializing the pageblock flags:
WARNING: mm/mm_init.c:600 at __init_single_page+0xd0/0xf4
Call Trace:
memmap_init_zone_device+0x164/0x430
memremap_pages+0x43c/0x93c
devm_memremap_pages+0x3c/0xa4
dev_dax_probe+0x264/0x3d0
dax_bus_probe+0x140/0x1c8
BUG: Kernel NULL pointer dereference on read at 0x00001400
__set_pfnblock_flags_mask.constprop.0+0x34/0x160
memmap_init_zone_device+0x358/0x430
On kernels without these initialization-time diagnostics, the
uninitialized metadata remains latent. When userspace later maps and
accesses the affected device DAX range, the kernel operates on those struct
pages and panics at that point instead of during device initialization.
The Fixes target predates the section-based vmemmap optimization
infrastructure, so older kernels do not have section state that can be
marked non-HVO. Backports to such kernels need to handle the PMD-reuse case
in powerpc radix code directly, for example by initializing the tail struct
pages that core ZONE_DEVICE initialization would otherwise skip.
Mark the section as non-HVO when reusing an existing PMD mapping, so the
section's HVO state matches the actual vmemmap layout and all required
struct pages are initialized.
Fixes: f2b79c0d7968 ("powerpc/book3s64/radix: add support for vmemmap optimization for radix")
Cc: stable@vger.kernel.org
Reported-by: Pavithra <pavrampu@linux.ibm.com>
Closes: https://lore.kernel.org/r/97f85592bb78a273be8519e6897e7f9b9bd31469.1793070429.git.ritesh.list@gmail.com
Signed-off-by: Muchun Song <songmuchun@bytedance.com>
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
---
arch/powerpc/mm/book3s64/radix_pgtable.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c b/arch/powerpc/mm/book3s64/radix_pgtable.c
index 44868b62b14e..4f75f10ed68f 100644
--- a/arch/powerpc/mm/book3s64/radix_pgtable.c
+++ b/arch/powerpc/mm/book3s64/radix_pgtable.c
@@ -1261,7 +1261,16 @@ int __meminit vmemmap_populate_compound_pages(unsigned long start_pfn,
return -ENOMEM;
if (pmd_leaf(READ_ONCE(*pmd))) {
- /* existing huge mapping. Skip the range */
+ unsigned long addr_pfn = page_to_pfn((struct page *)addr);
+ struct mem_section *ms = __pfn_to_section(addr_pfn);
+
+ /*
+ * Existing PMD mappings can cover the edges of a valid
+ * HVO populate range. They are ordinary vmemmap mappings,
+ * so the current section must not be treated as HVO-backed
+ * when its struct pages are initialized later.
+ */
+ section_set_compound_order(ms, 0);
next = pmd_addr_end(addr, end);
continue;
}
base-commit: d865f2677c44cb2171b833d6775cf692756fa8be
--
2.54.0
next reply other threads:[~2026-10-29 6:36 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-29 6:36 Muchun Song [this message]
2026-10-29 15:45 ` [PATCH] powerpc/mm: fix uninitialized ZONE_DEVICE struct pages with PMDs Ritesh Harjani
2026-10-30 3:03 ` Muchun Song
2026-10-30 10:20 ` Ritesh Harjani
2026-10-30 11:13 ` Muchun Song
2026-10-30 6:42 ` pavrampu
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=20261029063601.1961415-1-songmuchun@bytedance.com \
--to=songmuchun@bytedance.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@linux.ibm.com \
--cc=chleroy@kernel.org \
--cc=david@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=maddy@linux.ibm.com \
--cc=mpe@ellerman.id.au \
--cc=muchun.song@linux.dev \
--cc=npiggin@gmail.com \
--cc=pavrampu@linux.ibm.com \
--cc=ritesh.list@gmail.com \
--cc=rppt@kernel.org \
--cc=sshegde@linux.ibm.com \
--cc=stable@vger.kernel.org \
--cc=venkat88@linux.ibm.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