Re: [PATCH v5] dax/bus: Fix Device DAX range alignment validation

[Ritesh Harjani (IBM) <ritesh.list@gmail.com>]

Andrew Morton <akpm@linux-foundation.org> writes:

> On Sat, 24 Oct 2026 19:25:55 +0800 Muchun Song <songmuchun@bytedance.com> 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) <ritesh.list@gmail.com>
> Closes: https://lore.kernel.org/wlrkqqvg.ritesh.list@gmail.com

I think, the fix for the issue (the one that I reported) is a different
patch [1]. And I did give my tested by there.

[1]: https://lore.kernel.org/all/20261016054914.2601510-1-songmuchun@bytedance.com/

>
> I don't believe that Ritesh has tested this?  He wasn't cc'ed...

Nopes, I haven't.
But I am looking into another open issue on Power which this series
exposes. So while at it, I can test this as well.

Thanks for the cc'

-ritesh