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@xxxxxxxxxxxxx> 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.
