Hello, "Troubleshooting" section in Documentation/locking/lockdep-design.txt describes ---------------------------------------- 1. Repeated module loading and unloading while running the validator will result in lock-class leakage. The issue here is that each load of the module will create a new set of lock classes for that module's locks, but module unloading does not remove old classes (see below discussion of reuse of lock classes for why). Therefore, if that module is loaded and unloaded repeatedly, the number of lock classes will eventually reach the maximum. ::: One might argue that the validator should be modified to allow lock classes to be reused. However, if you are tempted to make this argument, first review the code and think through the changes that would be required, keeping in mind that the lock classes to be removed are likely to be linked into the lock-dependency graph. This turns out to be harder to do than to say. ----------------------------------------
I am wondering these "module unloading does not remove old classes" "the lock classes to be removed are likely to be linked into the lock-dependency graph" sentences are still valid? Does "the lock-dependency graph" mean class->hash_entry class->lock_entry and/or list_entries[]? Those are handled by zap_class() at unloading the module. Here is my question. Doesn't zap_class() make the slot in lock_classes[] logically unused? If so, can we re-use the unused slot by searchng and testing some members in struct lock_class? For example, bool test_unused(class) { return !rcu_access_pointer(class->name) && !rcu_access_pointer(class->key) && list_empty(&class->lock_entry) && hlist_unhashed(&class->hash_entry); } Though a new function list_del_init_rcu() for zap_class() will be necessary. J. R. Okajima