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

[Lorenzo Stoakes (ARM)]

On Thu, Jul 30, 2026 at 02:10:23PM +0200, David Hildenbrand (Arm) wrote:
> 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.

Yeah exactly. Also setting an absolute value in general is potentially
problematic.

>
> --
> Cheers,
>
> David

Cheers, Lorenzo