[lkml]   [2019]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Patch in this message
Subject[PATCH v3 18/18] locking/lockdep: Add explanation to lock usage rules in lockdep design doc
The rules that if violated a deacklock may happen are explained in more
detail concerning both irqs and circular dependencies.

Signed-off-by: Yuyang Du <>
Documentation/locking/lockdep-design.txt | 35 +++++++++++++++++++++++---------
1 file changed, 25 insertions(+), 10 deletions(-)

diff --git a/Documentation/locking/lockdep-design.txt b/Documentation/locking/lockdep-design.txt
index 1dcceaa..83803c6 100644
--- a/Documentation/locking/lockdep-design.txt
+++ b/Documentation/locking/lockdep-design.txt
@@ -105,14 +105,24 @@ Unused locks (e.g., mutexes) cannot be part of the cause of an error.
Single-lock state rules:

+A lock is irq-safe means it was ever used in an irq context, while a lock
+is irq-unsafe means it was ever acquired with irq enabled.
A softirq-unsafe lock-class is automatically hardirq-unsafe as well. The
-following states are exclusive, and only one of them is allowed to be
-set for any lock-class:
+following states must be exclusive: only one of them is allowed to be set
+for any lock-class based on its usage:
+ <hardirq-safe> or <hardirq-unsafe>
+ <softirq-safe> or <softirq-unsafe>

- <hardirq-safe> and <hardirq-unsafe>
- <softirq-safe> and <softirq-unsafe>
+This is because if a lock can be used in irq (safe) then it cannot be ever
+acquired with irq enabled (unsafe). Otherwise, a deadlock may happen. For
+example, in the scenario that after this lock was acquired but before
+released, if the context is interrupted this lock will be attempted to
+acquire twice, which creates a deadlock, sometimes referred to as lock
+recursion deadlock.

-The validator detects and reports lock usage that violate these
+The validator detects and reports lock usage that violates these
single-lock state rules.

Multi-lock dependency rules:
@@ -121,15 +131,20 @@ Multi-lock dependency rules:
The same lock-class must not be acquired twice, because this could lead
to lock recursion deadlocks.

-Furthermore, two locks may not be taken in different order:
+Furthermore, two locks can not be taken in inverse order:

<L1> -> <L2>
<L2> -> <L1>

-because this could lead to lock inversion deadlocks. (The validator
-finds such dependencies in arbitrary complexity, i.e. there can be any
-other locking sequence between the acquire-lock operations, the
-validator will still track all dependencies between locks.)
+because it could lead to a deadlock - sometimes referred to as lock
+inversion deadlock - as attempts to acquire the two locks form a circle
+which could lead to two contexts waiting for each other permanently, namely
+the two contexts are holding one lock while waiting for acquiring the other
+in an inverse order. The validator will find such circle in arbitrary
+complexity. In other words, there can be any number of locking sequences
+between two acquire-lock operations (holding one lock while acquiring
+another); the validator will still find whether these locks can be acquired
+in a circular fashion.

Furthermore, the following usage based lock dependencies are not allowed
between any two lock-classes:
 \ /
  Last update: 2019-03-21 08:59    [W:0.116 / U:11.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site