[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

[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