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
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".
Also
Reported-by: Ritesh Harjani (IBM) <[email protected]>
Closes: https://lore.kernel.org/[email protected]
I don't believe that Ritesh has tested this? He wasn't cc'ed...
