Documentation/locking/lockdep-design.rst

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
528 we can combine writers and non-recursive readers for L2 (as they get blocked by the
608 	L1 -> L2 ... -> Ln -> L1
612 	L1 -> L2
613 	L2 -> L3
620 Firstly let's make one CPU/task get the L1 in L1 -> L2, and then another get
621 the L2 in L2 -> L3, and so on. After this, all of the Lx in Lx -> Lx+1 are
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 ->
626 L2 and L2 -> L3 are not -(xR)-> and -(Sx)-> (the definition of strong), which
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
629 cannot get L2, it has to wait L2's holder to release.
631 Moreover, we can have a similar conclusion for L2's holder: it has to wait L3's
646 we have L1 -> L2, L2 -> L3, ..., Ln-1 -> Ln in the dependency graph, which means we
649 	Ln -> L1 -> L2 -> ... -> Ln