PowerPC radix vmemmap population can reuse an existing PMD mapping for
a device DAX range marked HVO-enabled. The reused mapping is ordinary:
its tail struct pages are not remapped to the shared tail page.
Leaving the section marked HVO-enabled makes memmap_init_zone_device()
treat the range as optimized and skip initializing real tail struct pages
that remain in use. This first triggers a zone mismatch warning, 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
Without these diagnostics, the uninitialized metadata remains latent until
userspace accesses the device DAX range and triggers a later panic.
Mark the section non-HVO when reusing a PMD mapping so its state matches
the actual vmemmap layout and core ZONE_DEVICE code initializes all real
struct pages.
The Fixes target predates the section-based vmemmap optimization
infrastructure, so this patch cannot be applied directly to some older
kernels. Older kernels instead need to pass the vmemmap bounds to a
range-aware vmemmap_can_optimize() and reject optimization on PowerPC if
a PMD leaf overlaps the range. This reuses the existing mapping normally
and makes core ZONE_DEVICE code initialize all real tail entries.
Fixes: f2b79c0d7968 ("powerpc/book3s64/radix: add support for vmemmap
optimization for radix")
Cc: <[email protected]> # see patch description, needs a different fix for
<= 7.3
Signed-off-by: Muchun Song <[email protected]>
Reported-by: Pavithra <[email protected]>
Closes:
https://lore.kernel.org/r/97f85592bb78a273be8519e6897e7f9b9bd31469.1793070429.git.ritesh.l...@gmail.com
Reviewed-by: Ritesh Harjani (IBM) <[email protected]>
Tested-by: Pavithra Prakash <[email protected]>
---
v2:
- Rewrite the commit message.
- Describe the range-aware vmemmap_can_optimize() fix for older kernels
- Note that kernels through v7.3 require a different stable fix
(suggested by Ritesh Harjani)
- Collect Tested-by from Pavithra Prakash
---
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
