Message-ID: <20241121110020.GC24774@noisy.programming.kicks-ass.net>
Date: Thu, 21 Nov 2024 12:00:20 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Josh Poimboeuf <jpoimboe@...nel.org>
Cc: Valentin Schneider <vschneid@...hat.com>, linux-kernel@...r.kernel.org,
	linux-doc@...r.kernel.org, kvm@...r.kernel.org, linux-mm@...ck.org,
	bpf@...r.kernel.org, x86@...nel.org, rcu@...r.kernel.org,
	linux-kselftest@...r.kernel.org,
	Steven Rostedt <rostedt@...dmis.org>,
	Masami Hiramatsu <mhiramat@...nel.org>,
	Jonathan Corbet <corbet@....net>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Wanpeng Li <wanpengli@...cent.com>,
	Vitaly Kuznetsov <vkuznets@...hat.com>,
	Andy Lutomirski <luto@...nel.org>,
	Frederic Weisbecker <frederic@...nel.org>,
	"Paul E. McKenney" <paulmck@...nel.org>,
	Neeraj Upadhyay <quic_neeraju@...cinc.com>,
	Joel Fernandes <joel@...lfernandes.org>,
	Josh Triplett <josh@...htriplett.org>,
	Boqun Feng <boqun.feng@...il.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	Lai Jiangshan <jiangshanlai@...il.com>,
	Zqiang <qiang.zhang1211@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Uladzislau Rezki <urezki@...il.com>,
	Christoph Hellwig <hch@...radead.org>,
	Lorenzo Stoakes <lstoakes@...il.com>,
	Jason Baron <jbaron@...mai.com>, Kees Cook <keescook@...omium.org>,
	Sami Tolvanen <samitolvanen@...gle.com>,
	Ard Biesheuvel <ardb@...nel.org>,
	Nicholas Piggin <npiggin@...il.com>,
	Juerg Haefliger <juerg.haefliger@...onical.com>,
	Nicolas Saenz Julienne <nsaenz@...nel.org>,
	"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
	Nadav Amit <namit@...are.com>, Dan Carpenter <error27@...il.com>,
	Chuang Wang <nashuiliang@...il.com>,
	Yang Jihong <yangjihong1@...wei.com>,
	Petr Mladek <pmladek@...e.com>,
	"Jason A. Donenfeld" <Jason@...c4.com>, Song Liu <song@...nel.org>,
	Julian Pidancet <julian.pidancet@...cle.com>,
	Tom Lendacky <thomas.lendacky@....com>,
	Dionna Glaze <dionnaglaze@...gle.com>,
	Thomas Weißschuh <linux@...ssschuh.net>,
	Juri Lelli <juri.lelli@...hat.com>,
	Marcelo Tosatti <mtosatti@...hat.com>,
	Yair Podemsky <ypodemsk@...hat.com>,
	Daniel Wagner <dwagner@...e.de>, Petr Tesarik <ptesarik@...e.com>
Subject: Re: [RFC PATCH v3 06/15] jump_label: Add forceful jump label type

On Wed, Nov 20, 2024 at 08:55:15AM -0800, Josh Poimboeuf wrote:
> On Wed, Nov 20, 2024 at 03:57:46PM +0100, Peter Zijlstra wrote:
> > On Wed, Nov 20, 2024 at 03:56:49PM +0100, Peter Zijlstra wrote:
> > 
> > > But I think we can make the fall-back safer, we can simply force the IPI
> > > when we poke at noinstr code -- then NOHZ_FULL gets to keep the pieces,
> > > but at least we don't violate any correctness constraints.
> > 
> > I should have read more; that's what is being proposed.
> 
> Hm, now I'm wondering what you read, as I only see the text poke IPIs
> being forced when the caller sets force_ipi, rather than the text poke
> code itself detecting a write to .noinstr.

Right, so I had much confusion and my initial thought was that it would
do something dangerous. Then upon reading more I see it forces the IPI
for these special keys -- with that force_ipi thing.

Now, there's only two keys marked special, and both have a noinstr
presence -- the entire reason they get marked.

So effectively we force the IPI when patching noinstr, no?

But yeah, this is not quite the same as not marking anything and simply
forcing the IPI when the target address is noinstr.

And having written all that; perhaps that is the better solution, it
sticks the logic in text_poke and ensure it automagically work for all
its users, obviating the need for special marking.

Is that what you were thinking?

Powered by blists - more mailing lists