> On Oct 25, 2026, at 09:38, Andrew Morton <[email protected]> wrote:
>
> On Sat, 24 Oct 2026 19:25:55 +0800 Muchun Song <[email protected]>
> wrote:
>
>> Only range sizes are currently validated against dev_dax->align. A
>> dynamic device can therefore select a large-page alignment and allocate a
>> range whose start is not naturally aligned.
>>
>> Sashiko found that memmap_init_zone_device() could then initialize the
>> struct pages with a large-page order for a physical range that is not
>> naturally aligned. A subsequent write to a userspace mapping then
>> triggered a kernel panic in testing.
>>
>> The automatic resize path can also split a size-aligned request across
>> arbitrary free gaps. When devices with different alignments fragment a
>> region, this can extend a range by less than the device alignment. A later
>> allocation then fails, leaving the failed resize partially applied.
>>
>> Initialize the device alignment before its first allocation. Validate both
>> the start and size of allocated and adjusted ranges. Use the same
>> aligned-gap iterator for free-space accounting and range allocation so the
>> pre-check and allocation path cannot diverge. Skip unusable gaps and
>> serialize size validation with alignment updates.
>>
>> Static Device DAX already has a pre-populated pgmap whose full range was
>> validated against memremap_compat_align(). Its usable data range may begin
>> after namespace metadata, so require only dev_dax->align for static
>> devices. Dynamic Device DAX builds its pgmap from the allocated ranges and
>> must continue to satisfy both alignments.
>
> Thanks. This is now a must-have for 7.4.
>
> I suggest that the changelog mention that the bug becomes hittable once
Let me explain this issue in more detail. Without my patch set, the
problem was not hidden—it was simply shifted to the second stage.
DAX device usage is divided into two stages:
1) Device DAX initialization
2) When user space maps a Device DAX device.
Without my patch set, this problem would trigger a kernel panic during
stage 2). After applying my patch set, the problem is caught during the
first stage (with the current prerequisite that CONFIG_DEBUG_VM is
enabled; if it is not enabled, the problem still occurs in the second
stage).
Therefore, there is already a serious problem that will trigger a panic
when users use it.
> your series "mm: Unify device DAX and HugeTLB vmemmap population paths"
> exposes it. That's
>
> 4b77739fe789 ("mm/sparse-vmemmap: drop VMEMMAP_POPULATE_DAX").
>
> I intend to send this to Linus next week.
>
> Maybe also a Fixes: 4b77739fe789. That series didn't create the bug,
> but this data provides notification to people who are backporting this
> series (unlikely) "hey, you need to add this fix as well".
Based on the above info, do you think it is necessary to include this
commit as a Fixes tag? My inclination is to exclude it, because the
issue is still there. It's just that it gets triggered earlier when the
debug kernel is enabled.
>
> Also
> Reported-by: Ritesh Harjani (IBM) <[email protected]>
> Closes: https://lore.kernel.org/[email protected]
This is a similar issue to the one reported by Ritesh, but it was reported
by Sashiko.
Thanks,
Muchun
>
> I don't believe that Ritesh has tested this? He wasn't cc'ed...
