subclass and name_version of lockdep
 

I'm new to lockdep and there is something which I cannot understand exactly. I want to figure out subclass and name_version. It seems that since lockdep use name_version to track the each instance of the lock class. And subclass represents for nested lock.

Then Here my questions comes.

There are two SSD each /dev/sda /dev/sdb and each SSD has two partitions so /dev/sda1 /dev/sda2 /dev/sdb1 /dev/sdb2 Then for each disk and partition, how the lock name is determined? I think that /dev/sda -> lock#1 /dev/sda1-> lock#1/1 /dev/sda2 -> lock#?/1 How the /dev/sda2's lock name is determined? It seems that the order of lock_acquire() might influence the name_version but let assume /dev/sda1's lock is pre-acquired than /dev/sda2's one.

Is there anyone who can clarify the each lock's name for possible case?

I think I have figure out what these are. Here is the thing that I get so far.
Basically, lockdep distinguish lock by class, not instance. In other words, lock thinks all spinlocks to be same, unless you set the key explicitly by lockdep_set* function.(Hereafter, assume all the spinlock is initialized by the same function)
Actually, when a spinlock is intialized, key argument which is static is always passed to the lockdep_map member of the spinlock. That's the reason why lockdep recognize all spinlocks to be same.
However, this is not useful when you debug deadlock or possible deadlock situation. So lockdep provides lockdep_set* function so that you can register each lock to be considered different by the lockdep. When the name passed to lockdep_set* is overlapped, lockdep distinguish registered lock by the name_version which is printed as # followed by number. Subclass has same principle. It is used for nested lock. With subclass argument existing, lockdep register newly so that it differentiate it. Otherwise, lockdep warns you that there is an possible deadlock situation.

Let me explain again with an example.
there is a directory contains three subdirectory which contains three files.
Top_Dir
|_Sub_Dir_1
|__File1, File2, File3
|_Sub_Dir_2
|__File4, File5, File6
|_Sub_Dir_3
|__File7, File8, File9
In this situation, if you use spinlocks for all directory and file and does not set the key explicitly, lockdep will recognizes all the lock to be same.
But if you set the key explicitly with same name, you can see such that dir_lock, dir_lock#2, dir_lock#3, ...
Moreover, when you use subclass argument with *Nested function, you can see such that dir_lock/1, dir_lock#2/1, ....

To conclude, you can annotate name_version and subclass for helping you to debug deadlock situation easily.