Re: [PATCH v2 1/4] mm: fix missing page-table destructor in pagetable_free()

[Muchun Song]

> On Oct 12, 2026, at 19:15, Jose A. Perez de Azpillaga <azpijr@xxxxxxxxx> wrote:
> 
> On Sat, Oct 10, 2026 at 07:24:54PM +0800, Muchun Song wrote:
>> Since commit 49f599666420 ("mm: call ctor/dtor for kernel PTEs"),
>> pte_alloc_one_kernel() runs the page-table constructor for kernel PTE
>> tables.
>> 
>> HVO (HugeTLB Vmemmap Optimization) uses pte_alloc_one_kernel() when
>> splitting a PMD. Restoring the vmemmap backing pages does not collapse
>> the PTE table, so a later memory hot-remove eventually frees it through
>> pagetable_free() on x86-64. That releases the page without running the
>> matching destructor and leaves NR_PAGETABLE elevated.
>> 
>> Make pagetable_free() detect constructor-backed pages and run the
>> destructor before releasing their memory to fix the problem.
>> 
>> Fixes: 49f599666420 ("mm: call ctor/dtor for kernel PTEs")
>> Cc: stable@xxxxxxxxxxxxxxx
> 
> is the x86 case covered for 6.16-6.18? as far as I can see, x86
> free_pagetable() only uses pagetable_free() since bf9e4e30f353
> ("x86/mm: use pagetable_free()") in v6.19, so the backport wouldn't
> change anything there. or am I missing something?

Yes, you are absolutely right — thanks for catching this.

I double-checked and indeed x86's free_pagetable() only starts using
pagetable_free() since bf9e4e30f353 ("x86/mm: use pagetable_free()"),
which landed in v6.19. So for 6.16-6.18 the prerequisite is not present
and the backport would be a no-op there.

The correct trailer is:

Cc: <stable@xxxxxxxxxxxxxxx> # 6.16-6.18: bf9e4e30f353: x86/mm: use pagetable_free()

Andrew, would you be able to update the trailer in the patch when you
pick it up? If there are further review comments that require code
changes, I'll fix this trailer as part of the v3 respin. Thanks a lot!

Thanks,
Muchun