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

[Kiryl Shutsemau <k.shutemov@gmail.com>]

On Thu, Sep 24, 2026 at 10:32:29AM +0200, David Hildenbrand (Arm) wrote:
> 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.

I suggested using a bitmap because ranges are not scalable. Some memory
failure modes generate errors repeated across the physical address space
(think of a column failure, for instance). It would produce too many
ranges to be viable.

We already consult a bitmap in memblock for unaccepted memory. We *can*
do the same for poisoned memory.

But I am not convinced it is needed for the initial implementation.
Memblock is a small portion of kernel allocations. If we step on broken
memory there, the machine is dead and requires repair. It can be
improved later if the rate is too high.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov