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

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

[Muchun Song]

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.

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
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(-)

diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c b/arch/powerpc/mm/book3s64/radix_pgtable.c
index 44868b62b14e..4f75f10ed68f 100644
--- a/arch/powerpc/mm/book3s64/radix_pgtable.c
+++ b/arch/powerpc/mm/book3s64/radix_pgtable.c
@@ -1261,7 +1261,16 @@ int __meminit vmemmap_populate_compound_pages(unsigned long start_pfn,
 			return -ENOMEM;
 
 		if (pmd_leaf(READ_ONCE(*pmd))) {
-			/* existing huge mapping. Skip the range */
+			unsigned long addr_pfn = page_to_pfn((struct page *)addr);
+			struct mem_section *ms = __pfn_to_section(addr_pfn);
+
+			/*
+			 * Existing PMD mappings can cover the edges of a valid
+			 * HVO populate range. They are ordinary vmemmap mappings,
+			 * so the current section must not be treated as HVO-backed
+			 * when its struct pages are initialized later.
+			 */
+			section_set_compound_order(ms, 0);
 			next = pmd_addr_end(addr, end);
 			continue;
 		}

base-commit: d865f2677c44cb2171b833d6775cf692756fa8be
-- 
2.54.0

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

[Ritesh Harjani]

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

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

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

-ritesh

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

[Muchun Song]

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

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

Thanks.

> 
> -ritesh

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

[pavrampu]

On 2026-10-29 12:06, Muchun Song wrote:
> 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.
> 
> 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
> 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(-)
> 
> diff --git a/arch/powerpc/mm/book3s64/radix_pgtable.c
> b/arch/powerpc/mm/book3s64/radix_pgtable.c
> index 44868b62b14e..4f75f10ed68f 100644
> --- a/arch/powerpc/mm/book3s64/radix_pgtable.c
> +++ b/arch/powerpc/mm/book3s64/radix_pgtable.c
> @@ -1261,7 +1261,16 @@ int __meminit
> vmemmap_populate_compound_pages(unsigned long start_pfn,
>  			return -ENOMEM;
> 
>  		if (pmd_leaf(READ_ONCE(*pmd))) {
> -			/* existing huge mapping. Skip the range */
> +			unsigned long addr_pfn = page_to_pfn((struct page *)addr);
> +			struct mem_section *ms = __pfn_to_section(addr_pfn);
> +
> +			/*
> +			 * Existing PMD mappings can cover the edges of a valid
> +			 * HVO populate range. They are ordinary vmemmap mappings,
> +			 * so the current section must not be treated as HVO-backed
> +			 * when its struct pages are initialized later.
> +			 */
> +			section_set_compound_order(ms, 0);
>  			next = pmd_addr_end(addr, end);
>  			continue;
>  		}
> 
> base-commit: d865f2677c44cb2171b833d6775cf692756fa8be

Tested on IBM Power10 (ppc64le), kernel v7.3

Tested-by: Pavithra Prakash <pavrampu@linux.ibm.com>