Andrew Morton <[email protected]> writes: > 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 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/[email protected]/ > > 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
