[PATCH v3 2/4] mm/sparse-vmemmap: Pass @pgmap argument to memory deactivation paths

[Muchun Song]

> On Apr 21, 2026, at 11:55, Oscar Salvador <osalvador at suse.de> wrote:
> 
> On Tue, Apr 21, 2026 at 10:20:42AM +0800, Muchun Song wrote:
>> Currently, the memory hot-remove call chain -- arch_remove_memory(),
>> __remove_pages(), sparse_remove_section() and section_deactivate() --
>> does not carry the struct dev_pagemap pointer. This prevents the lower
>> levels from knowing whether the section was originally populated with
>> vmemmap optimizations (e.g., DAX with vmemmap optimization enabled).
>> 
>> Without this information, we cannot call vmemmap_can_optimize() to
>> determine if the vmemmap pages were optimized. As a result, the vmemmap
>> page accounting during teardown will mistakenly assume a non-optimized
>> allocation, leading to incorrect memmap statistics.
>> 
>> To lay the groundwork for fixing the vmemmap page accounting, we need
>> to pass the @pgmap pointer down to the deactivation location. Plumb the
>> @pgmap argument through the APIs of arch_remove_memory(), __remove_pages()
>> and sparse_remove_section(), mirroring the corresponding *_activate()
>> paths.
>> 
>> Signed-off-by: Muchun Song <songmuchun at bytedance.com>
>> Acked-by: Mike Rapoport (Microsoft) <rppt at kernel.org>
> 
> Reviewed-by: Oscar Salvador <osalvador at suse.de>

Thanks.

> 
> The change looks good to me, but I was wondering whether we should pass a
> mhp struct instead to low-level functions like arch_remove_memory and
> __remove_pages and have __remove_pages then pass the right stuff down
> the road.
> That way it would mimic more what we do in hot-add path.

Passing the pgmap parameter is a temporary fix, as I have another
patchset coming up to remove pgmap entirely [1].

[1] https://lore.kernel.org/linux-mm/20260405125240.2558577-46-songmuchun@bytedance.com/

Thanks,
Muchun.

> 
> 
> -- 
> Oscar Salvador
> SUSE Labs