Re: [PATCH mm-hotfixes 0/2] mm/huge_memory: fix huge_zero_pfn race

["David Hildenbrand (Arm)" <david@kernel.org>]

On 7/29/26 10:15, Lorenzo Stoakes (ARM) wrote:
> On Tue, Jul 28, 2026 at 09:02:57PM +0200, David Hildenbrand (Arm) wrote:
>> On 7/28/26 14:05, Lorenzo Stoakes (ARM) wrote:
>>> There is a subtle race in the reference-counted huge_zero_folio
>>> implementation.
>>>
>>> The fast path atomic logic fails to account for the fact that the
>>> shrinker (which drops the final huge_zero_refcount pin) can overwrite
>>> huge_zero_pfn with the ~0UL sentinel value in shrink_huge_zero_folio_scan()
>>> after a racing get_huge_zero_folio() installed a valid value there.
>>>
>>> This results in huge_zero_folio being correctly set but huge_zero_pfn being
>>> set incorrectly and thus is_huge_zero_pfn() and consequently
>>> is_huge_zero_pmd() will misidentify the huge zero folio as being an
>>> ordinary THP folio.
>>>
>>> This can result in the huge zero folio being split and otherwise treated
>>> incorrectly.
>>>
>>> The solution to this is very subtle as there is an atomic fast path, and
>>> thus ordering in weakly ordered architectures has to be treated very
>>> carefully.
>>>
>>> As a result, this series first reworks the
>>> CONFIG_PERSISTENT_HUGE_ZERO_FOLIO logic so it is separated from the
>>> refcounted code in order to make the subsequent fix reasonably
>>> understandable.
>>
>> For at least somewhat easier backports, can we reverse the order?
> 
> Since I'm going to be doing the backports can we keep it the same? :)

I enjoy reviewing small targeted fixes (also for backports), so I want to
understand why patch #1 is required at this point.

>> The spinlock+proper ordering should be possible without #1, or am I missing
>> something important?
> 
> It's possible but this way it's a lot easier to deal with and I'd rather keep
> things consistent for stable kernels.

"A lot easier to deal with", can you elaborate?

The shrinker code never runs with the persistent huge zero folio. So that is not
a concern.

So it's about get_huge_zero_folio().

But there, it's simply that concurrent races are impossible.

Please enlighten me.

> 
> I can figure things out for < persistent huge stable kernels. It'll be manual
> work either way.
> 
> (It'd be good to get some review on the actual changes also :)
Sure, will get to it, but I have limited capacity.

And I have more capacity for small targeted fixes :P

-- 
Cheers,

David