Lines Matching refs:L1
22 dependency can be understood as lock order, where L1 -> L2 suggests that
23 a task is attempting to acquire L2 while holding L1. From lockdep's
24 perspective, the two locks (L1 and L2) are not necessarily related; that
145 <L1> -> <L2>
146 <L2> -> <L1>
521 L1 -> L2
523 , which means lockdep has seen L1 held before L2 held in the same context at runtime.
524 And in deadlock detection, we care whether we could get blocked on L2 with L1 held,
525 IOW, whether there is a locker L3 that L1 blocks L3 and L2 gets blocked by L3. So
526 we only care about 1) what L1 blocks and 2) what blocks L2. As a result, we can combine
527 recursive readers and non-recursive readers for L1 (as they block the same types) and
608 L1 -> L2 ... -> Ln -> L1
612 L1 -> L2
616 Ln -> L1
620 Firstly let's make one CPU/task get the L1 in L1 -> L2, and then another get
624 And then because we have L1 -> L2, so the holder of L1 is going to acquire L2
625 in L1 -> L2, however since L2 is already held by another CPU/task, plus L1 ->
627 means either L2 in L1 -> L2 is a non-recursive locker (blocked by anyone) or
628 the L2 in L2 -> L3, is writer (blocking anyone), therefore the holder of L1
633 Lx+1's holder to release, and note that Ln+1 is L1, so we have a circular
645 for L1 and holding Ln, so we will have Ln -> L1 in the dependency graph. Similarly,
646 we have L1 -> L2, L2 -> L3, ..., Ln-1 -> Ln in the dependency graph, which means we
649 Ln -> L1 -> L2 -> ... -> Ln