[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2c5d11cf-ad06-444c-b84a-42de7a10159d@intel.com>
Date: Fri, 2 May 2025 10:57:00 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Valentin Schneider <vschneid@...hat.com>,
Steven Rostedt <rostedt@...dmis.org>
Cc: linux-kernel@...r.kernel.org, virtualization@...ts.linux.dev,
linux-arm-kernel@...ts.infradead.org, loongarch@...ts.linux.dev,
linux-riscv@...ts.infradead.org, linux-perf-users@...r.kernel.org,
kvm@...r.kernel.org, linux-arch@...r.kernel.org,
linux-modules@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
rcu@...r.kernel.org, linux-hardening@...r.kernel.org,
linux-kselftest@...r.kernel.org, bpf@...r.kernel.org,
Juri Lelli <juri.lelli@...hat.com>, Marcelo Tosatti <mtosatti@...hat.com>,
Yair Podemsky <ypodemsk@...hat.com>, Josh Poimboeuf <jpoimboe@...nel.org>,
Daniel Wagner <dwagner@...e.de>, Petr Tesarik <ptesarik@...e.com>,
Nicolas Saenz Julienne <nsaenz@...zon.com>,
Frederic Weisbecker <frederic@...nel.org>,
"Paul E. McKenney" <paulmck@...nel.org>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Sean Christopherson <seanjc@...gle.com>, Juergen Gross <jgross@...e.com>,
Ajay Kaher <ajay.kaher@...adcom.com>,
Alexey Makhalov <alexey.amakhalov@...adcom.com>,
Broadcom internal kernel review list
<bcm-kernel-feedback-list@...adcom.com>, Russell King
<linux@...linux.org.uk>, Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>, Huacai Chen <chenhuacai@...nel.org>,
WANG Xuerui <kernel@...0n.name>, Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>,
Alexandre Ghiti <alex@...ti.fr>, Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Namhyung Kim <namhyung@...nel.org>, Mark Rutland <mark.rutland@....com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Jiri Olsa <jolsa@...nel.org>, Ian Rogers <irogers@...gle.com>,
Adrian Hunter <adrian.hunter@...el.com>,
"Liang, Kan" <kan.liang@...ux.intel.com>,
Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>,
Paolo Bonzini <pbonzini@...hat.com>, Arnd Bergmann <arnd@...db.de>,
Jason Baron <jbaron@...mai.com>, Ard Biesheuvel <ardb@...nel.org>,
Luis Chamberlain <mcgrof@...nel.org>, Petr Pavlu <petr.pavlu@...e.com>,
Sami Tolvanen <samitolvanen@...gle.com>, Daniel Gomez
<da.gomez@...sung.com>, Naveen N Rao <naveen@...nel.org>,
Anil S Keshavamurthy <anil.s.keshavamurthy@...el.com>,
"David S. Miller" <davem@...emloft.net>,
Masami Hiramatsu <mhiramat@...nel.org>,
Neeraj Upadhyay <neeraj.upadhyay@...nel.org>,
Joel Fernandes <joel@...lfernandes.org>,
Josh Triplett <josh@...htriplett.org>, Boqun Feng <boqun.feng@...il.com>,
Uladzislau Rezki <urezki@...il.com>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Lai Jiangshan <jiangshanlai@...il.com>, Zqiang <qiang.zhang1211@...il.com>,
Vincent Guittot <vincent.guittot@...aro.org>,
Dietmar Eggemann <dietmar.eggemann@....com>, Ben Segall
<bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
Kees Cook <kees@...nel.org>, Shuah Khan <shuah@...nel.org>,
Masahiro Yamada <masahiroy@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>,
Miguel Ojeda <ojeda@...nel.org>, "Mike Rapoport (Microsoft)"
<rppt@...nel.org>, Rong Xu <xur@...gle.com>,
Rafael Aquini <aquini@...hat.com>, Song Liu <song@...nel.org>,
Andrii Nakryiko <andrii@...nel.org>, Dan Carpenter
<dan.carpenter@...aro.org>, Brian Gerst <brgerst@...il.com>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Benjamin Berg <benjamin.berg@...el.com>,
Vishal Annapurve <vannapurve@...gle.com>,
Randy Dunlap <rdunlap@...radead.org>, John Stultz <jstultz@...gle.com>,
Tiezhu Yang <yangtiezhu@...ngson.cn>
Subject: Re: [PATCH v5 00/25] context_tracking,x86: Defer some IPIs until a
user->kernel transition
gah, the cc list here is rotund...
On 5/2/25 09:38, Valentin Schneider wrote:
...
>> All of the paths to enter the kernel from userspace have some
>> SWITCH_TO_KERNEL_CR3 variant. If they didn't, the userspace that they
>> entered from could have attacked the kernel with Meltdown.
>>
>> I'm theorizing that if this is _just_ about avoiding TLB flush IPIs that
>> you can get away with a single mechanism.
>
> So right now there would indeed be the TLB flush IPIs, but also the
> text_poke() ones (sync_core() after patching text).
>
> These are the two NOHZ-breaking IPIs that show up on my HP box, and that I
> also got reports for from folks using NOHZ_FULL + CPU isolation in
> production, mostly on SPR "edge enhanced" type of systems.
...
> While I don't expect the list to grow much, it's unfortunately not just the
> TLB flush IPIs.
Isn't text patching way easier than TLB flushes? You just need *some*
serialization. Heck, since TLB flushes are architecturally serializing,
you could probably even reuse the exact same mechanism: implement
deferred text patch serialization operations as a deferred TLB flush.
The hardest part is figuring out which CPUs are in the state where they
can be deferred or not. But you have to solve that in any case, and you
already have an algorithm to do it.
Powered by blists - more mailing lists