Re: [PATCH v5 7/9] drivers/base/memory: count inherited poisoned frames into the block

[Harry Yoo <harry@kernel.org>]

On Tue, Sep 22, 2026 at 01:51:08PM +0100, Kiryl Shutsemau wrote:
> 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.

One limitation with that is that (as David mentioned)

by poisoning memory when freeing memory from memblock to the buddy,
the kernel might end up allocating the bad memory from memblock
during the early boot process. I don't think we have a functionality
to poison memory in memblock.

Hmm, will it be a problem if we just reserve area memblock....?
Well, that was the case in v2!
https://lore.kernel.org/all/aohldTtzE2GJ76md@thinkstation

IIUC the problem there was: when the architecture does not keep memblock
metadata, nothing prevents kexec from allocating memory from the
reserved space.

So, what should we do know? Reserve the poisoned areas in memblock AND
free those reserved spaces to the buddy to pass poison information? ;-)

-- 
Cheers,
Harry / Hyeonggon