[PATCH v2] powerpc/mm: fix uninitialized ZONE_DEVICE struct pages with PMDs

[Muchun Song]

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: <stable@xxxxxxxxxxxxxxx> # see patch description, needs a different fix for <= 7.3
Signed-off-by: Muchun Song <songmuchun@xxxxxxxxxxxxx>
Reported-by: Pavithra <pavrampu@xxxxxxxxxxxxx>
Closes: https://lore.kernel.org/r/97f85592bb78a273be8519e6897e7f9b9bd31469.1793070429.git.ritesh.list@xxxxxxxxx
Reviewed-by: Ritesh Harjani (IBM) <ritesh.list@xxxxxxxxx>
Tested-by: Pavithra Prakash <pavrampu@xxxxxxxxxxxxx>
---
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