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

[Harry Yoo]

On Tue, Sep 15, 2026 at 06:38:47AM -0700, Breno Leitao wrote:
> 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.

Ack.

> 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?

That will work, no strong opinion here.

-- 
Cheers,
Harry / Hyeonggon