Re: [PATCH v4 2/5] mm/memory-failure: libstub: install the poisoned-memory EFI table

[Harry Yoo <harry@kernel.org>]

On Tue, Sep 15, 2026 at 02:03:48AM -0700, Breno Leitao wrote:
> On Thu, Sep 10, 2026 at 06:11:53AM -0700, Breno Leitao wrote:
> > So I'd say we have two options:
> >
> > 1) Keep it similar to unaccepted memory, with 2M granularity.
> >    - Pro : Similar mental model as unnacepted memory
> >    - Cons: 2 MB might be a bit wasteful
> >
> > 2) Move to a linked list like the RFC, keeping it outside of the EFI
> >    table.
> >    - Pro: Reduce the memory granularities to page instead of 2M blocs.
> >    - Cons: Another way of passing memory information between kexec
> >      kernels.
> >
> > Any any other option or strong preference?
> 
> Since nobody voiced a strong preference, I will stick with option (1),
> the bitmap, for these reasons:

Not sure if this was discussed already, but perhaps we need to have
a chain of struct linux_efi_poisoned_memory rather than a single
bitmap, to easily add support for hot-added memory later?

Also, I wonder if some architectures have a scattered set of pfn
ranges so that the span from the start pfn to the end pfn being much
larger than the actual physical memory size.

If so it might make more sense to have a bitmap for each pfn range.

-- 
Cheers,
Harry / Hyeonggon

> 1) It follows the same mental model as unaccepted memory, which people
>    are already familiar with.
> 
> 2) It is simpler to query at boot time, especially as the number of
>    poisoned memory regions grows. Walking a bitmap is easier than
>    walking a linked list when freeing memory back to the buddy
>    allocator.