Re: [PATCH v6 0/5] Only free healthy pages in high-order has_hwpoisoned folio

[Matthew Wilcox]

On Mon, Jul 27, 2026 at 04:20:54PM +0200, David Hildenbrand (Arm) wrote:
> >> Just adding a comment about this aspect:
> >> The check_new_pages() mechanism used by the __rmqueue functions should
> >> filter these pages out, but this has been disabled by default in 2023
> >> with:
> >> [PATCH] mm, page_alloc: reduce page alloc/free sanity checks
> >> https://lore.kernel.org/all/20230216095131.17336-1-vbabka@xxxxxxx
> >>
> >> So it would need to be enabled back, taking some of the performance hit.
> >> (and I personally think that it has to be done)
> > 
> > Would it truly fix the issue, or rather there would still be a race window
> > left where we check that there's no hwpoison flag in the re-enabled check,
> > and only then someone sets it?
> 
> Why are we checking PageHWPoison at all then in check_new_page()?
> 
> I think we created a mess.
> 
> The PageHWPoison check is not just a "nice to have" sanity check for kernel bugs.
> 
> So it should never have been optimized out that way before reworking the bigger
> picture.

There's A Lot Going On (and I don't think I understand it all yet).
We can soft-poison pages while they're in Buddy, for example.
And then soft-unpoison them again.  Is it handled properly?  I doubt
it.  Looks to me like it's full of races.

> > Also, can the hardware actually detect a problem with a page that nobody
> > accesses? I guess if yes, it's only in some corner cases.
> 
> Yes, quite frequently I think.
> 
> > 
> > So I'm wary about penalizing the allocator paths again.
> 
> I get the feeling that we don't have a proper plan on how to handle HWPoisoned
> pages. We should take a step back and discuss how we actually want to handle
> them instead of optimizing here and there and creating more of a mess.

I feel like there's a general lack of understanding of how hwpoison
works amongst those of us who work on the core of memory handling,
and the memory-failure code has not been kept up to date with how we
think about page/folio/memdesc handling.  It might be good to have a
BOF at Plumbers to share our (mis)understandings of how all of this
works yesterday/today/tomorrow.