Messages in this thread Patch in this message |  | | From | Sebastian Andrzej Siewior <> | Subject | [PATCH] lockdep: make print_lock_name() robust against non-existing lock_class | Date | Wed, 15 Apr 2015 15:24:36 +0200 |
| |
During sysrq's show-held-locks command it is possible that hlock_class() returns NULL for a given lock. The result is then (after the warning):
|BUG: unable to handle kernel NULL pointer dereference at 0000001c |IP: [<c1088145>] get_usage_chars+0x5/0x100 |Call Trace: | [<c1088263>] print_lock_name+0x23/0x60 | [<c1576b57>] print_lock+0x5d/0x7e | [<c1088314>] lockdep_print_held_locks+0x74/0xe0 | [<c1088652>] debug_show_all_locks+0x132/0x1b0 | [<c1315c48>] sysrq_handle_showlocks+0x8/0x10
This *might* happen because the thread on the other CPU drops the lock after we are looking ->lockdep_depth and ->held_locks points no longer to a lock that is held. The fix here is to simply ignore it and continue.
Reported-by: Andreas Messerschmid <andreas@linutronix.de> Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de> --- kernel/locking/lockdep.c | 4 ++++ 1 file changed, 4 insertions(+)
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c index ba77ab5f64dd..260155a2cb89 100644 --- a/kernel/locking/lockdep.c +++ b/kernel/locking/lockdep.c @@ -530,6 +530,10 @@ static void print_lock_name(struct lock_class *class) { char usage[LOCK_USAGE_CHARS]; + if (!class) { + printk(" (<NONE>)"); + return; + } get_usage_chars(class, usage); printk(" ("); -- 2.1.4
|  |