From: Ingo Molnar hm, while most code (except the one above) is prepared for type->name being NULL, it should not be NULL. Maybe an uninitialized lock slipped through? Please try the patch below - it both protects against type->name being NULL in this place, and will warn if it finds a NULL lockname. Cc: Arjan van de Ven Signed-off-by: Andrew Morton --- kernel/lockdep.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff -puN kernel/lockdep.c~lock-validator-core-count_matching_names-fix kernel/lockdep.c --- devel/kernel/lockdep.c~lock-validator-core-count_matching_names-fix 2006-06-09 15:23:06.000000000 -0700 +++ devel-akpm/kernel/lockdep.c 2006-06-09 15:23:06.000000000 -0700 @@ -1153,7 +1153,7 @@ int count_matching_names(struct lock_typ list_for_each_entry(type, &all_lock_types, lock_entry) { if (new_type->key - new_type->subtype == type->key) return type->name_version; - if (!strcmp(type->name, new_type->name)) + if (type->name && !strcmp(type->name, new_type->name)) count = max(count, type->name_version); } @@ -1976,7 +1976,8 @@ void lockdep_init_map(struct lockdep_map if (DEBUG_WARN_ON(!key)) return; - + if (DEBUG_WARN_ON(!name)) + return; /* * Sanity check, the lock-type key must be persistent: */ _