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

[Lorenzo Stoakes (ARM)]

On Thu, Jul 30, 2026 at 11:05:49AM +0200, David Hildenbrand (Arm) wrote:
> 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.
...
> >
> > 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

The fix is small and targeted, it's 2/2.

>
> >> 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.
>

Rather than debating I'll just drop that and respin.

>
> --
> Cheers,
>
> David