[PATCH v6 7/7] mm/memory_hotplug: Factor out altmap freeing checks

[Muchun Song]

> On Apr 24, 2026, at 18:20, Andrew Morton <akpm at linux-foundation.org> wrote:
> 
> On Fri, 24 Apr 2026 09:34:43 +0200 "David Hildenbrand (Arm)" <david at kernel.org> wrote:
> 
>> On 4/24/26 04:55, Muchun Song wrote:
>>> Use a small helper to centralize altmap freeing after verifying that all
>>> vmemmap pages were released. This keeps the check consistent between the
>>> normal teardown path and the memory hotplug error paths.
>>> 
>>> Suggested-by: David Hildenbrand (Arm) <david at kernel.org>
>>> Signed-off-by: Muchun Song <songmuchun at bytedance.com>
>>> ---
>> 
>> Thanks!
>> 
>> Acked-by: David Hildenbrand (Arm) <david at kernel.org>
>> 
>> Andrew usually prefers sending non-fixes separately,
> 
> Patches which are destined for the current -rc cycle (and possibly
> -stable) (aka "hotfixes") take a different route into mainline from
> regular next-merge-window material.  They go into different branches
> and they have different timing.
> 
> If a patchset has a mixture of hotfixes (upstream next week) and
> regular patches (upstream mid June) then I have to pull the series
> apart, stage some things into one branch and other things in another
> branch, rework the cover letter etc etc.  Problems with this are:
> 
> - what goes upstream doesn't map well onto what was presented on the
>  mailing list.
> 
> - the hotfixes (upstream next week) may have dependencies on the
>  regular patches (upstream mid June).  This is backwards.
> 
> Much depends on the urgency of the hotfixes.
> 
> In this case, iirc, the determination is "not very urgent at all".  So
> the series is OK as-is - it's all "upstream mid June".
> 
> This is still a bit suboptimal because when the -stable maintainers get
> onto backporting the cc:stable patches (after mid June), they may
> encounter merge/build/runtime issues due to the absence of the
> non-hotfix patches from this series.
> 
> So generally, it is best for authors to have a think about these
> timing/priority issues and to present the patches in a suitable fashion
> - hotfixes/-stable patches in one series then non-hotfixes in a second,
> later series.  This way their presentation matches what goes upstream
> and we reduce the possibility of problems when the -stable maintainers
> get onto backporting.

Thanks for the clarification! Since I'm heading into the next revision
anyway, I’ll go ahead and split the series.

I'll drop the non-fix patches for now and focus this series on the
bugfixes to ensure a smooth merge. The regular patches will follow
in a separate submission later.

Thanks,
Muchun.