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. >> >>> 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 -ritesh
