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

[Harry Yoo <harry@kernel.org>]

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.

> We might even want to be bold and discuss a holistic design overhaul if
> it's warranted.
> 
> If anybody has ideas for future topics, please let me know and I'll try to 
> organize them.  We'd love to have volunteers to lead future topics as well 
> as requests for MM topics to be presented.
> 
> Looking forward to seeing all of you on Wednesday!
> 
> Time zones
> 
> PDT (UTC-7)		9:00am
> MDT (UTC-6)		10:00am
> CDT (UTC-5)		11:00am
> EDT (UTC-4)		12:00pm
> Rio de Janeiro (UTC-3)	1:00pm
> London (UTC+1)		5:00pm
> Berlin (UTC+2)		6:00pm
> Moscow (UTC+3)		7:00pm
> Dubai (UTC+4)		8:00pm
> Mumbai (UTC+5:30)	9:30pm
> Singapore (UTC+8)	12:00am Thursday
> Beijing (UTC+8)		12:00am Thursday
> Tokyo (UTC+9)		1:00am Thursday
> Sydney (UTC+10)		2:00am Thursday
> Auckland (UTC+12)	4:00am Thursday

-- 
Cheers,
Harry / Hyeonggon