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

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

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? :)

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

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 :)

>
> --
> Cheers,
>
> David

Thanks, Lorenzo