Re: [PATCH] kexec: keep the next kernel off hardware-poisoned pages

[Breno Leitao]

On Wed, Jul 29, 2026 at 01:57:01PM +0200, Pratyush Yadav wrote:
> On Tue, Jul 28 2026, Breno Leitao wrote:
> 
> > Memory failures (such as unrecoverable ECCs errors) are getting more and
> > more common. The kernel knows how to handle it while running, marking it
> > as poisoned (and SIGBUS user tasks).
> >
> > Poisoned memory is removed from the buddy allocator, but, not from
> > other places. A current problem is that kexec will load new kernel
> > on top of a bad/poisoned memory, which is undesirable.
> >
> > If the next kernel's image, initrd or purgatory lands on poisoned frame,
> > the relocation copy writes to the bad memory and the machine checks
> > during the kexec.
> >
> > Skip hardware-poisoned frames when placing segments: check them in the
> > kexec_file hole finder so it lays the next kernel down on good memory,
> > and reject a poisoned destination in sanity_check_segment_list() for
> > the kexec_load path, which cannot relocate.
> 
> kexec_locate_mem_hole() uses kexec_alloc_contig() to try to find a
> contiguous range from CMA. If found, it uses that and skips relocation.
> Do you know if CMA tracks poisoned pages and skips allocating them?
> 
> sanity_check_segment_list() will catch these anyway and error out, but
> would be nice if CMA can track poisoned pages in the first place.
> Anyway, that is out of scope for this patch, but something you might
> want to look into.

Good point, I understand CMA already avoids them: alloc_contig_range()
runs in PB_ISOLATE_MODE_CMA_ALLOC, where a HWPoison page counts as
unmovable, so isolation returns -EBUSY and cma_alloc() routes around it,
no?

> > --- a/kernel/kexec_file.c
> > +++ b/kernel/kexec_file.c
> > @@ -504,6 +504,13 @@ static int locate_mem_hole_top_down(unsigned long start, unsigned long end,
> >  			continue;
> >  		}
> >  
> > +		/* Avoid placing the next kernel on hardware-poisoned memory */
> > +		if (range_contains_hwpoison(temp_start,
> > +					    temp_end - temp_start + 1)) {
> > +			temp_start = temp_start - PAGE_SIZE;
> 
> Sashiko complains about this
> https://sashiko.dev/#/patchset/20260728-kexec_posioned-v1-1-160c81d180fe@xxxxxxxxxx:
> 
>     If we find a hardware-poisoned page within a large segment, does this loop in
>     locate_mem_hole_top_down() cause a CPU soft lockup?
> 
>     Since temp_start is shifted by only PAGE_SIZE, the next iteration will call
>     range_contains_hwpoison() again. As seen in mm/memory-failure.c, that
>     function does a linear scan from the new start address:
> 
>     	for (pfn = PHYS_PFN(start); pfn <= end_pfn; pfn++) {
>     		if (pfn_valid(pfn) && PageHWPoison(pfn_to_page(pfn)))
>     			return true;
>     	}
> 
>     This means we could rescan almost the entire segment over and over until it
>     finally moves past the poisoned page. For a very large segment like a 512MB
>     initrd, this would iterate billions of times without yielding.
> 
>     Could range_contains_hwpoison() return the address of the poisoned page so
>     the hole finder can skip past it efficiently?
> 
> Which does seem to make sense. Same problem below.

Agreed, that could be a real problem. Returning the poisoned page
address from range_contains_hwpoison() would work but feels awkward
for a predicate function.

Let me think through a cleaner approach.

Thanks for the review,
--breno