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

[David Hildenbrand (Arm)]

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?

The spinlock+proper ordering should be possible without #1, or am I missing
something important?

-- 
Cheers,

David