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

[David Hildenbrand (Arm)]

On 7/30/26 11:55, Lorenzo Stoakes (ARM) wrote:
> On Thu, Jul 30, 2026 at 11:22:09AM +0200, David Hildenbrand (Arm) wrote:
>> [...]
>>
>>> So invariants are required - huge_zero_refcount MUST:
>>>
>>> * Only be set in the huge_zero_lock critical section to ensure
>>>   serialisation of huge_zero_pfn, huge_zero_folio and huge_zero_refcount
>>>   writes.
>>>
>>> * Be set non-zero only AFTER huge_zero_[pfn, folio] are set to valid values
>>>   so installation of the huge zero folio on read page fault ensures
>>>   concurrent is_huge_zero_*() calls correctly identify the huge zero folio.
>>>
>>> * Be set zero only BEFORE huge_zero_[pfn, folio] are set to NULL and ~0UL
>>>   respectively, and atomically.
>>>
>>> Establish these by:
>>>
>>> * Only updating huge_zero_refcount in the huge_zero_lock critical section
>>>   in get_huge_zero_folio() and shrink_huge_zero_folio_scan().
>>
>> That is imprecise. huge_zero_refcount is updated (incremented) outside of
>> huge_zero_lock in get_huge_zero_folio().
> 
> You're right.
> 
> ->
> 
> * Only setting huge_zero_refcount to zero or an absolute value in the
>   huge_zero_lock critical section in get_huge_zero_folio() and
>   shrink_huge_zero_folio_scan() and updating atomically elsewhere.
> 
> Seems better?

Yes, I guess the transition from/to 0 are the problematic bits. Everything else
can just be lockless.

-- 
Cheers,

David