Hello Kiryl, First of all, thanks for the review and topics raised!
On Wed, Jun 24, 2026 at 01:04:19PM +0100, 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. Agreed - that wording was wrong. It is recovery, not prevention, and running memory_failure() against an already-allocated (possibly kernel) frame is the not ideal, but, still better than what we have today. > 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. > > So I don't think this should be a memory_failure() replay. The frames need > to leave the next kernel's view at the memory-map level, before memblock > and KASLR. Agreed, this is the ideal right approach. > > Possible solutions > > ================== > ... > > > > 2. e820 / EFI memory map (E820_TYPE_UNUSABLE). Tempting because the > > frame would simply never become RAM (no allocator race at all). > > But: it is x86-only (no arm64 equivalent in the same mechanism; > > this series is tested on arm64); > > (+Ard. I might get some details around EFI wrong.) > > This isn't accurate, and I think it's the right direction for EFI > platforms. EFI_UNUSABLE_MEMORY is honored on both arches today, no new > consumer code: > > - arm64: reserve_regions() marks non-usable memory nomap. Is it true for non-UEFI arm64 hosts? > - x86: do_add_efi_memmap() maps it to E820_TYPE_UNUSABLE. > > And it closes the KASLR window for free, because the image is only placed in > EFI_CONVENTIONAL_MEMORY on both (x86 process_efi_entries(), arm64 > randomalloc.c). So the bad frame is invisible to both the allocator and > KASLR, which is exactly what fs_initcall_sync can't give you. > > There's also LINUX_EFI_MEMRESERVE (efi_mem_reserve_persistent()) - > cross-arch, reserved pre-buddy in efi_init() - and looks otherwise fine, but > it's parsed too late to keep KASLR off the frame. Thanks, I am wondering if we piggy-back on this EFI_UNUSABLE_MEMORY (or something similar), than we don't need to use KHO at all, basically just marked the page as EFI_UNUSABLE_MEMORY at poison time, and rely on kexec to avoid passing this page forward. Thanks for the discussion, --breno
