Re: [PATCH] mm: fix the race on huge alloc failed

From: Guilherme Giacomo Simoes

Date: Sat Aug 29 2026 - 14:03:02 EST


Matthew Wilcox <willy@xxxxxxxxxxxxx> wrotes:
>> Fixes: 164b06f238b9 ("mm: call wp_page_copy() under the VMA lock")
>
> what makes you think this is the right commit for fixes?
Maybe I would should analyzed this better. I only seed the commit that introduce
this function (and consequently this reader)

>> The race occurs because the reader (__vmf_anon_prepare()) checks
>> `vma->anon->vma` without holding the mmap_lock and withou the
>> READ_ONCE() macro. Since the writer (__anon_vma_prepare()) is holding the
>> mmap_lock and updating the pointer, it creates a data race as the two
>> access are not properly synchronized.
>
> also this explanation is bogus. i don't have time to fix it right now.
Hmm... I would like to say that the reader (__vmf_anon_prepare) access the same
data that the writer (__anon_vma_prepare()), lead to a race condition problem.

When the huge page alloc failed, the asm_exc_page_fault interrupt is fired but
on the same time the procces that was trying to alloc the huge page, try handle
to this failed too..

How READ_ONCE() and WRITE_ONCE() is atomic, the race problem can be resolved.

Thanks,
Guilherme