Re: [PATCH v6 1/2] kho: fix deferred init of kho scratch

[Pratyush Yadav <pratyush@kernel.org>]

Hi Michal,

On Wed, Mar 11 2026, Michal Clapinski wrote:

> Currently, if DEFERRED is enabled, kho_release_scratch will initialize
> the struct pages and set migratetype of kho scratch. Unless the whole
> scratch fit below first_deferred_pfn, some of that will be overwritten
> either by deferred_init_pages or memmap_init_reserved_pages.
>
> To fix it, I initialize kho scratch early and modify every other
> path to leave the scratch alone.
>
> In detail:
> 1. Modify deferred_init_memmap_chunk to not initialize kho
> scratch, since we already did that. Then, modify deferred_free_pages
> to not set the migratetype. Also modify reserve_bootmem_region to skip
> initializing kho scratch.
>
> 2. Since kho scratch is now not initialized by any other code, we have
> to initialize it ourselves also on cold boot. On cold boot memblock
> doesn't mark scratch as scratch, so we also have to modify the
> initialization function to not use memblock regions.
>
> Signed-off-by: Michal Clapinski <mclapinski@google.com>

I haven't had the time to carefully review this yet, but sharing some
high level thoughts.

IIUC the real problem isn't struct page initialization, but the fact
that if the page is at a pageblock boundary its migrate type is not
correctly set to MIGRATE_CMA. So you fix the problem by making sure no
one else but KHO can initialize the scratch pages.

I think the end result makes the already complicated page initialization
sequence even more complicated. I tried to grok that patch and it makes
my brain hurt.

Can we get away with something simpler? Here's an idea: keep the struct
page init the same as it is now, just modify
init_pageblock_migratetype() to override the migrate type if page lands
in scratch. It already does something similar with MIGRATE_PCPTYPES:

	if (unlikely(page_group_by_mobility_disabled &&
		     migratetype < MIGRATE_PCPTYPES))
		migratetype = MIGRATE_UNMOVABLE;

So we can also add:

	/*
	 * Scratch pages are always MIGRATE_CMA since they can't contain
	 * unmovable allocations.
	 */
	if (unlikely(pfn_is_kho_scratch(page_to_pfn(page))))
		migratetype = MIGRATE_CMA;

Do you think this will work? If yes, then I think it is a lot nicer than
what this patch is doing.

Also, pfn_is_kho_scratch() is pretty much a duplicate of
kho_scratch_overlap(). Please pull kho_scratch_overlap() out of
kexec_handover_debug.c and use that instead.

> ---
> My previous idea of marking scratch as CMA late, after deferred struct
> page init was done, was bad since allocations can be made before that
> and if they land in kho scratch, they become unpreservable.
> Such was the case with iommu page tables.
[...]

-- 
Regards,
Pratyush Yadav