linux-kernel - Re: [PATCH v3 2/3] mm/page_alloc: only free healthy pages in high-order has

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CACw3F50WiPm-N4Bwh7=L5P6s1trpK75wZFTLKMYAEAJPbjwtHQ@mail.gmail.com>
Date: Fri, 23 Jan 2026 21:32:56 -0800
From: Jiaqi Yan <jiaqiyan@...gle.com>
To: "David Hildenbrand (Red Hat)" <david@...nel.org>, linmiaohe@...wei.com, ziy@...dia.com, 
	harry.yoo@...cle.com, william.roche@...cle.com
Cc: jackmanb@...gle.com, hannes@...xchg.org, willy@...radead.org, 
	nao.horiguchi@...il.com, lorenzo.stoakes@...cle.com, tony.luck@...el.com, 
	wangkefeng.wang@...wei.com, jane.chu@...cle.com, akpm@...ux-foundation.org, 
	osalvador@...e.de, muchun.song@...ux.dev, rientjes@...gle.com, 
	duenwen@...gle.com, jthoughton@...gle.com, linux-mm@...ck.org, 
	linux-kernel@...r.kernel.org, Liam.Howlett@...cle.com, vbabka@...e.cz, 
	rppt@...nel.org, surenb@...gle.com, mhocko@...e.com
Subject: Re: [PATCH v3 2/3] mm/page_alloc: only free healthy pages in
 high-order has_hwpoisoned folio

Sorry for the late reply, Harry, Zi, Miaohe, and David. I was occupied
by some other duty in the past two weeks.

On Thu, Jan 15, 2026 at 12:43 PM David Hildenbrand (Red Hat)
<david@...nel.org> wrote:
>
> On 1/12/26 01:49, Jiaqi Yan wrote:
> > At the end of dissolve_free_hugetlb_folio(), a free HugeTLB folio
> > becomes non-HugeTLB, and it is released to buddy allocator
> > as a high-order folio, e.g. a folio that contains 262144 pages
> > if the folio was a 1G HugeTLB hugepage.
> >
> > This is problematic if the HugeTLB hugepage contained HWPoison
> > subpages. In that case, since buddy allocator does not check
> > HWPoison for non-zero-order folio, the raw HWPoison page can
> > be given out with its buddy page and be re-used by either
> > kernel or userspace.
>
>
> Do we really have to have all that complexity in free_frozen_pages().
>
> Can't we hook into __update_and_free_hugetlb_folio() and just free the
> chunks there?

I don't know but I imagine to get chunks you will need the ability to
split a in-use (not free_huge_folio()-ed) hugetlb folio like splitting
a THP folio? Won't that be more complicated and very specific to
hugetlb? This solution is implemented in free_frozen_pages() to avoid
heavylifing splitting.

Also, doing in __update_and_free_hugetlb_folio() definitely won't help
with [1]: to handle a previously split-failed and now to be freed
PG_has_hwpoisoned THP. This solution works.

[1] https://lore.kernel.org/linux-mm/CACw3F529=PC-pwXOX0gbNrnS7HTwXq93oVT=V74J4FHLqcZ-ug@mail.gmail.com/T/#m202f91883b9b70c0346c3076db5b341d02d3f348

>
> >
> > Memory failure recovery (MFR) in kernel does attempt to take
> > raw HWPoison page off buddy allocator after
> > dissolve_free_hugetlb_folio(). However, there is always a time
> > window between dissolve_free_hugetlb_folio() frees a HWPoison
> > high-order folio to buddy allocator and MFR takes HWPoison
> > raw page off buddy allocator.
>
> I wonder whether marking the pageblock as isolated before freeing it
> could work?

Maybe... but where can the pageblock be isolated? Is there an existing
candidate, or inventing a scribble pad to stash it?

And then who and when should un-isolate the pageblock, if we don't
want to leak it?

>
> In that case, nobody will be able to allocate the page before we
> un-isolate it.
>
> Just a thought: but when you are dealing with a possible race, you can
> avoid that race by prohibiting the intermediate allocation from
> happening in the first place.
>
>
> Also, this is a lot of complexity. Was this issue already hit in the
> past or is it purely theoretical?

Theoretical for now. But when I work on [2] with William and Harry,
the issue can be reproduced fairly easily [3].

[2] https://lore.kernel.org/linux-mm/20251116013223.1557158-3-jiaqiyan@google.com/T/#m87c95ddf0b9397b409a9f8fac4e772ecc9abf209
[3] https://lore.kernel.org/linux-mm/20250919155832.1084091-1-william.roche@oracle.com


>
> --
> Cheers
>
> David