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/[email protected]/ [...] -- Regards, Pratyush Yadav
