On Fri, Oct 30, 2026 at 07:53:25PM +0800, Muchun Song wrote:
> 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]>
Acked-by: Mike Rapoport (Microsoft) <[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
>
--
Sincerely yours,
Mike.
