Messages in this thread | | | Date | Mon, 24 Feb 2020 17:34:09 +0100 | From | Peter Zijlstra <> | 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@infradead.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.
| |