[PATCH v2 6/6] efi: respect the poisoned pages coming from previous kernel
Breno Leitao
leitao at debian.org
Fri Aug 21 07:03:06 PDT 2026
On Fri, Aug 21, 2026 at 01:13:55PM +0100, Kiryl Shutsemau wrote:
> On Fri, Aug 21, 2026 at 03:06:06AM -0700, Breno Leitao wrote:
> > + /* Reserve the table itself so it survives a further kexec. */
> > + memblock_reserve(PAGE_ALIGN_DOWN(ppm),
> > + PAGE_ALIGN(ppm + sizeof(*pm) + bitmap_size) -
> > + PAGE_ALIGN_DOWN(ppm));
>
> Hm. I don't think it is enough.
>
> On x86, kernel doesn't keep memblock around after boot (see
> CONFIG_ARCH_KEEP_MEMBLOCK). Reserving in memblock exclude the memory
> from page allocator. But kexec can place the image there.
You mean the third kexec?
1) Kernel A hits an ECC error and marks page X poisoned.
2) Kernel A kexecs into kernel B, which won't use that page since
it's in EFI_POISONED_PAGE and memblock-reserved.
3) Kernel B kexecs into kernel C, which doesn't respect
EFI_POISONED_PAGE.
Is this the scenario you mean?
If so, the config table, once installed, persists forever, right?
So kernel C will see the poisoned pages, but could still step into
one during the kexec itself?
> For !CONFIG_ARCH_KEEP_MEMBLOCK, kexec uses walk_system_ram_res() that
> looks into iomem_resource. And memblock does nothing to exclude the
> memory from iomem_resource.
Maybe we need something similar to "efi: mm/memory-failure: keep
hardware-poisoned pages out of the next kexec"[1], but checking
EFI_POISONED_PAGE instead?
Link: https://lore.kernel.org/all/20260812-kexec_posioned-v6-0-e477887086f0@debian.org/ [1]
Thanks for the review,
--breno
More information about the kexec
mailing list