Re: [PATCH] x86/mm: avoid a reclaiming allocation in pud_free_pmd_page()

[Dave Hansen <dave.hansen@intel.com>]

[-- Attachment #1: Type: text/plain, Size: 1577 bytes --]

On 9/23/26 11:38, Pedro Falcato wrote:
> So, the question is: why the heck do we need a copy? PMD is still allocated
> by the time we flush the TLB. Why doesn't a simple pud_clear() + flush_tlb +
> free over the pmd Just Work? Am I missing something? The git log isn't
> clueing me in.

Yeah, the original changelog in here:

	commit 5e0fb5df2ee871b841f96f9cb6a7f2784e96aa4e
	Author: Toshi Kani <toshi.kani@hpe.com>
	Date:   Wed Jun 27 08:13:48 2018 -0600

	    x86/mm: Add TLB purge to free pmd/pte page interfaces

is a bit vague about what it is doing. I think there might have been
some confusion around speculation:

	speculation may cache pud/pmd entries (paging-structure
	caches) when they have P-bit set

Because, as far as I know, you can't have establish an entry in the TLB,
period, if Accessed==0. I think the changelog imagines a world where the
CPU is establishing TLB entries from Present=1,Accessed=0 PTEs. That
just doesn't happen.

There are only two ways the CPU can find a page table entry to cache in
the TLB and start setting Accessed bits:

 1. It walks down from CR3 and finds the entry
 2. It starts from a mid-level cache and finds the entry

This takes care of a walk from CR3 (#1):

	pud_clear(pud);

and this takes care of the mid-level caches (#2):

	/* INVLPG to clear all paging-structure caches */
	flush_tlb_kernel_range(addr, addr + PAGE_SIZE-1);

I don't think there's anything else to do. Right?

I think that means we can do something like the completely untested
attached patch.

Looks like Mikhail came to basically the same conclusion.

[-- Attachment #2: pud_free_pmd_page-simplify.patch --]
[-- Type: text/x-patch, Size: 1831 bytes --]



---

 b/arch/x86/mm/pgtable.c |   30 ++++++++++--------------------
 1 file changed, 10 insertions(+), 20 deletions(-)

diff -puN arch/x86/mm/pgtable.c~pud_free_pmd_page-simplify arch/x86/mm/pgtable.c
--- a/arch/x86/mm/pgtable.c~pud_free_pmd_page-simplify	2026-09-23 15:30:32.035610475 -0700
+++ b/arch/x86/mm/pgtable.c	2026-09-23 15:36:56.663747586 -0700
@@ -1,4 +1,4 @@
-// SPDX-License-Identifier: GPL-2.0
+pud_free_pmd_page-simplify// SPDX-License-Identifier: GPL-2.0
 #include <linux/mm.h>
 #include <linux/gfp.h>
 #include <linux/hugetlb.h>
@@ -711,44 +711,34 @@ int pmd_clear_huge(pmd_t *pmd)
  * @addr: Virtual address associated with PUD
  *
  * Context: The PUD range has been unmapped and TLB purged.
- * Return: 1 if clearing the entry succeeded. 0 otherwise.
  *
  * NOTE: Callers must allow a single page allocation.
  */
-int pud_free_pmd_page(pud_t *pud, unsigned long addr)
+void pud_free_pmd_page(pud_t *pud, unsigned long addr)
 {
-	pmd_t *pmd, *pmd_sv;
 	struct ptdesc *pt;
+	pmd_t *pmd;
 	int i;
 
 	pmd = pud_pgtable(*pud);
-	pmd_sv = (pmd_t *)__get_free_page(GFP_KERNEL);
-	if (!pmd_sv)
-		return 0;
-
-	for (i = 0; i < PTRS_PER_PMD; i++) {
-		pmd_sv[i] = pmd[i];
-		if (!pmd_none(pmd[i]))
-			pmd_clear(&pmd[i]);
-	}
 
 	pud_clear(pud);
 
-	/* INVLPG to clear all paging-structure caches */
+	/*
+	 * 'pmd' and all its descendents are unreachable
+	 * via normal page walks. Make them unreachable
+	 * in cached mid-level walks too:
+	 */
 	flush_tlb_kernel_range(addr, addr + PAGE_SIZE-1);
 
 	for (i = 0; i < PTRS_PER_PMD; i++) {
-		if (!pmd_none(pmd_sv[i])) {
-			pt = page_ptdesc(pmd_page(pmd_sv[i]));
+		if (!pmd_none(pmd[i])) {
+			pt = page_ptdesc(pmd_page(pmd[i]));
 			pagetable_dtor_free(pt);
 		}
 	}
 
-	free_page((unsigned long)pmd_sv);
-
 	pmd_free(&init_mm, pmd);
-
-	return 1;
 }
 
 /**
_