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 10:31, Andrew Morton <akpm@linux-foundation.org> wrote:
> 
> 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?
> 

Thanks. I used this format because it is explicitly documented by the
stable kernel rules.

The shell-style comment is the format documented in
Documentation/process/stable-kernel-rules.rst for specifying additional
patch prerequisites:

  Cc: <stable@vger.kernel.org> # 3.3.x: <commit>: <subject>
  Cc: <stable@vger.kernel.org> # 3.3.x

See:

  https://docs.kernel.org/process/stable-kernel-rules.html#option-1

A Fixes tag alone cannot express this dependency. It does not specify
an additional commit that must be cherry-picked first. The documented
Cc comment provides both the prerequisite and the required cherry-pick
order.

Would this be sufficient for the stable team to pick up the prerequisite?

Thanks,
Muchun