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.