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

[Muchun Song <muchun.song@linux.dev>]

> On Oct 29, 2026, at 23:45, Ritesh Harjani (IBM) <ritesh.list@gmail.com> wrote:
> 
> Muchun Song <songmuchun@bytedance.com> writes:
> 
> Thanks Muchun,
> 
>> 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.
>> 
> 
> Actually that would be totally new code right? It won't be a straight
> forward backport, correct? ... 

Right. Because it's impossible to backport the whole section-based vmemmap
optimization infrastructure (48 commits).

> 
>> 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
> 
> ... then should we mark Cc: stable here with the above mentioned fixes
> tag? Because this patch cannot be backported as is to older kernels -
> for the reasons you mentioned above.

The comment following the trailer is used to guide stable maintainers to
backport proper prerequisite commits. It's hard to do that. So I choose to
mention the alternative in the commit message. But with the help of LLM,
I found the alternative is also not the right solution. The reason is as below.

That pmd_leaf() path only creates or reuses the vmemmap mapping. After it
returns, sparse_add_section() calls page_init_poison() on the whole memmap,
which overwrites any page state initialized there.

Therefore, older kernels must pass the PMD-leaf information to
memmap_init_zone_device() and let it initialize all real tail struct
page entries. Initializing them immediately in the PowerPC pmd_leaf()
branch would be too early.

Another solution is making vmemmap_can_optimize() range-aware by passing
the vmemmap start and end addresses.

On PowerPC, reject the optimization when any part of the range is already
covered by a PMD leaf. This ensures that an existing PMD mapping is reused
normally and that all real tail struct page entries are initialized later
by the core code.

Maybe it should be a separate patch for old kernels? Thoughts?

> 
>> 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(-)
>> 
> 
> I think, this patch should go via mm tree, due to all the dependencies
> coming from there, right?

Better. I hope Andrew will pick it up once I send a v2 version with more
proper commit message changed.

Thanks.

> 
> -ritesh