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

[Oscar Salvador]

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>

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.


-- 
Oscar Salvador
SUSE Labs