Re: [PATCH] mm/hugetlb_vmemmap: fix incorrect vmemmap restore in rollback

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

> On May 26, 2026, at 05:49, Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> On Mon, 25 May 2026 10:52:13 +0800 Muchun Song <songmuchun@bytedance.com> wrote:
> 
>> vmemmap_restore_pte() rebuilds restored vmemmap pages from a
>> tail-page template derived from compound_head(). This is wrong when the
>> current PTE already maps a page whose contents are not tail-page
>> metadata.
>> 
>> In the rollback path of vmemmap_remap_free(), the first restored PTE is
>> backed by vmemmap_head and contains head-page metadata. Reconstructing
>> that page from a tail-page template overwrites the head-page state and
>> corrupts the restored vmemmap page.
>> 
>> Fix this by copying the full page from the page currently mapped by the
>> PTE. Also pass vmemmap_tail to the rollback walk so only PTEs backed by
>> the shared tail page are restored, while the head PTE remains mapped to
>> vmemmap_head. Add VM_WARN_ON_ONCE() checks for unexpected cases.
> 
> Queued in mm-hotfixes, thanks.
> 
>> Fixes: c0b495b91a47 ("mm/hugetlb: refactor code around vmemmap_walk")
> 
> A "refactoring" patch caused a regression?  Ouch.

Yes.

> 
> This patch caused Sashiko to identify a possible pre-existing mem
> hotplug race:
> https://sashiko.dev/#/patchset/20260525025213.2229628-1-songmuchun@bytedance.com

I think it is a false positive since hugetlb pages cannot be freed to
buddy allocator, we cannot race with memory hot remove.

Muchun,
Thanks.