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

[Breno Leitao <leitao@debian.org>]

On Tue, Sep 15, 2026 at 02:31:38PM +0100, Harry Yoo wrote:
> On Tue, Sep 15, 2026 at 05:39:44AM -0700, Breno Leitao wrote:
> > > 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.
> >
> > Agreed, having a ->next in linux_efi_poisoned_memory is a good idea that
> > we can lean on depending on whatever problem comes up down the road.
> >
> > Very good point — let's keep this linux_efi_poisoned_memory chain idea in
> > mind for whenever we need to expand it.
>
> You mean 1) keeping the structure as-is for now (and expand later with
> new EFI table version) or 2) adjusting the structure in the future
> revision of this patchset?

I'd say option (1): keep the structure as it is for now, and only adjust
it once/if we actually decide to implement the hot-add use case.

That's exactly why I added the "u32 version" field to
struct linux_efi_poisoned_memory, so, it can be expanded later.

Version 1 (this patchset) covers the common, basic approach. If down the
road someone sees value in extending it to other use cases (such as
hot-plug), we can bump it to v2 and add a ->next field then.

What do you think?

Thanks for the review,
--breno