Re: [PATCH v3 0/8] mm: fix allocator races with memory hotplug

[Gregory Price (Meta)]

On 2026-10-28 09:37 +0100, David Hildenbrand (Arm) wrote:
> On 10/21/26 04:39, Gregory Price (Meta) wrote:
> > Eight fixes for allocator paths that can act on state another CPU is
> > updating: zonelists rebuilt by memory hotplug, and the pagesets of a
> > zone that offlining empties.
> > 
> > I've packaged these together because they're all related to hotplug.
> > 
> > *** Backport note - Patches 5-7 build on patch 1: without it, their
> >     retry is compiled out when CONFIG_MEMORY_HOTREMOVE=n.
> > 
> > Most of these race conditions stem from zonelists being re-ordered
> > in-place at runtime during hotplug.  The result is a mixture of failed
> > allocations, NULL dereferences, incorrect placement (GFP_KERNEL in
> > ZONE_MOVABLE), node misplacement, or incorrectly allowing hugetlb /
> > contig allocations on a node/zone otherwise not eligible.
> > 
> > Most of these are incredibly narrow race conditions, but since the most
> > likely impacted machines are VMs with memory hotplug, the narrow
> > condition can more easily occur when a vCPU takes a long interrupt / VM
> > exit of some kind.  I've made all of these race conditions
> > deterministics with a kprobe reproduction module described below.
> 
> What's the status of this? "memory hotplug" caught my attention, but then then
> is all page_alloc material :)
> 

I have a v4 with the requested tweaks and some performance analysis,
though i think there is some overlap with the other Fixes: series.

I can send it out and if it helps i can pull together a report on
overlap between the different Fixes: series.

~Gregory

-- 
~Gregory