In the SH-3/4 TLB access violation path we were enabling IRQs before
the call in to trace_hardirqs_on(), which ended up triggering:
if (DEBUG_LOCKS_WARN_ON(!irqs_disabled()))
return;
in kernel/lockdep.c:2031. Fix this up by removing the early re-enable,
we were already re-enabling IRQs post-trace_hardirqs_on() already, so
the semantics are now as was initially intended.
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
lds r10, pr
rts
nop
-0: sti
- mov.l 3f, r0
+0: mov.l 3f, r0
mov r9, r6
mov r8, r5
jmp @r0