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 <[email protected]> Signed-off-by: Sebastian Andrzej Siewior <[email protected]> --- 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
