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

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

On 9/23/26 16:36, Harry Yoo wrote:
> On Wed, Sep 23, 2026 at 03:37:14PM +0200, David Hildenbrand (Arm) wrote:
>> On 9/23/26 14:57, Harry Yoo wrote:
>>>
>>> [+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.

My naive design would be:

1) Teach memblock early about poisoned memory ranges. Don't let it hand them out.

2) Memblock will naturally skip them when freeing pages to the buddy. No need to
hook bitmap scans into other code path.

3) Teach memblock to hwpoison the memmap.

4) Don't update memblock (ARCH_KEEP_MEMBLOCK) when poisoning occurs later during
boot. Any hwpoison happening after boot will be reflected in the memmap (+
synced to the bitmap).


What you are describing is "how to keep kexec from placing data on hwpoisoned
ranges". If we want to avoid scanning a bitmap (which I really think we want to
avoid), the memmap is our ultimate source of truth for hwpoisoned. I would just
consult that. (that's likely what v2 did?)

One complication might be that a single hwpoisoned page is represented as a
bigger chunk in the bitmap. So we might place kexec data on healthy pages within
a poisoned (per bitmap) block. That's fine (pages are healthy after all), we
just have to teach the new kernel to deal with that.

> 
>> 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.
Yes. I think it's fine to update the bitmap passively through some callback
mechanism from hwpoison code.

-- 
Cheers,

David