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

[Pratyush Yadav]

On Tue, Aug 11 2026, Breno Leitao wrote:

> On Mon, Aug 10, 2026 at 07:32:41PM +0300, Mike Rapoport wrote:
>> Hi Breno,
>> 
>> On Mon, Aug 10, 2026 at 06:32:04AM -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. 
>
> 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();
>

Now that we are looking at this, Sashiko also complains about a race
with memory hotunplug.

    Can the page pointer become invalid here due to concurrent memory hotplug?

    The loop retrieves the struct page pointer using pfn_to_online_page() and
    then yields the CPU with cond_resched(). Since this iteration runs without
    holding get_online_mems(), could a concurrent memory hot-unplug event offline
    and remove the memory section while the thread is sleeping?

    If the vmemmap backing the struct page is freed and its page tables torn
    down, dereferencing the pointer in is_page_hwpoison(page) upon waking
    could cause a use-after-free regression.

Kind of makes sense at first glance but I didn't go and look. Perhaps it
is better to do the cond_resched() at the end of the loop?

-- 
Regards,
Pratyush Yadav