ARC: Call trace_hardirqs_on() before enabling irqs
authorDaniel Mentz <danielmentz@google.com>
Fri, 5 Aug 2016 00:56:53 +0000 (17:56 -0700)
committerVineet Gupta <vgupta@synopsys.com>
Wed, 10 Aug 2016 17:14:07 +0000 (10:14 -0700)
commit18b43e89d295cc65151c505c643c98fb2c320e59
tree6a4b3936ca2d3fbfdb577f6525d18b468f19879c
parent29b4817d4018df78086157ea3a55c1d9424a7cfc
ARC: Call trace_hardirqs_on() before enabling irqs

trace_hardirqs_on_caller() in lockdep.c expects to be called before, not
after interrupts are actually enabled.

The following comment in kernel/locking/lockdep.c substantiates this
claim:

"
/*
 * We're enabling irqs and according to our state above irqs weren't
 * already enabled, yet we find the hardware thinks they are in fact
 * enabled.. someone messed up their IRQ state tracing.
 */
"

An example can be found in include/linux/irqflags.h:

do { trace_hardirqs_on(); raw_local_irq_enable(); } while (0)

Without this change, we hit the following DEBUG_LOCKS_WARN_ON.

[    7.760000] ------------[ cut here ]------------
[    7.760000] WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:2711 resume_user_mode_begin+0x48/0xf0
[    7.770000] DEBUG_LOCKS_WARN_ON(!irqs_disabled())
[    7.780000] Modules linked in:
[    7.780000] CPU: 0 PID: 1 Comm: init Not tainted 4.7.0-00003-gc668bb9-dirty #366
[    7.790000]
[    7.790000] Stack Trace:
[    7.790000]   arc_unwind_core.constprop.1+0xa4/0x118
[    7.800000]   warn_slowpath_fmt+0x72/0x158
[    7.800000]   resume_user_mode_begin+0x48/0xf0
[    7.810000] ---[ end trace 6f6a7a8fae20d2f0 ]---

Signed-off-by: Daniel Mentz <danielmentz@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
arch/arc/include/asm/irqflags-compact.h