Lockdep traces the classes but not the instances of locks.
For examle, the spinlock:
When being initialized by 'spin_lock_init':
#define raw_spin_lock_init(lock)\
do { \
static struct lock_class_key __key; \
__raw_spin_lock_init((lock), #lock, &__key); \
}while(0)
While the macro defined a static struct for any locks initialized by the
same macro,so they shared the same key to identified their class.
When using 'spin_lock' to lock, we come into '
__lock_acquire', it will check whether
the lock's class has been regisitered, if not ,regisiter it. And then, it will insert the
lock(by using its lockdep_map field and other args to init an hlock instance) into the
current task's held_lock array without increasing the number of held the array.
Then it calculates the chain key of current task and save the pervious chain key on
in hlock's prev_chain_key field. By using chain key for searching in a hash table
of lock chains(the ways of locking order), it can know whether there exist an locking
order include the lock which is being locked. If there is, it means that before we use lock
there is someone use it like this before, so it would be an deadlock. If there is not, it means
that is an new way or locking order, then it would be checked whether there is circular
dependency exist. And some other deadlock check.
When using 'spin_unlock' to unlock, the chain key will be restore from hlock's prev_chain_key or
recaculated.
阅读(1211) | 评论(0) | 转发(0) |