Lines Matching full:lock
8 Lock-class
15 tens of thousands of) instantiations. For example a lock in the inode
17 lock class.
19 The validator tracks the 'usage state' of lock-classes, and it tracks
20 the dependencies between different lock-classes. Lock usage indicates
21 how a lock is used with regard to its IRQ contexts, while lock
22 dependency can be understood as lock order, where L1 -> L2 suggests that
26 continuing effort to prove lock usages and dependencies are correct or
29 A lock-class's behavior is constructed by its instances collectively:
30 when the first instance of a lock-class is used after bootup the class
33 the class. A lock-class does not go away when a lock instance does, but
34 it can be removed if the memory space of the lock class (static or
41 The validator tracks lock-class usage history and divides the usage into
65 modprobe/2287 is trying to acquire lock:
66 (&sio_locks[i].lock){-.-.}, at: [<c02867fd>] mutex_lock+0x21/0x24
68 but task is already holding lock:
69 (&sio_locks[i].lock){-.-.}, at: [<c02867fd>] mutex_lock+0x21/0x24
72 For a given lock, the bit positions from left to right indicate the usage
73 of the lock and readlock (if exists), for each of the n STATEs listed
86 (&sio_locks[i].lock){-.-.}, at: [<c02867fd>] mutex_lock+0x21/0x24
94 For a given STATE, whether the lock is ever acquired in that STATE
97 exact case is for the lock as of the reporting time.
114 Single-lock state rules:
117 A lock is irq-safe means it was ever used in an irq context, while a lock
120 A softirq-unsafe lock-class is automatically hardirq-unsafe as well. The
122 for any lock-class based on its usage::
127 This is because if a lock can be used in irq context (irq-safe) then it
129 deadlock may happen. For example, in the scenario that after this lock
131 lock will be attempted to acquire twice, which creates a deadlock,
132 referred to as lock recursion deadlock.
134 The validator detects and reports lock usage that violates these
135 single-lock state rules.
137 Multi-lock dependency rules:
140 The same lock-class must not be acquired twice, because this could lead
141 to lock recursion deadlocks.
148 because this could lead to a deadlock - referred to as lock inversion
152 i.e., there can be any other locking sequence between the acquire-lock
156 Furthermore, the following usage based lock dependencies are not allowed
157 between any two lock-classes::
162 The first rule comes from the fact that a hardirq-safe lock could be
163 taken by a hardirq context, interrupting a hardirq-unsafe lock - and
164 thus could result in a lock inversion deadlock. Likewise, a softirq-safe
165 lock could be taken by an softirq context, interrupting a softirq-unsafe
166 lock.
169 kernel: when acquiring a new lock, the validator checks whether there is
170 any rule violation between the new lock and any of the held locks.
172 When a lock-class changes its state, the following aspects of the above
175 - if a new hardirq-safe lock is discovered, we check whether it
176 took any hardirq-unsafe lock in the past.
178 - if a new softirq-safe lock is discovered, we check whether it took
179 any softirq-unsafe lock in the past.
181 - if a new hardirq-unsafe lock is discovered, we check whether any
182 hardirq-safe lock took it in the past.
184 - if a new softirq-unsafe lock is discovered, we check whether any
185 softirq-safe lock took it in the past.
189 could lead to a lock inversion deadlock - even if that lock scenario did
196 instance of the same lock-class. Such cases typically happen when there
205 always takes the whole disk lock as a higher lock than the partition
206 lock, the lock ordering is fully correct. The validator does not
227 The validator treats a lock that is taken in such a nested fashion as a
238 must be held: lockdep_assert_held*(&lock) and lockdep_*pin_lock(&lock).
241 particular lock is held at a certain time (and generate a WARN() otherwise).
249 lockdep_assert_held(&rq->lock);
253 where holding rq->lock is required to safely update a rq's clock.
256 used for rq->lock ATM. Despite their limited adoption these annotations
257 generate a WARN() if the lock of interest is "accidentally" unlocked. This turns
259 layer assumes a lock remains taken, but a lower layer thinks it can maybe drop
260 and reacquire the lock ("unwittingly" introducing races). lockdep_pin_lock()
262 that nobody tampered with the lock, e.g. kernel/sched/sched.h::
266 rf->cookie = lockdep_pin_lock(&rq->lock);
273 lockdep_unpin_lock(&rq->lock, rf->cookie);
289 lock related deadlock. [1]_
315 value is unique for every lock-chain in the system. Also, lock
322 that for every lock taken and for every irqs-enable event, it would
324 is O(N^2), so even with just a few hundred lock-classes we'd have to do
330 calculated, which hash is unique for every lock chain. The hash value,
339 The validator tracks a maximum of MAX_LOCKDEP_KEYS number of lock classes.
345 desktop systems have less than 1,000 lock classes, so this warning
346 normally results from lock-class leakage or failure to properly
350 will result in lock-class leakage. The issue here is that each
351 load of the module will create a new set of lock classes for
353 classes (see below discussion of reuse of lock classes for why).
355 the number of lock classes will eventually reach the maximum.
360 spinlock_t will consume 8192 lock classes -unless- each spinlock
364 the per-bucket spinlocks would guarantee lock-class overflow.
365 In contrast, a loop that called spin_lock_init() on each lock
366 would place all 8192 locks into a single lock class.
372 lock classes to be reused. However, if you are tempted to make this
374 be required, keeping in mind that the lock classes to be removed are
375 likely to be linked into the lock-dependency graph. This turns out to
378 Of course, if you do run out of lock classes, the next thing to do is
379 to find the offending lock classes. First, the following command gives
380 you the number of lock classes currently in use along with the maximum::
382 grep "lock-classes" /proc/lockdep_stats
386 lock-classes: 748 [max: 8191]
390 identify the leaking lock classes::
396 can also help you find situations where runtime lock initialization has
418 even inside the critical section of another reader of the same lock instance,
419 in other words, allowing nested read-side critical sections of one lock instance.
422 the critical section of another reader of the same lock instance.
425 recursive readers get blocked only by a write lock *holder*, while non-recursive
426 readers could get blocked by a write lock *waiter*. Considering the follow
442 Block conditions on readers/writers of the same lock instance:
469 only get blocked by current write lock *holders* other than write lock
481 the lock X, the second read_lock() doesn't need to wait because it's a recursive
482 read lock. However if the read_lock() is non-recursive read lock, then the above
484 lock, but it can block the second read_lock() in TASK A.
486 Note that a lock can be a write lock (exclusive lock), a non-recursive read
487 lock (non-recursive shared lock) or a recursive read lock (recursive shared
488 lock), depending on the lock operations used to acquire it (more specifically,
490 lock instance has three types of acquisition depending on the acquisition
497 even true for two non-recursive read locks). A non-recursive lock can block the
498 corresponding recursive lock, and vice versa.
514 Lock dependencies record the orders of the acquisitions of a pair of locks, and
515 because there are 3 types for lockers, there are, in theory, 9 types of lock
516 dependencies, but we can show that 4 types of lock dependencies are enough for
519 For each lock dependency::
573 -(xR)-> and -(Sx)->. In other words, a "strong" path is a path from a lock
574 walking to another through the lock dependencies, and if X -> Y -> Z is in the
643 a lock held by P2, and P2 is waiting for a lock held by P3, ... and Pn is waiting
644 for a lock held by P1. Let's name the lock Px is waiting as Lx, so since P1 is waiting
653 For a lock Lx, Px contributes the dependency Lx-1 -> Lx and Px+1 contributes
658 and this is true for any lock in the circle, therefore, the circle is strong.