aboutsummaryrefslogtreecommitdiff
path: root/lib/cpu-notifier-error-inject.c
diff options
context:
space:
mode:
authorSteven Rostedt <[email protected]>2011-11-02 20:24:16 -0400
committerSteven Rostedt <[email protected]>2011-11-07 11:01:46 -0500
commite5e78d08f3ab3094783b8df08a5b6d1d1a56a58f (patch)
tree524c4faf387d4ac1dc46b23015a9d8fc4823ab88 /lib/cpu-notifier-error-inject.c
parent3890c136357284cb0656f9dd0e62286995ad32e9 (diff)
lockdep: Show subclass in pretty print of lockdep output
The pretty print of the lockdep debug splat uses just the lock name to show how the locking scenario happens. But when it comes to nesting locks, the output becomes confusing which takes away the point of the pretty printing of the lock scenario. Without displaying the subclass info, we get the following output: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(slock-AF_INET); lock(slock-AF_INET); lock(slock-AF_INET); lock(slock-AF_INET); *** DEADLOCK *** The above looks more of a A->A locking bug than a A->B B->A. By adding the subclass to the output, we can see what really happened: other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(slock-AF_INET); lock(slock-AF_INET/1); lock(slock-AF_INET); lock(slock-AF_INET/1); *** DEADLOCK *** This bug was discovered while tracking down a real bug caught by lockdep. Link: http://lkml.kernel.org/r/[email protected] Cc: Peter Zijlstra <[email protected]> Reported-by: Thomas Gleixner <[email protected]> Tested-by: Simon Kirby <[email protected]> Signed-off-by: Steven Rostedt <[email protected]>
Diffstat (limited to 'lib/cpu-notifier-error-inject.c')
0 files changed, 0 insertions, 0 deletions