From: Pedro Falcato <pfalcato@suse.de>
To: Lance Yang <lance.yang@linux.dev>
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,
nadav.amit@gmail.com, 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
Subject: Re: [PATCH 1/1] x86/mm: fix incomplete page-table invalidation with TCE
Date: Mon, 5 Oct 2026 12:24:49 +0200 [thread overview]
Message-ID: <asN4wjUbDAIcrfA-@pedro-suse.tail5790ac.ts.net> (raw)
In-Reply-To: <60d5db86-8002-4d87-b8d3-c161d674122b@linux.dev>
On Mon, Oct 05, 2026 at 03:29:22PM +0800, Lance Yang wrote:
>
>
> On 2026/10/5 14:09, Pedro Falcato wrote:
> > On Mon, Oct 05, 2026 at 01:23:02PM +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.
> > >
> > > 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>
> >
> > I'm not sure this is correct. The PUD is clear. We invalidate the TLB, which
> > invalidates the translation caches for that walk. invlpg will notice the PUD
> > isn't present. I don't see a case where it can ever not clear the rest
> > of the translation caches for all leaves. And, in fact, by that point the CPU
> > can (does?) probably formally treat the PUD as the leaf.
>
> IIUC, clearing the PUD in memory doesn't invalidate cached PMD entries by
> itself. With TCE enabled, flushing one address only invalidates the entries
> associated with that address ...
>
> (That's how I read the manual, but AMD folks, please correct me if I'm
> missing something.)
>
> So couldn't other cached PMDs under the same PUD survive?
I don't read it as that. I read it as "flushing one address only invalidates
the entries on that path". So, if you flush one address, you'll flush the
whole translation cache for that range. And page table zapping agrees; if you
follow the code from zap_pte_range() -> pte_free_tlb(), it will do a single flush
for each PTE table (if the whole table is empty/non-present).
--
Pedro
next prev parent reply other threads:[~2026-10-05 10:25 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-05 5:23 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 [this message]
2026-10-05 12:10 ` Lance Yang
2026-10-05 6:38 ` Nadav Amit
2026-10-05 7:23 ` Lance Yang
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=asN4wjUbDAIcrfA-@pedro-suse.tail5790ac.ts.net \
--to=pfalcato@suse.de \
--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=lance.yang@linux.dev \
--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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®