All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
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,
	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: Sun, 4 Oct 2026 22:47:39 -0700	[thread overview]
Message-ID: <20261004224739.e1049f07332d388169f7ef08@linux-foundation.org> (raw)
In-Reply-To: <20261005052302.43042-1-lance.yang@linux.dev>

On Mon,  5 Oct 2026 13:23:02 +0800 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

Sorry, but my usual complaint applies.

Check the first 32 lines of
Documentation/process/stable-kernel-rules.rst.  They're very simple,

I'm sure x86 people can immediately grasp the importance of this
change, but nobody else can.  This includes -stable maintainers as well
as a large number of other downstream users of our work who are
wondering "why should I apply this to my kernel".  Let's tell them!


iow, and not for the first time: when fixing a bug please fully
describe the userspace-visible runtime effects of that bug.

Thanks.


  reply	other threads:[~2026-10-05  5:47 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 [this message]
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
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=20261004224739.e1049f07332d388169f7ef08@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=Manali.Shukla@amd.com \
    --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=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.