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: [email protected]
Reported-by: Pavithra <[email protected]>
Closes:
https://lore.kernel.org/r/97f85592bb78a273be8519e6897e7f9b9bd31469.1793070429.git.ritesh.l...@gmail.com
Signed-off-by: Muchun Song <[email protected]>
Reviewed-by: Ritesh Harjani (IBM) <[email protected]>
---
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
