All of lore.kernel.org
 help / color / mirror / Atom feed
From: Lance Yang <lance.yang@linux.dev>
To: Nadav Amit <nadav.amit@gmail.com>
Cc: 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, riel@surriel.com,
	linux-kernel@vger.kernel.org, qi.zheng@linux.dev,
	thomas.lendacky@amd.com, kernel-team@meta.com,
	linux-mm@kvack.org, akpm@linux-foundation.org,
	brendan.jackman@linux.dev, jannh@google.com,
	mhklinux@outlook.com, andrew.cooper3@citrix.com,
	Manali.Shukla@amd.com, mingo@kernel.org, stable@vger.kernel.org,
	toshi.kani@hpe.com, david@kernel.org,
	mikhail.v.gavrilov@gmail.com, pfalcato@suse.de
Subject: Re: [PATCH 1/1] x86/mm: fix incomplete page-table invalidation with TCE
Date: Mon, 5 Oct 2026 15:23:45 +0800	[thread overview]
Message-ID: <c6421cab-1a21-4d39-87ff-05dc7be6bc02@linux.dev> (raw)
In-Reply-To: <D8AEF6EF-D92A-4838-95A7-EB93BE319BE1@gmail.com>



On 2026/10/5 14:38, Nadav Amit wrote:
> 
> 
>>
>>
>> On 5 Oct 2026, at 8:23, Lance Yang <lance.yang@linux.dev> 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.
>>
>> Use a full TLB flush before freeing the page tables on CPUs with TCE. Keep
>> the single-address invalidation otherwise.
>>
>> Fixes: 440a65b7d25f ("x86/mm: Enable AMD translation cache extensions")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Lance Yang <lance.yang@linux.dev>
>> ---
>> arch/x86/mm/pgtable.c | 11 ++++++++++-
>> 1 file changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/mm/pgtable.c b/arch/x86/mm/pgtable.c
>> index 4a105f283cfb..6b7fa44f1bf6 100644
>> --- a/arch/x86/mm/pgtable.c
>> +++ b/arch/x86/mm/pgtable.c
>> @@ -727,7 +727,16 @@ int pud_free_pmd_page(pud_t *pud, unsigned long addr)
>> 	 * via normal page walks. Make them unreachable
>> 	 * in cached mid-level walks too:
>> 	 */
>> -	flush_tlb_kernel_range(addr, addr + PAGE_SIZE-1);
>> +	if (boot_cpu_has(X86_FEATURE_TCE)) {
>> +		/*
>> +		 * With TCE enabled, a single-address flush does not invalidate
>> +		 * cached PMD entries for the rest of the PUD range.
>> +		 */
>> +		flush_tlb_all();
>> +	} else {
>> +		/* INVLPG to clear all paging-structure caches */
>> +		flush_tlb_kernel_range(addr, addr + PAGE_SIZE-1);
>> +	}
>>
> 
> 
> It might be cleaner to replace flush_tlb_all() with:
> 
> 	flush_tlb_kernel_range(addr, addr + PUD_SIZE - 1);

Looks much cleaner, Thanks!

> While the flush-ceiling would usually end up doing a full flush, the
> code would be easier to follow (the very least). Maybe adding stride
> to kernel TLB range flushing would make sense in the future.

Ack.


  reply	other threads:[~2026-10-05  7:24 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-05  5:23 [PATCH 1/1] x86/mm: fix incomplete page-table invalidation with TCE Lance Yang
2026-10-05  5:47 ` Andrew Morton
2026-10-05  6:09 ` Pedro Falcato
2026-10-05  7:29   ` Lance Yang
2026-10-05  8:19     ` Andrew Cooper
2026-10-05  8:32       ` Lance Yang
2026-10-05  9:57         ` Andrew Cooper
2026-10-05 10:12           ` Lance Yang
2026-10-05 14:22             ` Borislav Petkov
2026-10-05 14:36               ` Lance Yang
2026-10-05 14:53                 ` Borislav Petkov
2026-10-05 14:58                   ` Lance Yang
2026-10-05 15:22             ` Andrew Cooper
2026-10-05 15:36               ` Lance Yang
2026-10-05 10:24     ` Pedro Falcato
2026-10-05 12:10       ` Lance Yang
2026-10-05  6:38 ` Nadav Amit
2026-10-05  7:23   ` Lance Yang [this message]
2026-10-05 15:15 ` Rik van Riel
2026-10-05 15:30   ` Lance Yang

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=c6421cab-1a21-4d39-87ff-05dc7be6bc02@linux.dev \
    --to=lance.yang@linux.dev \
    --cc=Manali.Shukla@amd.com \
    --cc=akpm@linux-foundation.org \
    --cc=andrew.cooper3@citrix.com \
    --cc=bp@alien8.de \
    --cc=brendan.jackman@linux.dev \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@kernel.org \
    --cc=hpa@zytor.com \
    --cc=jannh@google.com \
    --cc=kernel-team@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=luto@kernel.org \
    --cc=mhklinux@outlook.com \
    --cc=mikhail.v.gavrilov@gmail.com \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=nadav.amit@gmail.com \
    --cc=peterz@infradead.org \
    --cc=pfalcato@suse.de \
    --cc=qi.zheng@linux.dev \
    --cc=riel@surriel.com \
    --cc=stable@vger.kernel.org \
    --cc=tglx@kernel.org \
    --cc=thomas.lendacky@amd.com \
    --cc=toshi.kani@hpe.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.