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

[Lance Yang <lance.yang@linux.dev>]

On Sat, Aug 29, 2026 at 03:02:34PM -0300, Guilherme Giacomo Simoes wrote:
>Matthew Wilcox <willy@infradead.org> 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.

This patch should make KCSAN happy, IIUC, BUT ...

Still, the subject and changelog are rather confusing. The race is on
vma->anon_vma, not on a failed huge page allocation. READ_ONCE() and
WRITE_ONCE() do not stop the two faults from racing. They just tell
KCSAN that these concurrent accesses are intentional ... no?

Cheers, Lance