[tip:core/rcu] documentation: Expand on scheduler/ RCU deadlock requirements

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Commit-ID:  a4b575627e8d1a2498a921940813266d4e26ff56
Gitweb:     http://git.kernel.org/tip/a4b575627e8d1a2498a921940813266d4e26ff56
Author:     Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx>
AuthorDate: Wed, 7 Oct 2015 15:52:25 -0700
Committer:  Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx>
CommitDate: Sat, 5 Dec 2015 12:33:26 -0800

documentation: Expand on scheduler/RCU deadlock requirements

This commit adds a second option for avoiding scheduler/RCU deadlocks,
namely that preemption be disabled across the entire RCU read-side
critical section in question.

Signed-off-by: Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx>
---
 Documentation/RCU/Design/Requirements/Requirements.html  | 14 +++++++++-----
 Documentation/RCU/Design/Requirements/Requirements.htmlx | 14 +++++++++-----
 2 files changed, 18 insertions(+), 10 deletions(-)

diff --git a/Documentation/RCU/Design/Requirements/Requirements.html b/Documentation/RCU/Design/Requirements/Requirements.html
index 1052471..ab513ed 100644
--- a/Documentation/RCU/Design/Requirements/Requirements.html
+++ b/Documentation/RCU/Design/Requirements/Requirements.html
@@ -1942,12 +1942,16 @@ RCU depends on the scheduler, and the scheduler uses RCU to
 protect some of its data structures.
 This means the scheduler is forbidden from acquiring
 the runqueue locks and the priority-inheritance locks
-in the middle of an outermost RCU read-side critical section unless
-it also releases them before exiting that same
-RCU read-side critical section.
-This same prohibition also applies to any lock that is acquired
+in the middle of an outermost RCU read-side critical section unless either
+(1)&nbsp;it releases them before exiting that same
+RCU read-side critical section, or
+(2)&nbsp;preemption is disabled across
+that entire RCU read-side critical section.
+This same prohibition also applies (recursively!) to any lock that is acquired
 while holding any lock to which this prohibition applies.
-Violating this rule results in deadlock.
+Adhering to this rule prevents preemptible RCU from invoking
+<tt>rcu_read_unlock_special()</tt> while either runqueue or
+priority-inheritance locks are held, thus avoiding deadlock.
 
 <p>
 For RCU's part, the preemptible-RCU <tt>rcu_read_unlock()</tt>
diff --git a/Documentation/RCU/Design/Requirements/Requirements.htmlx b/Documentation/RCU/Design/Requirements/Requirements.htmlx
index 5b76e21..f7c817f 100644
--- a/Documentation/RCU/Design/Requirements/Requirements.htmlx
+++ b/Documentation/RCU/Design/Requirements/Requirements.htmlx
@@ -2109,12 +2109,16 @@ RCU depends on the scheduler, and the scheduler uses RCU to
 protect some of its data structures.
 This means the scheduler is forbidden from acquiring
 the runqueue locks and the priority-inheritance locks
-in the middle of an outermost RCU read-side critical section unless
-it also releases them before exiting that same
-RCU read-side critical section.
-This same prohibition also applies to any lock that is acquired
+in the middle of an outermost RCU read-side critical section unless either
+(1)&nbsp;it releases them before exiting that same
+RCU read-side critical section, or
+(2)&nbsp;preemption is disabled across
+that entire RCU read-side critical section.
+This same prohibition also applies (recursively!) to any lock that is acquired
 while holding any lock to which this prohibition applies.
-Violating this rule results in deadlock.
+Adhering to this rule prevents preemptible RCU from invoking
+<tt>rcu_read_unlock_special()</tt> while either runqueue or
+priority-inheritance locks are held, thus avoiding deadlock.
 
 <p>
 For RCU's part, the preemptible-RCU <tt>rcu_read_unlock()</tt>
--
To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Stable Commits]     [Linux Stable Kernel]     [Linux Kernel]     [Linux USB Devel]     [Linux Video &Media]     [Linux Audio Users]     [Yosemite News]     [Linux SCSI]

  Powered by Linux