On Wed, Jun 24 2026, Rik van Riel wrote: > On Wed, 2026-06-24 at 15:40 +0200, Pratyush Yadav wrote: >> >> Also, what happens on cold reboot? If the HW does not remember bad >> pages, won't the kernel be in the same position? How does it know the >> bad pages on a cold boot? > > Some modern server hardware will simply unmap known > bad pages from the physical page map, so they will > not be exposed to the OS after a cold reboot. > > The hardware keeps a log of uncorrectable memory > errors somewhere in memory, for example in the SEL. > >> >> >> > >> > This PoC >> > ======== >> > >> > * Makes hardware-poisoned pages survive a kexec, using KHO (Kexec >> > HandOver) to carry the poison list between kernels. >> > >> > * Producer: hooks num_poisoned_pages_inc()/_sub() - the single >> > chokepoint for every poison/unpoison event - and records each >> > poisoned PFN into a vmalloc array that KHO preserves across the >> > kexec, described by a small versioned "hwpoison" subtree. >> >> More of an implementation detail, but with vmalloc array, what if you >> have too many poisoned pages? >> > > > If a very large amount of memory is broken, you > should probably just repair the hardware.
"large" is relative. On a 2 TiB system, if you have 0.5% of pages poisoned (I have no idea if that number is realistic), you have 10 GiB of memory poisoned, or around 2.6 million pages. To store all their PFNs, you need around 20 MiB of memory. While not too large, it isn't trivial either. I think static data structures like vmalloc are likely not the way to go here especially when we have better things like KHO block or the KHO radix tree. Between those two, what is more efficient largely depends on how many pages you'd typically see poisoned and what their locations tend to be. That I think we can dive deeper into when we take a closer look at the patches. > > Page poisoning is good for localized memory > failures, but not for failures that extend across > much of a memory chip. -- Regards, Pratyush Yadav
