Re: [PATCH 1/4] x86/mm: fix missing pgtable destructor for vmemmap tables

[Muchun Song]

> On Oct 10, 2026, at 04:54, Dave Hansen <dave.hansen@xxxxxxxxx> wrote:
> 
> On 10/8/26 00:30, 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.
>> 
>> 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 that table through
>> free_pagetable(). That path currently calls pagetable_free() directly
>> without decrementing NR_PAGETABLE.
>> 
>> Use PageTable() to identify constructor-backed tables and run the
>> matching destructor before freeing them. Keep reserved and
>> constructor-free tables on their existing paths. This also prepares
>> vmemmap teardown for generic runtime allocations through the normal
>> pgalloc helpers.
> 
> Could you please take some time and trim the bits out of this changelog
> that the LLM inserted but that are not super relevant? For instance, I'm
> not sure what the first paragraph is trying to say. It is apparently
> missing some context.
> 
> FWIW, I really don't like the LLM changelogs on their own. They almost
> inevitably need human editing to make them usable. I really, really
> expect humans that are sending x86 patches to spend some human
> brainpower on them. In fact, I expect folks with:
> 
> Assisted-by: LLM
> 
> to be sending _impeccable_ changelogs in v1 because their LLM saved them
> so much time that they can spend gobs on their changelogs. More than
> ever. ;)

I agree with the general point that LLM output needs to be carefully
checked by the submitter rather than adopted as-is.

However, I think the first paragraph is relevant. It is intended to
provide background: commit 49f599666420 changed the behavior of
pte_alloc_one_kernel and should be canditate for Fixes tag. The second
paragraph then explains that HVO depends on pte_alloc_one_kernel, so
that change also affected HVO behavior. The third paragraph describes
the fix. So the changelog does have a coherent structure, even if it
can be trimmed.

Of course. I just wanted to explain that I did review the LLM-generated
content, and that I did not simply leave it unchecked.

> 
> Oh, and it's an x86 crime that we have:
> 
> free_pagetable()
> and
> pagetable_free()
> 
> Any work that makes that coherent would be much appreciated.

Maybe rename free_pagetable to free_hotplug_pgtable_page in
a separate cleanup patch?

Thanks,
Muchun