Re: [Invitation] Linux MM Alignment Session on Hwpoison on Wednesday

[Harry Yoo <harry@kernel.org>]

On Wed, Sep 23, 2026 at 03:37:14PM +0200, David Hildenbrand (Arm) wrote:
> On 9/23/26 14:57, Harry Yoo wrote:
> > On Mon, Sep 21, 2026 at 09:26:22AM -0700, David Rientjes wrote:
> >> Hi everybody,
> >>
> >> We host a biweekly series, the Linux MM Alignment Session, on Wednesdays.
> >> We'd like to invite MM developers to attend and will announce the topic
> >> for the next instance on the Monday prior to the next meeting.
> >>
> >> Our next Linux MM Alignment Session is scheduled for Wednesday.  The
> >> details:
> >>
> >> Wednesday, September 23 * 9:00 - 10:00am PDT (UTC-7)
> >> https://meet.google.com/csb-wcds-xya
> >> backup: https://tel.meet/csb-wcds-xya?pin=1301132214803
> >> doc:
> >> https://docs.google.com/document/d/1QQfZFPHa-pGEGf4A06cSqS0jdJwuZ8ro9JU5H0YSUQ0/view
> >>
> >> This week's topic will be Hwpoison, see the discussion in 
> >> https://marc.info/?l=linux-kernel&m=178796007385067&w=2
> >>
> >> No specific agenda other than to gather core MM developers with hwpoison
> >> developers and discuss:
> >>  - where validation should live, esp with regard to the page allocator, or
> >>    strict invariants in the page allocator
> >>    + implications for the fastpath
> >>  - handling for folios of arbitary orders
> >>  - handling partial folio poisoning and split failures
> >>  - race conditions between memory_failure() and concurrent
> >>    alloc/free/compaction
> >>  - soft offline for pages in the pcp lists
> > 
> > [+Cc Breno]
> > 
> > This might be worth some attention:
> > 
> >   [PATCH v5 0/9] mm/memory-failure: keep hardware-poisoned pages out of the next kexec
> >   https://lore.kernel.org/linux-mm/20260915-hwpoison-kho-v5-0-3bc7a57bd503@debian.org/
> > 
> >   - The question: How best can we pass information about poisoned pages
> >     across kexec when the kernel accesses a poisoned page, panics and
> >     calls kexec, so that the next kernel avoids hitting the poisoned
> >     pages again?
> > 
> >     One challenge here is introducing another source (a new EFI bitmap
> >     that represents poisoned memory, in addition to existing
> >     PG_hwpoison) of poisoned pages adds complexity and confusion.
> > 
> >     David Hildenbrand suggested that we should simplify this as much
> >     as possible in a way that we don't have two sources of information
> >     w/ inconsistency between them and using memmap as the only source.
> > 
> >     e.g.) By consuming the EFI bitmap only once when initializing
> >     memmap (to propagate poison information to not just free pages
> >     through __free_pages_core(), but to the all pages on memmap).
> > 
> >     Another challenge here is that we don't have functionality
> >     to poison pages early in the boot process before memmap and buddy
> >     are ready. So any allocation before initializing them might still
> >     allocate poisoned pages.
> 
> I've been thinking some more (and will reply in detail to the series), but I do
> wonder whether memblock should actually be thought about poisoned ranges and
> refuse to hand them out (reserved/allocated).

I believe this is what the patchset actually did in v2.

That way we'll have to either
1) make any architecture that supports kexec select ARCH_KEEP_MEMBLOCK,
or 2) make kexec scan the bitmap when allocating the memory.

> So we'd use the bitmap only to feed memblock, but not for anything else later
> (if possible).

We can try not to use it for anything later, but still we'd have to
pass a proper bitmap (through the EFI table) to the next kernel.
At least the kernel should update the bitmap for newly poisoned pages
at some point.

-- 
Cheers,
Harry / Hyeonggon