On Fri, Sep 07, 2018 at 10:01:28AM -0400, Steven Rostedt wrote: > On Fri, 7 Sep 2018 09:55:33 -0400 > Steven Rostedt <rost...@goodmis.org> wrote: > > > On Fri, 7 Sep 2018 15:45:32 +0200 > > Peter Zijlstra <pet...@infradead.org> wrote: > > > > > Yes really, we should not muck with the IRQ state from NMI context. > > > > Right, and we didn't. Your patch didn't change anything, but allow for > > printk_nmi_enter/exit() to be traced by ftrace, but that's wrong to > > begin with because it ftrace_nmi_enter() hasn't been called yet. > > > > I would even argue that placing printk_nmi_enter() between > lockdep_off() and ftrace_nmi_enter() is wrong because if in the future > printk_nmi_enter() were to do any ftrace tracing, it wont be caught, as > it was by having it before lockdep_off(). > > printk_nmi_enter() should not muck with IRQ state, nor should it do any > ftrace tracing. Since ftrace mucks with IRQ state when it gets enabled > or disabled, it will screw up lockdep, and lockdep will complain. That > way we can use lockdep not being off to catch this bug.
The very bestest solution is to rm -rf printk ;-)
