summaryrefslogtreecommitdiff
path: root/net/TUNABLE
diff options
context:
space:
mode:
authorSteven Rostedt <srostedt@redhat.com>2011-04-21 01:41:57 (GMT)
committerIngo Molnar <mingo@elte.hu>2011-04-22 09:06:58 (GMT)
commitdad3d7435e1d8c254d6877dc06852dc00c5da812 (patch)
tree85f4ab38ff63879b117d363ef1fdb3cf83bf870d /net/TUNABLE
parent48702ecf308e53f176c1f6fdc193d622ded54ac0 (diff)
downloadlinux-fsl-qoriq-dad3d7435e1d8c254d6877dc06852dc00c5da812.tar.xz
lockdep: Print a nicer description for irq inversion bugs
Irq inversion and irq dependency bugs are only subtly different. The diffenerence lies where the interrupt occurred. For irq dependency: irq_disable lock(A) lock(B) unlock(B) unlock(A) irq_enable lock(B) unlock(B) <interrupt> lock(A) The interrupt comes in after it has been established that lock A can be held when taking an irq unsafe lock. Lockdep detects the problem when taking lock A in interrupt context. With the irq_inversion the irq happens before it is established and lockdep detects the problem with the taking of lock B: <interrupt> lock(A) irq_disable lock(A) lock(B) unlock(B) unlock(A) irq_enable lock(B) unlock(B) Since the problem with the locking logic for both of these issues is in actuality the same, they both should report the same scenario. This patch implements that and prints this: other info that might help us debug this: Chain exists of: &rq->lock --> lockA --> lockC Possible interrupt unsafe locking scenario: CPU0 CPU1 ---- ---- lock(lockC); local_irq_disable(); lock(&rq->lock); lock(lockA); <Interrupt> lock(&rq->lock); *** DEADLOCK *** Signed-off-by: Steven Rostedt <rostedt@goodmis.org> Acked-by: Peter Zijlstra <a.p.zijlstra@chello.nl> Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Andrew Morton <akpm@linux-foundation.org> Link: http://lkml.kernel.org/r/20110421014259.910720381@goodmis.org Signed-off-by: Ingo Molnar <mingo@elte.hu>
Diffstat (limited to 'net/TUNABLE')
0 files changed, 0 insertions, 0 deletions