Re: [PATCH 1/6] mm/sparse-vmemmap: drop VMEMMAP_POPULATE_DAX

[Qi Zheng <qi.zheng@linux.dev>]

On 9/19/26 10:07 PM, Muchun Song wrote:
> 
> 
>> On Sep 19, 2026, at 22:01, Qi Zheng <qi.zheng@linux.dev> wrote:
>> On 9/13/26 4:37 PM, Muchun Song wrote:
>>> VMEMMAP_POPULATE_DAX currently distinguishes DAX vmemmap population in two
>>> places: it keeps allocations on the normal path and takes a reference when
>>> a backing page is supplied for reuse.
>>> After Device DAX switched to the common per-zone shared tail page, both
>>> conditions can be determined locally. DAX supplies ptpfn for every shared
>>> tail mapping and requests an allocation only for compound head mappings,
>>> whose PFNs are not optimizable. Therefore, vmemmap_optimizable_pfn() alone
>>> selects the correct allocation path.
>>> When ptpfn is supplied, the caller is reusing an existing backing page.
>>> Once the slab allocator is available, take a reference for each reused
>>
>> Does the availability of slab mean the buddy allocator is already being
>> used? Could there be a window where the buddy allocator is functional
>> but slab hasn't become available yet?
> 
> Yes, because the slab allocator is based on buddy allocator. But I want to know
> what's your concern here?

The goal here is to check if the buddy allocator is ready, but the code
actually checks for slab.

I'm concerned there could be a gap between these two:

buddy is ready <-- gap --> slab is ready

Thanks,
Qi