[PATCH] mm: warn on unaligned compound zone device ranges

[PATCH] mm: warn on unaligned compound zone device ranges

[Muchun Song]

A compound page of order N must start at a PFN aligned to 2^N pages.
Therefore, a range used to initialize compound pages must start on a
compound-page boundary and contain an integral number of compound pages.

Two recent Device DAX bugs were caused by ranges that violated this
invariant, but neither was detected by memmap_init_zone_device().

Warn if the adjusted zone-device range violates this invariant so future
violations are reported when the compound pages are initialized.

Link: https://lore.kernel.org/r/20261016053944.2579541-1-songmuchun@bytedance.com
Link: https://lore.kernel.org/r/20261016054914.2601510-1-songmuchun@bytedance.com
Assisted-by: LLM
Signed-off-by: Muchun Song <songmuchun@bytedance.com>
---
 mm/mm_init.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/mm_init.c b/mm/mm_init.c
index 4c17a892924d..01ced0553ce9 100644
--- a/mm/mm_init.c
+++ b/mm/mm_init.c
@@ -1142,6 +1142,8 @@ void __ref memmap_init_zone_device(struct zone *zone,
 	if (!nr_pages)
 		return;
 
+	VM_WARN_ON(!IS_ALIGNED(start_pfn | nr_pages, pfns_per_compound));
+
 	/*
 	 * Seed the reusable head-page template from the first real struct
 	 * page. The normal page-init and refcount helpers must operate on

base-commit: 63562804f25cb5b6f5e4f5e3a9f0d1c3c6868596
-- 
2.54.0

Re: [PATCH] mm: warn on unaligned compound zone device ranges

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] mm: out-of-bounds struct page write due to unhandled unaligned range
--

commit b8dd4e5f7a50b091c065c7673c2a6a148529465a
Author: Muchun Song <muchun.song@linux.dev>

mm: warn on unaligned compound zone device ranges

A compound page of order N must start at a PFN aligned to 2^N pages.
Therefore, a range used to initialize compound pages must start on a
compound-page boundary and contain an integral number of compound pages.

Link: https://lore.kernel.org/r/20261016053944.2579541-1-songmuchun@bytedance.com
Link: https://lore.kernel.org/r/20261016054914.2601510-1-songmuchun@bytedance.com

> diff --git a/mm/mm_init.c b/mm/mm_init.c
> index 4c17a892924d2..01ced0553ce9b 100644
> --- a/mm/mm_init.c
> +++ b/mm/mm_init.c
> @@ -1142,6 +1142,8 @@ void __ref memmap_init_zone_device(struct zone *zone,
>  	if (!nr_pages)
>  		return;
>  
> +	VM_WARN_ON(!IS_ALIGNED(start_pfn | nr_pages, pfns_per_compound));
> +

[Severity: High]
This warning detects the unaligned range, but does this still allow an
out-of-bounds write if execution continues?

If nr_pages is not a multiple of pfns_per_compound, the main initialization
loop in memmap_init_zone_device() advances by pfns_per_compound chunks:

	for (; pfn < end_pfn; pfn += pfns_per_compound) {
		...
		memmap_init_compound(page, pfn, zone_idx, nid, pgmap,
				     compound_nr_pages(pfn, pgmap));
	}

And memmap_init_compound() will then write exactly pfns_per_compound entries
(since compound_nr_pages() returns pfns_per_compound), ignoring the actual
end of the zone-device range:

	for (pfn = head_pfn + 2; pfn < end_pfn; pfn++)
		zone_device_page_init_from_template(pfn_to_page(pfn), ...);

Could this overrun the allocated range and corrupt adjacent struct pages?

Additionally, since VM_WARN_ON is compiled out without CONFIG_DEBUG_VM,
could this result in silent memory corruption on production kernels?

Should we abort the initialization when an unaligned range is detected?

>  	/*
>  	 * Seed the reusable head-page template from the first real struct
>  	 * page. The normal page-init and refcount helpers must operate on

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261016131334.3419393-1-songmuchun@bytedance.com?part=1

Re: [PATCH] mm: warn on unaligned compound zone device ranges

[Andrew Morton]

On Fri, 16 Oct 2026 21:13:34 +0800 Muchun Song <songmuchun@bytedance.com> wrote:

> A compound page of order N must start at a PFN aligned to 2^N pages.
> Therefore, a range used to initialize compound pages must start on a
> compound-page boundary and contain an integral number of compound pages.
> 
> Two recent Device DAX bugs were caused by ranges that violated this
> invariant, but neither was detected by memmap_init_zone_device().
> 
> Warn if the adjusted zone-device range violates this invariant so future
> violations are reported when the compound pages are initialized.
> 
> ...
>
> --- a/mm/mm_init.c
> +++ b/mm/mm_init.c
> @@ -1142,6 +1142,8 @@ void __ref memmap_init_zone_device(struct zone *zone,
>  	if (!nr_pages)
>  		return;
>  
> +	VM_WARN_ON(!IS_ALIGNED(start_pfn | nr_pages, pfns_per_compound));

Would VM_WARN_ON_ONCE() suffice?

> +
>  	/*
>  	 * Seed the reusable head-page template from the first real struct
>  	 * page. The normal page-init and refcount helpers must operate on
> 
> base-commit: 63562804f25cb5b6f5e4f5e3a9f0d1c3c6868596
> -- 
> 2.54.0

Re: [PATCH] mm: warn on unaligned compound zone device ranges

[Muchun Song]

> On Oct 17, 2026, at 10:21, Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> On Fri, 16 Oct 2026 21:13:34 +0800 Muchun Song <songmuchun@bytedance.com> wrote:
> 
>> A compound page of order N must start at a PFN aligned to 2^N pages.
>> Therefore, a range used to initialize compound pages must start on a
>> compound-page boundary and contain an integral number of compound pages.
>> 
>> Two recent Device DAX bugs were caused by ranges that violated this
>> invariant, but neither was detected by memmap_init_zone_device().
>> 
>> Warn if the adjusted zone-device range violates this invariant so future
>> violations are reported when the compound pages are initialized.
>> 
>> ...
>> 
>> --- a/mm/mm_init.c
>> +++ b/mm/mm_init.c
>> @@ -1142,6 +1142,8 @@ void __ref memmap_init_zone_device(struct zone *zone,
>> if (!nr_pages)
>> return;
>> 
>> + 	VM_WARN_ON(!IS_ALIGNED(start_pfn | nr_pages, pfns_per_compound));
> 
> Would VM_WARN_ON_ONCE() suffice?

What I was thinking is that this function won't be called frequently, so it
won't encounter a large volume of log flushing. Therefore, I didn't use the
ONCE interface, and this way it can continue to catch similar issues.

I'm OK if you prefer VM_WARN_ON_ONCE() though. Let me know what you think.

Thanks,
Muchun

> 
>> +
>> 	/*
>>  	 * Seed the reusable head-page template from the first real struct
>>  	 * page. The normal page-init and refcount helpers must operate on
>> 
>> base-commit: 63562804f25cb5b6f5e4f5e3a9f0d1c3c6868596
>> -- 
>> 2.54.0