Lines Matching refs:lock
14 tens of thousands of) instantiations. For example a lock in the inode
16 lock class.
18 The validator tracks the 'state' of lock-classes, and it tracks
19 dependencies between different lock-classes. The validator maintains a
22 Unlike an lock instantiation, the lock-class itself never goes away: when
23 a lock-class is used for the first time after bootup it gets registered,
24 and all subsequent uses of that lock-class will be attached to this
25 lock-class.
30 The validator tracks lock-class usage history into 4n + 1 separate state bits:
47 modprobe/2287 is trying to acquire lock:
48 (&sio_locks[i].lock){-.-...}, at: [<c02867fd>] mutex_lock+0x21/0x24
50 but task is already holding lock:
51 (&sio_locks[i].lock){-.-...}, at: [<c02867fd>] mutex_lock+0x21/0x24
65 Single-lock state rules:
68 A softirq-unsafe lock-class is automatically hardirq-unsafe as well. The
70 set for any lock-class:
75 The validator detects and reports lock usage that violate these
76 single-lock state rules.
78 Multi-lock dependency rules:
81 The same lock-class must not be acquired twice, because this could lead
82 to lock recursion deadlocks.
89 because this could lead to lock inversion deadlocks. (The validator
91 other locking sequence between the acquire-lock operations, the
94 Furthermore, the following usage based lock dependencies are not allowed
95 between any two lock-classes:
100 The first rule comes from the fact the a hardirq-safe lock could be
101 taken by a hardirq context, interrupting a hardirq-unsafe lock - and
102 thus could result in a lock inversion deadlock. Likewise, a softirq-safe
103 lock could be taken by an softirq context, interrupting a softirq-unsafe
104 lock.
107 kernel: when acquiring a new lock, the validator checks whether there is
108 any rule violation between the new lock and any of the held locks.
110 When a lock-class changes its state, the following aspects of the above
113 - if a new hardirq-safe lock is discovered, we check whether it
114 took any hardirq-unsafe lock in the past.
116 - if a new softirq-safe lock is discovered, we check whether it took
117 any softirq-unsafe lock in the past.
119 - if a new hardirq-unsafe lock is discovered, we check whether any
120 hardirq-safe lock took it in the past.
122 - if a new softirq-unsafe lock is discovered, we check whether any
123 softirq-safe lock took it in the past.
127 could lead to a lock inversion deadlock - even if that lock scenario did
134 instance of the same lock-class. Such cases typically happen when there
143 always takes the whole disk lock as a higher lock than the partition
144 lock, the lock ordering is fully correct. The validator does not
165 The validator treats a lock that is taken in such a nested fashion as a
180 lock related deadlock. [*]
204 value is unique for every lock-chain in the system. Also, lock
211 that for every lock taken and for every irqs-enable event, it would
213 is O(N^2), so even with just a few hundred lock-classes we'd have to do
219 calculated, which hash is unique for every lock chain. The hash value,
228 The validator tracks a maximum of MAX_LOCKDEP_KEYS number of lock classes.
234 desktop systems have less than 1,000 lock classes, so this warning
235 normally results from lock-class leakage or failure to properly
239 will result in lock-class leakage. The issue here is that each
240 load of the module will create a new set of lock classes for
242 classes (see below discussion of reuse of lock classes for why).
244 the number of lock classes will eventually reach the maximum.
249 spinlock_t will consume 8192 lock classes -unless- each spinlock
253 the per-bucket spinlocks would guarantee lock-class overflow.
254 In contrast, a loop that called spin_lock_init() on each lock
255 would place all 8192 locks into a single lock class.
261 lock classes to be reused. However, if you are tempted to make this
263 be required, keeping in mind that the lock classes to be removed are
264 likely to be linked into the lock-dependency graph. This turns out to
267 Of course, if you do run out of lock classes, the next thing to do is
268 to find the offending lock classes. First, the following command gives
269 you the number of lock classes currently in use along with the maximum:
271 grep "lock-classes" /proc/lockdep_stats
275 lock-classes: 748 [max: 8191]
279 identify the leaking lock classes:
285 can also help you find situations where runtime lock initialization has