Re: [PATCH 2/3] mm/page_ext: support early allocation for SPARSEMEM

[Muchun Song <muchun.song@linux.dev>]

> On Nov 15, 2026, at 14:44, Muchun Song <muchun.song@linux.dev> wrote:
> 
> 
> 
>> On Nov 15, 2026, at 14:23, Chris Down <chris@chrisdown.name> wrote:
>> 
>> Hi Muchun,
> 
> Hi,
> 
>> 
>> This looks good to me in general, I only have a few small things.
> 
> Thanks for taking a look.
> 
>> 
>> Muchun Song writes:
>>> -	/*
>>> -	 * page_owner must be initialized after buddy is ready, and also after
>>> -	 * slab is ready so that stack_depot_init() works properly
>>> -	 */
>>> -	page_ext_init_flatmem_late();
>> 
>> Not a big deal, but this means that on FLATMEM the init callbacks now run
>> after vmalloc_init() rather than straight after kmem_cache_init(). I can't
>> see anything that depends on the old place, but FLATMEM isn't what the
>> patch is about, so it'd be good to say in the changelog that this moves.
> 
> Sure. The new behavior is aligned with the non-FLATMEM case. It should be fine.
> 
>> 
>>> +	if (!slab_is_available()) {
>>> +	addr = memblock_alloc_try_nid(size, PAGE_SIZE, 0,
>>> +				      MEMBLOCK_ALLOC_ACCESSIBLE, nid);
>> 
>> Maybe this should pass __pa(MAX_DMA_ADDRESS) as min_addr, like
>> alloc_node_page_ext() does, so that the tables stay out of ZONE_DMA when
>> there's room elsewhere?
> 
> Make sense.
> 
>> 
>>> +	page = virt_to_page(addr);
>>> +	if (PageReserved(page)) {
>>> +		memmap_boot_pages_add(-nr_pages);
>>> +		kmemleak_free_part_phys(__pa(addr), table_size);
>>> +		free_reserved_area(addr, addr + table_size, -1, "page_ext");
>>> +	return;
>> 
>> free_reserved_area() prints "Freeing page_ext memory" when it's given a
>> name, and this runs once for every section, so offlining a few gigabytes
>> would put dozens of those in the log. I think it should pass NULL instead.
> 
> Good point. I'll pass NULL in v2.
> 
>> 
>> Did you manage to get this branch to run, by the way? KMSAN is the only
> 
> No. I only verified that the KMSCN kernel boots successfully.
> 
>> user of need_early, and from a quick check offlining a memory block on a
>> KMSAN kernel fails with EBUSY, presumably because the metadata pages can't
>> be migrated, so I couldn't exercise it myself.
> 
> I'll exercise this code on this path and report back.

I exercised this branch with a non-KMSAN kernel by temporarily setting
page_owner_ops.need_early = true. Offlining a boot memory block succeeded,
nr_memmap_boot_pages decreased by 576 pages, and the kernel logged:

    Freeing page_ext memory: 2304K

A subsequent kmemleak scan completed without reports or kernel warnings.

I could not exercise the branch with KMSAN enabled. During the
memblock-to-buddy handoff, kmsan_memblock_free_pages() retains the first
two of every three same-order blocks as shadow and origin backing, and
only releases the third block to the buddy allocator. The retained metadata
pages are not migratable. On this x86 setup, every ordinary boot memory
block therefore contains KMSAN metadata pages, and memory offlining fails
with -EBUSY before the MEM_OFFLINE notification is sent. Consequently,
page_ext_callback() never reaches this branch.

Thanks,
Muchun

> 
>> 
>> Once the changelog and the log message are fixed, please feel free to add:
>> 
>> Reviewed-by: Chris Down <chris@chrisdown.name>
> 
> Thanks for your review.
> 
> Muchun
> 
>> 
>> Thanks!
>> 
>> Chris