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

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

> On Oct 30, 2026, at 18:20, Ritesh Harjani (IBM) <ritesh.list@gmail.com> wrote:
> 
> Muchun Song <muchun.song@linux.dev> writes:
> 
>>> 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?
>> 
> 
> yes, I think we can do a separate patch later for older kernels. I
> will look at your suggestions to see what can be done in that case.

Thanks.

> 
> 
>>> 
>>>> 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.
>> 
> 
> I think we can add an explicit comment like this then?
> 
> Fixes: f2b79c0d7968 ("powerpc/book3s64/radix: add support for vmemmap optimization for radix")
> Cc: <stable@vger.kernel.org> # see patch description, needs a different fix for <= 7.3

Oh, yeah, I'll add this in v2. Thanks for your suggestion.

Thanks.

> 
> -ritesh