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

[IBM]

Muchun Song <muchun.song@xxxxxxxxx> writes:

>> On Oct 29, 2026, at 23:45, Ritesh Harjani (IBM) <ritesh.list@xxxxxxxxx> wrote:
>> 
>> Muchun Song <songmuchun@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
>> 
>> ... 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.


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

-ritesh