On Tue, Sep 22, 2026 at 01:33:51PM +0200, David Hildenbrand (Arm) wrote: > On 9/21/26 16:31, Breno Leitao wrote: > > On Fri, Sep 18, 2026 at 10:16:25PM +0200, David Hildenbrand (Arm) wrote: > >> On 9/18/26 17:22, Breno Leitao wrote: > >>> > >>> Right, we have two source for poisoned page information, today. > >>> > >>> 1) LINUX_EFI_POISONED_MEMORY: Used to track memory block that got > >>> poisioned, and will be passed around during kexec. > >>> 2) PG_hwpoison on struct page: Used by the memory subsystem to avoid > >>> touching it. > >> > >> How are both kept in sync? See below. > > > > The EFI table is only written when there is a memory failure. That is > > the only thing that writes to it: > > > > action_result() -> efi_hwpoison_record_pfn() -> set_bit() > > > > You can see it on patch "mm/memory-failure: efi: record > > hardware-poisoned frames into the poisoned-memory table" > > > > Then, when the kernel kexecs into a second kernel, the EFI config table > > is queried and the pages are poisoned from it at boot, as they are > > getting into the buddy allocator, in __free_pages_core(). > > I am not sure that is really the right place. That means we only poison free > memory. Shouldn't we poison as soon as we initialize the memmap, and check > whether any memblock allocations ended up on that poisoned memory and bail > out?
__free_pages_core() is how we hand over pages from memblock to page allocator initially -- from memblock_free_pages(), deferred_free_pages() and hotplug. It is the right place to never allow them on free lists. -- Kiryl Shutsemau / Kirill A. Shutemov
