mm/hwpoison: persist poisoned PFN list across kexec via KHO [RFC]

[Pratyush Yadav]

On Wed, Jun 24 2026, Kiryl Shutsemau wrote:

> On Wed, Jun 24, 2026 at 03:39:38AM -0700, Breno Leitao wrote:
>>   * Consumer: early in the next boot (fs_initcall_sync, before the
>>     buddy allocator has handed anything out) it restores that array
>>     and re-runs memory_failure() on each PFN, re-offlining the frame
>>     and rebuilding the full hwpoison state (PG_hwpoison, counters,
>>     HardwareCorrupted).
>
> fs_initcall_sync is not before buddy hands anything out - buddy has been
> live since memblock_free_all() in start_kernel(), and every initcall before
> this one has allocated freely. So this is recovery, not prevention: you may
> be running memory_failure() against a frame already in use, possibly by a
> kernel allocation.
>
> Two windows are missed entirely:
>
>   - memblock allocations between setup_arch() and memblock_free_all()
>     (page tables, mem_map[], percpu) can land on the bad frame.
>
>   - The kernel image itself: KASLR picks its location in the
>     decompressor/stub, long before any initcall. The next kernel can end
>     up running *on* the bad frame.

With KHO, you have "scratch memory", a pre-reserved area of memory on
cold boot. The kernel image is always in this area when KHO is used. I
think it would be a fair idea to deny kexec if any of the pages in this
scratch area are poisoned. Because at that point you can't reliably boot
anyway.

Normally, all allocations between setup_arch() and memblock_free_all()
_also_ happen from scratch memory, so this check would solve the first
problem too... but I recently added patches [0] to change this. So I
think we do need to identify the poisoned pages early in boot.

[0] https://lore.kernel.org/kexec/20260605183501.3884950-16-pratyush@kernel.org/

[...]

-- 
Regards,
Pratyush Yadav