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

["David Hildenbrand (Arm)" <david@kernel.org>]

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

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

-- 
Cheers,

David