Re: [PATCH v2 6/6] efi: respect the poisoned pages coming from previous kernel
Breno Leitao <[email protected]>
| Newsgroups | org.kernel.vger.linux-efi,org.infradead.lists.kexec,org.kernel.vger.linux-kernel,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
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/[email protected]/ [1] Thanks for the review, --breno