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

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

> On Oct 13, 2026, at 01:21, Jose A. Perez de Azpillaga <azpijr@gmail.com> wrote:
> 
> On 10/12/26 2:55 PM, Muchun Song wrote:
>> 
>> 
>>> On Oct 12, 2026, at 19:15, Jose A. Perez de Azpillaga <azpijr@gmail.com> 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@vger.kernel.org
>>> 
>>> 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@vger.kernel.org> # 6.16-6.18: bf9e4e30f353: x86/mm: use pagetable_free()
> 
> also, bf9e4e30f353 alone leaks PMD-sized vmemmap pages on those trees,
> it needs 39406c05f8f1 ("x86/mm: Fix freeing of PMD-sized vmemmap pages")
> as well :)

Yeah, you are so meticulous.

> 
> Reviewed-by: Jose A. Perez de Azpillaga <azpijr@gmail.com>
> 

Thanks.

> -- 
> cheers,
> jose a. p-a