diff options
| author | Daniel Mentz <danielmentz@google.com> | 2016-08-04 17:56:53 -0700 |
|---|---|---|
| committer | Vineet Gupta <vgupta@synopsys.com> | 2016-08-10 10:14:07 -0700 |
| commit | 18b43e89d295cc65151c505c643c98fb2c320e59 (patch) | |
| tree | 6a4b3936ca2d3fbfdb577f6525d18b468f19879c /fs/xfs/xfs_trans_inode.c | |
| parent | 29b4817d4018df78086157ea3a55c1d9424a7cfc (diff) | |
| download | linux-18b43e89d295cc65151c505c643c98fb2c320e59.tar.gz | |
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>
Diffstat (limited to 'fs/xfs/xfs_trans_inode.c')
0 files changed, 0 insertions, 0 deletions