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
