From: Dave Hansen <dave.hansen@intel.com>
To: Muchun Song <songmuchun@bytedance.com>, akpm@linux-foundation.org
Cc: linux-mm@kvack.org, stable@vger.kernel.org, david@kernel.org,
osalvador@suse.de, dave.hansen@linux.intel.com, luto@kernel.org,
peterz@infradead.org, tglx@kernel.org, mingo@redhat.com,
bp@alien8.de, x86@kernel.org, hpa@zytor.com,
catalin.marinas@arm.com, will@kernel.org, mark.rutland@arm.com,
linux-arm-kernel@lists.infradead.org, pjw@kernel.org,
palmer@dabbelt.com, aou@eecs.berkeley.edu, alex@ghiti.fr,
linux-riscv@lists.infradead.org, agordeev@linux.ibm.com,
kevin.brodsky@arm.com, bjorn@rivosinc.com, apopple@nvidia.com,
linux-kernel@vger.kernel.org, muchun.song@linux.dev
Subject: Re: [PATCH 1/4] x86/mm: fix missing pgtable destructor for vmemmap tables
Date: Fri, 9 Oct 2026 13:54:02 -0700 [thread overview]
Message-ID: <bd47fc12-f1cf-4994-8b42-45fc68944072@intel.com> (raw)
In-Reply-To: <20261008073021.2512665-2-songmuchun@bytedance.com>
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. ;)
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.
next prev parent reply other threads:[~2026-10-09 20:54 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-08 7:30 [PATCH 0/4] mm: Fix page-table teardown during memory hot-remove Muchun Song
2026-10-08 7:30 ` [PATCH 1/4] x86/mm: fix missing pgtable destructor for vmemmap tables Muchun Song
2026-10-08 8:32 ` Muchun Song
2026-10-09 20:29 ` David Hildenbrand (Arm)
2026-10-10 3:44 ` Muchun Song
2026-10-09 20:33 ` David Hildenbrand (Arm)
2026-10-09 20:36 ` David Hildenbrand (Arm)
2026-10-10 3:49 ` Muchun Song
2026-10-09 20:54 ` Dave Hansen [this message]
2026-10-10 5:11 ` Muchun Song
2026-10-08 7:30 ` [PATCH 2/4] riscv/mm: fix hotplug page-table destructor handling Muchun Song
2026-10-09 6:09 ` Björn Töpel
2026-10-09 14:14 ` Muchun Song
2026-10-09 20:37 ` David Hildenbrand (Arm)
2026-10-10 2:58 ` Muchun Song
2026-10-08 7:30 ` [PATCH 3/4] riscv/mm: fix missing destructor for hotplug PUD tables Muchun Song
2026-10-09 20:38 ` David Hildenbrand (Arm)
2026-10-08 7:30 ` [PATCH 4/4] arm64/mm: fix destructor for unconstructed hotplug page tables Muchun Song
2026-10-09 20:43 ` David Hildenbrand (Arm)
2026-10-10 3:43 ` Muchun Song
2026-10-09 20:48 ` [PATCH 0/4] mm: Fix page-table teardown during memory hot-remove Dave Hansen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bd47fc12-f1cf-4994-8b42-45fc68944072@intel.com \
--to=dave.hansen@intel.com \
--cc=agordeev@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=alex@ghiti.fr \
--cc=aou@eecs.berkeley.edu \
--cc=apopple@nvidia.com \
--cc=bjorn@rivosinc.com \
--cc=bp@alien8.de \
--cc=catalin.marinas@arm.com \
--cc=dave.hansen@linux.intel.com \
--cc=david@kernel.org \
--cc=hpa@zytor.com \
--cc=kevin.brodsky@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-riscv@lists.infradead.org \
--cc=luto@kernel.org \
--cc=mark.rutland@arm.com \
--cc=mingo@redhat.com \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=palmer@dabbelt.com \
--cc=peterz@infradead.org \
--cc=pjw@kernel.org \
--cc=songmuchun@bytedance.com \
--cc=stable@vger.kernel.org \
--cc=tglx@kernel.org \
--cc=will@kernel.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox