I've found the problem. It appears to be in lockdep. struct lock_class has =
a=20
const char *name field which points to a statically allocated string that=20
comes from the code which uses the lock. If that code/string is in a module=
=20
and gets unloaded, the pointer in |name| is no longer valid. Next time this=
=20
field is dereferenced (count_matching_names, in this case), we crash.
The following patch fixes the issue but there's probably a better way.
=2DMichael Wu
=2D--
diff --git a/include/linux/lockdep.h b/include/linux/lockdep.h
index 4c4d236..2aa0d35 100644
=2D-- a/include/linux/lockdep.h
+++ b/include/linux/lockdep.h
@@ -114,7 +114,7 @@ struct lock_class {
*/
unsigned long ops;
=20
=2D const char *name;
+ char name[128];
int name_version;
=20
#ifdef CONFIG_LOCK_STAT
diff --git a/kernel/lockdep.c b/kernel/lockdep.c
index 55fe0c7..63c4d8f 100644
=2D-- a/kernel/lockdep.c
+++ b/kernel/lockdep.c
@@ -768,7 +768,7 @@ register_lock_class(struct lockdep_map *lock, unsigned =
int=20
subclass, int force)
class =3D lock_classes + nr_lock_classes++;
debug_atomic_inc(&nr_unused_locks);
class->key =3D key;
=2D class->name =3D lock->name;
+ strcpy(class->name, lock->name);
class->subclass =3D subclass;
INIT_LIST_HEAD(&class->lock_entry);
INIT_LIST_HEAD(&class->locks_before);
