Re: [PATCH 1/1] x86/mm: fix incomplete page-table invalidation with TCE

[Lance Yang <lance.yang@linux.dev>]

On 2026/10/5 23:15, Rik van Riel wrote:
> On Mon, 2026-10-05 at 13:23 +0800, Lance Yang wrote:
>> pud_free_pmd_page() uses a single-address invalidation to flush the
>> paging-structure caches before freeing the page tables. With AMD TCE
>> enabled, this only invalidates upper-level entries associated with
>> the
>> target address. Cached PMD entries for other addresses in the PUD
>> range can
>> still reference the PTE pages being freed.
>>
>> The AMD manual quoted in the commit enabling TCE says these
>> instructions
>> remove
>>
>>    "only those upper-level entries that lead to the target PTE in the
>> page
>>    table hierarchy, leaving unrelated upper-level entries intact."
>>
>> Even with all PTEs cleared, speculative page walks can cache present
>> PMD
>> entries after the earlier TLB purge.
> 
> The comment above the function says it all. The TLB
> range should already have been cleared by the time
> pud_free_pmd_page() gets called:
> 
> /**
>   * pud_free_pmd_page - Clear PUD entry and free PMD page
>   * @pud: Pointer to a PUD
>   * @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)
> {
> 
> The PMD could have been (speculatively) loaded by the
> CPU after the PTEs were freed, so that one PMD mapping
> needs to be flushed here, but there should not be
> anything else left to flush.
> 
> The code looks odd, but it's a good idea to always
> ask your AI to draw up a full chain of events for
> a bug to trigger, going all the way back to something
> calling the mm from the outside.

Thanks for looking into this! I'll take another look
and trace it through.