Messages in this thread Patch in this message | | | From | Yuyang Du <> | Subject | [PATCH v3 18/18] locking/lockdep: Add explanation to lock usage rules in lockdep design doc | Date | Thu, 21 Mar 2019 15:57:25 +0800 |
| |
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 <duyuyang@gmail.com> --- 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: -- 1.8.3.1
| |