[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200224163409.GJ18400@hirez.programming.kicks-ass.net>
Date: Mon, 24 Feb 2020 17:34:09 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Steven Rostedt <rostedt@...dmis.org>
Cc: Andy Lutomirski <luto@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
linux-arch <linux-arch@...r.kernel.org>,
Ingo Molnar <mingo@...nel.org>,
Joel Fernandes <joel@...lfernandes.org>,
Greg KH <gregkh@...uxfoundation.org>, gustavo@...eddedor.com,
Thomas Gleixner <tglx@...utronix.de>, paulmck@...nel.org,
Josh Triplett <josh@...htriplett.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Lai Jiangshan <jiangshanlai@...il.com>,
Tony Luck <tony.luck@...el.com>,
Frederic Weisbecker <frederic@...nel.org>,
Dan Carpenter <dan.carpenter@...cle.com>,
Masami Hiramatsu <mhiramat@...nel.org>
Subject: Re: [PATCH v4 05/27] x86: Replace ist_enter() with nmi_enter()
On Mon, Feb 24, 2020 at 11:27:08AM -0500, Steven Rostedt wrote:
> On Mon, 24 Feb 2020 11:43:46 +0100
> Peter Zijlstra <peterz@...radead.org> wrote:
>
> > -dotraplinkage void notrace do_int3(struct pt_regs *regs, long error_code)
> > +dotraplinkage notrace void do_int3(struct pt_regs *regs, long error_code)
> > {
> > if (poke_int3_handler(regs))
> > return;
> >
> > /*
> > - * Use ist_enter despite the fact that we don't use an IST stack.
> > - * We can be called from a kprobe in non-CONTEXT_KERNEL kernel
> > - * mode or even during context tracking state changes.
> > - *
> > - * This means that we can't schedule. That's okay.
> > + * Unlike any other non-IST entry, we can be called from pretty much
> > + * any location in the kernel through kprobes -- text_poke() will most
> > + * likely be handled by poke_int3_handler() above. This means this
> > + * handler is effectively NMI-like.
> > */
> > - ist_enter(regs);
> > + nmi_enter();
>
> Hmm, note that nmi_enter() calls other functions. Did you make sure
> all of them are not able to be kprobed. This is different than just
> being "NMI like", it's that if they are kprobed, then this will go into
> an infinite loop because nothing can have a kprobe before the kprobe
> int3 handler is called here.
I did not audit that; I went with the fact that hitting kprobes before
in_nmi() is true is a bug.
Looking at nmi_enter(), that leaves trace_hardirq_enter(), since we know
we marked rcu_nmi_enter() as NOKPROBES, per the patches elsewhere in
this series.
Powered by blists - more mailing lists