Re: [PATCH 0/6] mm: fix pfn walker races with memory offline

[Gregory Price (Meta)]

On 2026-10-27 09:57 +0100, David Hildenbrand (Arm) wrote:
> On 10/27/26 05:21, Gregory Price (Meta) wrote:
> > Several pfn walkers check that a struct page is online, then use it
> > after memory offline has poisoned it (CONFIG_DEBUG_VM) or removal has
> > freed the vmemmap.  Five of the races crash the kernel; the sixth leaves
> > an offline spinning with the device hotplug lock held.
> 
> I have roughly the exact same list of AI garbage fixes here from a certain company.
> 
> And I consider this all extremely low priority.
> 
> So this is something to discuss throughout the next months and do it properly.
> 

I actually have a reason for these fixes other than "bot said bad".

We leverage ballooning and hotplugging as VM memory overcommit tools
and are finding that some of these race conditions crash them with
large MTBF.

While most of these are insanely narrow, they are not as unlikely to
happen as you think. A vCPU can take a vmexit in these windows much
more easily than a host can take an NMI or other interrupt.

Thankfully none of these (or the other series) appear to be obvious
security issues, but they are stability issues.

I have a reproducer for every single one of these (and the other
series) - but a handful are unreachable due to a 2-statement read
being emitted as a single read by the compiler (which can be undone
by a targeted compiler flag). Those were included for completeness.

--

On properly - I have a follow up series that fixes the zonelist walks
structurally, but it uses SRCU-fast on the fast path. The catch is that
PowerPC (and i think others?) don't SRCU-fast without atomics, so they
take a performance hit.  (It also doesn't help us for backports)

I've been weighing that solution over never freeing and/or prepopulating
zones - but this also results in performance impacts (leaving dead zones
in the list forces the allocator to walk them for no value).

-- 
~Gregory