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