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

[Breno Leitao <leitao@debian.org>]

On Tue, Aug 04, 2026 at 03:36:47PM +0100, Kiryl Shutsemau wrote:
> On Mon, Aug 03, 2026 at 05:41:10AM -0700, Breno Leitao wrote:
> > @@ -504,6 +505,15 @@ static int locate_mem_hole_top_down(unsigned long start, unsigned long end,
> >  			continue;
> >  		}
> >  
> > +		poison = range_last_hwpoison(temp_start, kbuf->memsz);
> > +		if (poison != PHYS_ADDR_MAX) {
> > +			/* we hit a poisoned page */
> > +			if (poison < kbuf->memsz)
> > +				return 0;
> > +			temp_start = poison - kbuf->memsz;
> > +			continue;
> > +		}
> > +
> 
> Hm. Don't we want range_first_hwpoison() for top-down walk? Otherwise
> the end of range would land on poison.

Sure, In this case would have both,  range_last_hwpoison() for
locate_mem_hole_bottom_up() and range_first_hwpoison() for
locate_mem_hole_top_down().

> > +	end_pfn = PHYS_PFN(start + size - 1);
> > +	for (pfn = PHYS_PFN(start); pfn <= end_pfn; pfn++) {
> > +		struct page *page = pfn_to_online_page(pfn);
> > +
> > +		if (page && PageHWPoison(page))
> > +			poison = PFN_PHYS(pfn);
> 
> Oh... I think it will not work for hugetlb pages. It will give
> false-negative.
> 
> We cannot just set the bit hugetlb pages as we don't always have memory
> for tail page -- look at HugeTLB Vmemmap Optimization (HVO). Hugetlb
> uses a trick to encode poison page. See code that uses _hugetlb_hwpoison
> in struct folio.
> 
> I think we need special-case hugetlb here. (One more reminder why I hate
> HugeTLB).

Confirmed -- hugetlb_update_hwpoison() sets the flag on the folio and
keeps the bad subpages on the raw_hwp_list, so a per-pfn scan only sees
the head and misses the tails.

Let me add this special case for our beloved hugeTLB.

Thanks for the review,
--breno