> On Oct 30, 2026, at 18:20, Ritesh Harjani (IBM) <[email protected]> wrote:
>
> Muchun Song <[email protected]> writes:
>
>>> On Oct 29, 2026, at 23:45, Ritesh Harjani (IBM) <[email protected]>
>>> wrote:
>>>
>>> Muchun Song <[email protected]> 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: [email protected]
>>>
>>> ... 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 <[email protected]>
>>>> Closes:
>>>> https://lore.kernel.org/r/97f85592bb78a273be8519e6897e7f9b9bd31469.1793070429.git.ritesh.l...@gmail.com
>>>> Signed-off-by: Muchun Song <[email protected]>
>>>> Reviewed-by: Ritesh Harjani (IBM) <[email protected]>
>>>> ---
>>>> 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: <[email protected]> # see patch description, needs a different fix
> for <= 7.3
Oh, yeah, I'll add this in v2. Thanks for your suggestion.
Thanks.
>
> -ritesh
