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

On Mon, Aug 10, 2026 at 10:49:16AM +0100, Kiryl Shutsemau wrote:
> On Fri, Aug 07, 2026 at 07:05:09AM -0700, Breno Leitao wrote:
> > diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
> > index dc770b9a6d053..e097e980b1439 100644
> > --- a/kernel/kexec_core.c
> > +++ b/kernel/kexec_core.c
> > @@ -212,6 +212,16 @@ int sanity_check_segment_list(struct kimage *image)
> >  	}
> >  #endif
> >  
> > +	/*
> > +	 * Reject destinations that land on hardware-poisoned memory: the
> > +	 * relocation copy would machine-check on the bad frame.
> > +	 */
> > +	for (i = 0; i < nr_segments; i++) {
> > +		if (range_first_hwpoison(image->segment[i].mem,
> > +					 image->segment[i].memsz) != PHYS_ADDR_MAX)
> > +			return -EADDRNOTAVAIL;
> 
> Other -EADDRNOTAVAIL usage indicate error on user side. But this is not
> a user fault. Maybe -EHWPOISON instead.

Ack!

> > +		if (!PageHWPoison(page))
> > +			/* page is good, let's go to the next one */
> > +			continue;
> 
> If you don't care about re-using clean part of poisoned hugetlb folio,
> use is_page_hwpoison(page).
> 
> This would do:
> 
> 		if (!page || !is_page_hwpoison(page))
> 			continue;
> 
> You would spin a bit on the same folio, but shouldn't be a big deal.

right, it will spin a bit more when there is a poisoned page in the
hugetlbfs folio, but it keep the code simpler, which might be a good
trade-off.

Let me update it and respin,
--breno