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

[Andrew Morton <akpm@linux-foundation.org>]

On Mon, 12 Oct 2026 20:55:06 +0800 Muchun Song <muchun.song@linux.dev> 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()
> 
> 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!

I don't know if/how the -stable maintainers handle a comment like that.
I expect it's more reliable to do this via Fixes:.  Possible?