Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755539AbbLDXu7 (ORCPT ); Fri, 4 Dec 2015 18:50:59 -0500 Received: from e34.co.us.ibm.com ([32.97.110.152]:43858 "EHLO e34.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754195AbbLDXt6 (ORCPT ); Fri, 4 Dec 2015 18:49:58 -0500 X-IBM-Helo: d03dlp02.boulder.ibm.com X-IBM-MailFrom: paulmck@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org From: "Paul E. McKenney" To: linux-kernel@vger.kernel.org Cc: mingo@kernel.org, jiangshanlai@gmail.com, dipankar@in.ibm.com, akpm@linux-foundation.org, mathieu.desnoyers@efficios.com, josh@joshtriplett.org, tglx@linutronix.de, peterz@infradead.org, rostedt@goodmis.org, dhowells@redhat.com, edumazet@google.com, dvhart@linux.intel.com, fweisbec@gmail.com, oleg@redhat.com, bobby.prani@gmail.com, "Paul E. McKenney" Subject: [PATCH tip/core/rcu 5/8] documentation: Expand on scheduler/RCU deadlock requirements Date: Fri, 4 Dec 2015 15:50:23 -0800 Message-Id: <1449273026-23633-5-git-send-email-paulmck@linux.vnet.ibm.com> X-Mailer: git-send-email 2.5.2 In-Reply-To: <20151204234952.GA22805@linux.vnet.ibm.com> References: <20151204234952.GA22805@linux.vnet.ibm.com> X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15120423-0017-0000-0000-000010100EB6 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3549 Lines: 70 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 --- 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 c95679dff143..e566e78b5eb1 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) it releases them before exiting that same +RCU read-side critical section, or +(2) 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 +rcu_read_unlock_special() while either runqueue or +priority-inheritance locks are held, thus avoiding deadlock.

For RCU's part, the preemptible-RCU rcu_read_unlock() diff --git a/Documentation/RCU/Design/Requirements/Requirements.htmlx b/Documentation/RCU/Design/Requirements/Requirements.htmlx index b0b88f1f765c..09d9539eb61a 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) it releases them before exiting that same +RCU read-side critical section, or +(2) 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 +rcu_read_unlock_special() while either runqueue or +priority-inheritance locks are held, thus avoiding deadlock.

For RCU's part, the preemptible-RCU rcu_read_unlock() -- 2.5.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/