Re: [PATCH v5 3/9] mm/memory-failure: libstub: install the poisoned-memory EFI table

[Breno Leitao <leitao@debian.org>]

Hello Usama,

On Wed, Sep 16, 2026 at 08:39:53AM -0700, Usama Arif wrote:
> On Tue, 15 Sep 2026 05:53:37 -0700 Breno Leitao <leitao@debian.org> wrote:
> > +static efi_status_t efi_get_ram_range(u64 *base, u64 *top)
> > +{
> > +	struct efi_boot_memmap *map __free(efi_pool) = NULL;
> > +	u64 ram_base = ULLONG_MAX, ram_top = 0;
> > +	efi_status_t status;
> > +	int i, nr_desc;
> > +
> > +	status = efi_get_memory_map(&map, false);
> > +	if (status != EFI_SUCCESS)
> > +		return status;
> > +
> > +	nr_desc = map->map_size / map->desc_size;
> > +	for (i = 0; i < nr_desc; i++) {
> > +		efi_memory_desc_t *d;
> > +
> > +		d = efi_memdesc_ptr((unsigned long)map->map, map->desc_size, i);
> > +		if (!(d->attribute & EFI_MEMORY_WB) &&
> > +		    d->type != EFI_UNACCEPTED_MEMORY)
> > +			continue;
> > +		ram_base = min(ram_base, d->phys_addr);
> 
> Can this use the architecture's full RAM predicate?  On x86,
> setup_e820() maps EFI_LOADER_CODE, EFI_LOADER_DATA, both boot-services
> types, and EFI_CONVENTIONAL_MEMORY as E820_TYPE_RAM without requiring
> EFI_MEMORY_WB.
> 
> If a non-WB descriptor is at either end of RAM, this code omits it
> from the bitmap span.  efi_hwpoison_record_pfn() then rejects a
> poisoned PFN there, so the next kernel can allocate the bad frame.
> 
> One possible way to preserve the x86 behavior before applying the WB rule is:
> 
>     if (IS_ENABLED(CONFIG_X86) &&
>         (d->type == EFI_LOADER_CODE ||
>          d->type == EFI_LOADER_DATA ||
>          d->type == EFI_BOOT_SERVICES_CODE ||
>          d->type == EFI_BOOT_SERVICES_DATA ||
>          d->type == EFI_CONVENTIONAL_MEMORY))
>             goto include;
>     if (!(d->attribute & EFI_MEMORY_WB) &&
>         d->type != EFI_UNACCEPTED_MEMORY)
>             continue;
> include:
>     ram_base = min(ram_base, 

Sure, I had something similar in v2, but the feedback there was to
simplify this and go coarser, since the real cost is only a few extra
bits in the bitmap, so it wasn't worth the added complexity.

Happy to bring it back if saving those bits is worthwhile.

See the discussion here:
https://lore.kernel.org/all/aogvGXKH2u7JsJiS@thinkstation/

Thanks for the review,
--breno