On Wed, Aug 19, 2020 at 05:32:50PM +0200, pet...@infradead.org wrote:
> On Wed, Aug 19, 2020 at 08:39:13PM +1000, Alexey Kardashevskiy wrote:
>
> > > or current upstream?
> >
> > The upstream 18445bf405cb (13 hours old) also shows the problem. Yours
> > 1/2 still fixes it.
>
> Afaict that just reduces the window.
>
> Isn't the problem that:
>
> arch/powerpc/kernel/exceptions-64e.S
>
> START_EXCEPTION(perfmon);
> NORMAL_EXCEPTION_PROLOG(0x260, BOOKE_INTERRUPT_PERFORMANCE_MONITOR,
> PROLOG_ADDITION_NONE)
> EXCEPTION_COMMON(0x260)
> INTS_DISABLE
> # RECONCILE_IRQ_STATE
> # TRACE_DISABLE_INTS
> # TRACE_WITH_FRAME_BUFFER(trace_hardirqs_off)
> #
> # but we haven't done nmi_enter() yet... whoopsy
>
> CHECK_NAPPING()
> addi r3,r1,STACK_FRAME_OVERHEAD
> bl performance_monitor_exception
> # perf_irq()
> # perf_event_interrupt
> # __perf_event_interrupt
> # nmi_enter()
>
>
>
> That is, afaict your entry code is buggered.
That is, patch 1/2 doesn't change the case:
local_irq_enable()
trace_hardirqs_on()
<NMI>
trace_hardirqs_off()
...
if (regs_irqs_disabled(regs)) // false
trace_hardirqs_on();
</NMI>
raw_local_irq_enable()
Where local_irq_enable() has done trace_hardirqs_on() and the NMI hits
and undoes it, but doesn't re-do it because the hardware state is still
disabled.
What's supposed to happen is:
<NMI>
nmi_enter()
trace_hardirqs_off() // no-op, because in_nmi() (or previously
because lockdep_off())
...
</NMI>
