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

[Kiryl Shutsemau]

On Tue, Aug 11, 2026 at 04:34:02PM +0300, Mike Rapoport wrote:
> On Tue, Aug 11, 2026 at 04:17:41AM -0700, Breno Leitao wrote:
> > > > +	for (pfn = PHYS_PFN(start); pfn <= end_pfn; pfn++) {
> > > > +
> > > > +		cond_resched();
> > > 
> > > cond_resched() for every pfn is too much, isn't it?
> > 
> > It is what the other pfn walkers do: the kpageflags read loop in
> > fs/proc/page.c and read_page_owner() in mm/page_owner.c both call it
> > once per pfn. 
> 
> I think it depends on the pfn walker, some of them cond_resched() once per
> "block"
>  
> > But I honestly don't have a strong opinion here, though, happy to batch
> > it if you prefer. Would this one look better?:
> > 
> > 	if (!(pfn % MAX_ORDER_NR_PAGES))
> > 		cond_resched();
> 
> Can't say I know the magic number here, but I think it's better to batch.

Hm. I thought cond_resched() deal with this internally, no?

We call it in pretty tight loops, like clear_contig_highpages() or
copy_folio_from_user().

I think adding external batching might be a bad move.

If calling cond_resched() often is a problem, something is wrong with
cond_resched().

-- 
  Kiryl Shutsemau / Kirill A. Shutemov