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
62 modprobe/2287 is trying to acquire lock:
63 (&sio_locks[i].lock){-.-.}, at: [<c02867fd>] mutex_lock+0x21/0x24
65 but task is already holding lock:
66 (&sio_locks[i].lock){-.-.}, at: [<c02867fd>] mutex_lock+0x21/0x24
69 For a given lock, the bit positions from left to right indicate the usage
70 of the lock and readlock (if exists), for each of the n STATEs listed
83 (&sio_locks[i].lock){-.-.}, at: [<c02867fd>] mutex_lock+0x21/0x24
91 For a given STATE, whether the lock is ever acquired in that STATE
94 exact case is for the lock as of the reporting time.
111 Single-lock state rules:
114 A lock is irq-safe means it was ever used in an irq context, while a lock
117 A softirq-unsafe lock-class is automatically hardirq-unsafe as well. The
119 for any lock-class based on its usage::
124 This is because if a lock can be used in irq context (irq-safe) then it
126 deadlock may happen. For example, in the scenario that after this lock
128 lock will be attempted to acquire twice, which creates a deadlock,
129 referred to as lock recursion deadlock.
131 The validator detects and reports lock usage that violates these
132 single-lock state rules.
134 Multi-lock dependency rules:
137 The same lock-class must not be acquired twice, because this could lead
138 to lock recursion deadlocks.
145 because this could lead to a deadlock - referred to as lock inversion
149 i.e., there can be any other locking sequence between the acquire-lock
153 Furthermore, the following usage based lock dependencies are not allowed
154 between any two lock-classes::
159 The first rule comes from the fact that a hardirq-safe lock could be
160 taken by a hardirq context, interrupting a hardirq-unsafe lock - and
161 thus could result in a lock inversion deadlock. Likewise, a softirq-safe
162 lock could be taken by an softirq context, interrupting a softirq-unsafe
163 lock.
166 kernel: when acquiring a new lock, the validator checks whether there is
167 any rule violation between the new lock and any of the held locks.
169 When a lock-class changes its state, the following aspects of the above
172 - if a new hardirq-safe lock is discovered, we check whether it
173 took any hardirq-unsafe lock in the past.
175 - if a new softirq-safe lock is discovered, we check whether it took
176 any softirq-unsafe lock in the past.
178 - if a new hardirq-unsafe lock is discovered, we check whether any
179 hardirq-safe lock took it in the past.
181 - if a new softirq-unsafe lock is discovered, we check whether any
182 softirq-safe lock took it in the past.
186 could lead to a lock inversion deadlock - even if that lock scenario did
193 instance of the same lock-class. Such cases typically happen when there
202 always takes the whole disk lock as a higher lock than the partition
203 lock, the lock ordering is fully correct. The validator does not
224 The validator treats a lock that is taken in such a nested fashion as a
235 must be held: lockdep_assert_held*(&lock) and lockdep_*pin_lock(&lock).
238 particular lock is held at a certain time (and generate a WARN() otherwise).
246 lockdep_assert_held(&rq->lock);
250 where holding rq->lock is required to safely update a rq's clock.
253 used for rq->lock ATM. Despite their limited adoption these annotations
254 generate a WARN() if the lock of interest is "accidentally" unlocked. This turns
256 layer assumes a lock remains taken, but a lower layer thinks it can maybe drop
257 and reacquire the lock ("unwittingly" introducing races). lockdep_pin_lock()
259 that nobody tampered with the lock, e.g. kernel/sched/sched.h::
263 rf->cookie = lockdep_pin_lock(&rq->lock);
270 lockdep_unpin_lock(&rq->lock, rf->cookie);
286 lock related deadlock. [1]_
312 value is unique for every lock-chain in the system. Also, lock
319 that for every lock taken and for every irqs-enable event, it would
321 is O(N^2), so even with just a few hundred lock-classes we'd have to do
327 calculated, which hash is unique for every lock chain. The hash value,
336 The validator tracks a maximum of MAX_LOCKDEP_KEYS number of lock classes.
342 desktop systems have less than 1,000 lock classes, so this warning
343 normally results from lock-class leakage or failure to properly
347 will result in lock-class leakage. The issue here is that each
348 load of the module will create a new set of lock classes for
350 classes (see below discussion of reuse of lock classes for why).
352 the number of lock classes will eventually reach the maximum.
357 spinlock_t will consume 8192 lock classes -unless- each spinlock
361 the per-bucket spinlocks would guarantee lock-class overflow.
362 In contrast, a loop that called spin_lock_init() on each lock
363 would place all 8192 locks into a single lock class.
369 lock classes to be reused. However, if you are tempted to make this
371 be required, keeping in mind that the lock classes to be removed are
372 likely to be linked into the lock-dependency graph. This turns out to
375 Of course, if you do run out of lock classes, the next thing to do is
376 to find the offending lock classes. First, the following command gives
377 you the number of lock classes currently in use along with the maximum::
379 grep "lock-classes" /proc/lockdep_stats
383 lock-classes: 748 [max: 8191]
387 identify the leaking lock classes::
393 can also help you find situations where runtime lock initialization has