All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/8] rcu: Ensure rcu read site is deadlock-immunity
@ 2013-08-07 10:24 Lai Jiangshan
  2013-08-07 10:24 ` [PATCH 1/8] rcu: add a warn to rcu_preempt_note_context_switch() Lai Jiangshan
                   ` (8 more replies)
  0 siblings, 9 replies; 49+ messages in thread
From: Lai Jiangshan @ 2013-08-07 10:24 UTC (permalink / raw)
  To: Paul E. McKenney, Steven Rostedt, Peter Zijlstra, linux-kernel
  Cc: Lai Jiangshan

Although all articles declare that rcu read site is deadlock-immunity.
It is not true for rcu-preempt, it will be deadlock if rcu read site
overlaps with scheduler lock.

ec433f0c, 10f39bb1 and 016a8d5b just partially solve it. But rcu read site
is still not deadlock-immunity. And the problem described in 016a8d5b
is still existed(rcu_read_unlock_special() calls wake_up).

The problem is fixed in patch5.

Lai Jiangshan (8):
  rcu: add a warn to rcu_preempt_note_context_switch()
  rcu: rcu_read_unlock_special() can be nested in irq/softirq 10f39bb1
  rcu: keep irqs disabled in rcu_read_unlock_special()
  rcu: delay task rcu state cleanup in exit_rcu()
  rcu: eliminate rcu read site deadlock
  rcu: call rcu_read_unlock_special() in rcu_preempt_check_callbacks()
  rcu: add # of deferred _special() statistics
  rcu: remove irq work for rsp_wakeup()

 include/linux/rcupdate.h |    2 +-
 kernel/rcupdate.c        |    2 +-
 kernel/rcutree.c         |   17 +--------
 kernel/rcutree.h         |    2 +-
 kernel/rcutree_plugin.h  |   82 ++++++++++++++++++++++++++++++++++-----------
 kernel/rcutree_trace.c   |    1 +
 6 files changed, 68 insertions(+), 38 deletions(-)

-- 
1.7.4.4


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [PATCH 1/8] rcu: add a warn to rcu_preempt_note_context_switch()
  2013-08-07 10:24 [PATCH 0/8] rcu: Ensure rcu read site is deadlock-immunity Lai Jiangshan
@ 2013-08-07 10:24 ` Lai Jiangshan
  2013-10-30 11:02   ` Paul E. McKenney
  2013-08-07 10:24 ` [PATCH 2/8] rcu: remove irq/softirq context check in rcu_read_unlock_special() Lai Jiangshan
                   ` (7 subsequent siblings)
  8 siblings, 1 reply; 49+ messages in thread
From: Lai Jiangshan @ 2013-08-07 10:24 UTC (permalink / raw)
  To: Paul E. McKenney, Steven Rostedt, Peter Zijlstra, linux-kernel
  Cc: Lai Jiangshan, Dipankar Sarma

It is expected that _nesting == INT_MIN if _nesting < 0.
Add a warning to it if something unexpected happen.

Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
---
 kernel/rcutree_plugin.h |    1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
index 63098a5..8fd947e 100644
--- a/kernel/rcutree_plugin.h
+++ b/kernel/rcutree_plugin.h
@@ -243,6 +243,7 @@ static void rcu_preempt_note_context_switch(int cpu)
 				       : rnp->gpnum + 1);
 		raw_spin_unlock_irqrestore(&rnp->lock, flags);
 	} else if (t->rcu_read_lock_nesting < 0 &&
+		   !WARN_ON_ONCE(t->rcu_read_lock_nesting != INT_MIN) &&
 		   t->rcu_read_unlock_special) {
 
 		/*
-- 
1.7.4.4


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 2/8] rcu: remove irq/softirq context check in rcu_read_unlock_special()
  2013-08-07 10:24 [PATCH 0/8] rcu: Ensure rcu read site is deadlock-immunity Lai Jiangshan
  2013-08-07 10:24 ` [PATCH 1/8] rcu: add a warn to rcu_preempt_note_context_switch() Lai Jiangshan
@ 2013-08-07 10:24 ` Lai Jiangshan
  2013-10-30 11:18   ` Paul E. McKenney
  2013-08-07 10:24 ` [PATCH 3/8] rcu: keep irqs disabled " Lai Jiangshan
                   ` (6 subsequent siblings)
  8 siblings, 1 reply; 49+ messages in thread
From: Lai Jiangshan @ 2013-08-07 10:24 UTC (permalink / raw)
  To: Paul E. McKenney, Steven Rostedt, Peter Zijlstra, linux-kernel
  Cc: Lai Jiangshan, Dipankar Sarma

After patch 10f39bb1, "special & RCU_READ_UNLOCK_BLOCKED" can't be true
in irq nor softirq.(due to RCU_READ_UNLOCK_BLOCKED can only be set
when preemption)

Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
---
 kernel/rcutree_plugin.h |    6 ------
 1 files changed, 0 insertions(+), 6 deletions(-)

diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
index 8fd947e..54f7e45 100644
--- a/kernel/rcutree_plugin.h
+++ b/kernel/rcutree_plugin.h
@@ -361,12 +361,6 @@ void rcu_read_unlock_special(struct task_struct *t)
 		rcu_preempt_qs(smp_processor_id());
 	}
 
-	/* Hardware IRQ handlers cannot block. */
-	if (in_irq() || in_serving_softirq()) {
-		local_irq_restore(flags);
-		return;
-	}
-
 	/* Clean up if blocked during RCU read-side critical section. */
 	if (special & RCU_READ_UNLOCK_BLOCKED) {
 		t->rcu_read_unlock_special &= ~RCU_READ_UNLOCK_BLOCKED;
-- 
1.7.4.4


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 3/8] rcu: keep irqs disabled in rcu_read_unlock_special()
  2013-08-07 10:24 [PATCH 0/8] rcu: Ensure rcu read site is deadlock-immunity Lai Jiangshan
  2013-08-07 10:24 ` [PATCH 1/8] rcu: add a warn to rcu_preempt_note_context_switch() Lai Jiangshan
  2013-08-07 10:24 ` [PATCH 2/8] rcu: remove irq/softirq context check in rcu_read_unlock_special() Lai Jiangshan
@ 2013-08-07 10:24 ` Lai Jiangshan
  2013-08-07 10:25 ` [PATCH 4/8] rcu: delay task rcu state cleanup in exit_rcu() Lai Jiangshan
                   ` (5 subsequent siblings)
  8 siblings, 0 replies; 49+ messages in thread
From: Lai Jiangshan @ 2013-08-07 10:24 UTC (permalink / raw)
  To: Paul E. McKenney, Steven Rostedt, Peter Zijlstra, linux-kernel
  Cc: Lai Jiangshan, Dipankar Sarma

rcu_read_unlock_special() may enable irqs temporarily before it finish its
last work. It doesn't introduce any extremely bad things. but it does
add more task rcu machine states and add more complexity, bad to review.

And if the task is preempted when it enables irqs,
the synchronize_rcu_expedited() will be slowed down, and it can't get help
from rcu_boost.

Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
---
 kernel/rcutree_plugin.h |   13 ++++++++-----
 1 files changed, 8 insertions(+), 5 deletions(-)

diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
index 54f7e45..6b23b6f 100644
--- a/kernel/rcutree_plugin.h
+++ b/kernel/rcutree_plugin.h
@@ -338,7 +338,7 @@ void rcu_read_unlock_special(struct task_struct *t)
 	int empty;
 	int empty_exp;
 	int empty_exp_now;
-	unsigned long flags;
+	unsigned long flags, irq_disabled_flags;
 	struct list_head *np;
 #ifdef CONFIG_RCU_BOOST
 	struct rt_mutex *rbmp = NULL;
@@ -351,6 +351,7 @@ void rcu_read_unlock_special(struct task_struct *t)
 		return;
 
 	local_irq_save(flags);
+	local_save_flags(irq_disabled_flags);
 
 	/*
 	 * If RCU core is waiting for this CPU to exit critical section,
@@ -414,9 +415,12 @@ void rcu_read_unlock_special(struct task_struct *t)
 							 rnp->grplo,
 							 rnp->grphi,
 							 !!rnp->gp_tasks);
-			rcu_report_unblock_qs_rnp(rnp, flags);
+			rcu_report_unblock_qs_rnp(rnp, irq_disabled_flags);
+			/* irqs remain disabled. */
 		} else {
-			raw_spin_unlock_irqrestore(&rnp->lock, flags);
+			raw_spin_unlock_irqrestore(&rnp->lock,
+						   irq_disabled_flags);
+			/* irqs remain disabled. */
 		}
 
 #ifdef CONFIG_RCU_BOOST
@@ -431,9 +435,8 @@ void rcu_read_unlock_special(struct task_struct *t)
 		 */
 		if (!empty_exp && empty_exp_now)
 			rcu_report_exp_rnp(&rcu_preempt_state, rnp, true);
-	} else {
-		local_irq_restore(flags);
 	}
+	local_irq_restore(flags);
 }
 
 #ifdef CONFIG_RCU_CPU_STALL_VERBOSE
-- 
1.7.4.4


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 4/8] rcu: delay task rcu state cleanup in exit_rcu()
  2013-08-07 10:24 [PATCH 0/8] rcu: Ensure rcu read site is deadlock-immunity Lai Jiangshan
                   ` (2 preceding siblings ...)
  2013-08-07 10:24 ` [PATCH 3/8] rcu: keep irqs disabled " Lai Jiangshan
@ 2013-08-07 10:25 ` Lai Jiangshan
  2013-08-07 10:25 ` [PATCH 5/8] rcu: eliminate deadlock for rcu read site Lai Jiangshan
                   ` (4 subsequent siblings)
  8 siblings, 0 replies; 49+ messages in thread
From: Lai Jiangshan @ 2013-08-07 10:25 UTC (permalink / raw)
  To: Paul E. McKenney, Steven Rostedt, Peter Zijlstra, linux-kernel
  Cc: Lai Jiangshan, Dipankar Sarma

exit_rcu() tries to clean up the task rcu state when the task is exiting.
It did it by calls __rcu_read_unlock().

Actually, calling rcu_read_unlock_special() is enough. This patch defer it
to the rcu_preempt_note_context_switch() of the next schedule().

This patch prepares for the next patch which defers rcu_read_unlock_special()
if irq is disabled when __rcu_read_unlock() is called.
So __rcu_read_unlock() can't work here(it is irq-disabled here)
if the next patch applied.

Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
---
 kernel/rcutree_plugin.h |   11 +++++++----
 1 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
index 6b23b6f..fc8b36f 100644
--- a/kernel/rcutree_plugin.h
+++ b/kernel/rcutree_plugin.h
@@ -942,10 +942,13 @@ void exit_rcu(void)
 
 	if (likely(list_empty(&current->rcu_node_entry)))
 		return;
-	t->rcu_read_lock_nesting = 1;
-	barrier();
-	t->rcu_read_unlock_special = RCU_READ_UNLOCK_BLOCKED;
-	__rcu_read_unlock();
+	WARN_ON_ONCE(!(t->rcu_read_unlock_special | RCU_READ_UNLOCK_BLOCKED));
+	/*
+	 * Task RCU state(rcu_node_entry) of this task will be cleanup by
+	 * the next rcu_preempt_note_context_switch() of the next schedule()
+	 * in the do_exit().
+	 */
+	t->rcu_read_lock_nesting = INT_MIN;
 }
 
 #else /* #ifdef CONFIG_TREE_PREEMPT_RCU */
-- 
1.7.4.4


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 5/8] rcu: eliminate deadlock for rcu read site
  2013-08-07 10:24 [PATCH 0/8] rcu: Ensure rcu read site is deadlock-immunity Lai Jiangshan
                   ` (3 preceding siblings ...)
  2013-08-07 10:25 ` [PATCH 4/8] rcu: delay task rcu state cleanup in exit_rcu() Lai Jiangshan
@ 2013-08-07 10:25 ` Lai Jiangshan
  2013-08-08 20:40   ` Paul E. McKenney
  2013-08-07 10:25 ` [PATCH 6/8] rcu: call rcu_read_unlock_special() in rcu_preempt_check_callbacks() Lai Jiangshan
                   ` (3 subsequent siblings)
  8 siblings, 1 reply; 49+ messages in thread
From: Lai Jiangshan @ 2013-08-07 10:25 UTC (permalink / raw)
  To: Paul E. McKenney, Steven Rostedt, Peter Zijlstra, linux-kernel
  Cc: Lai Jiangshan, Dipankar Sarma

Background)

Although all articles declare that rcu read site is deadlock-immunity.
It is not true for rcu-preempt, it will be deadlock if rcu read site
overlaps with scheduler lock.

ec433f0c, 10f39bb1 and 016a8d5b just partially solve it. But rcu read site
is still not deadlock-immunity. And the problem described in 016a8d5b
is still existed(rcu_read_unlock_special() calls wake_up).

Aim)

We want to fix the problem forever, we want to keep rcu read site
is deadlock-immunity as books say.

How)

The problem is solved by "if rcu_read_unlock_special() is called inside
any lock which can be (chained) nested in rcu_read_unlock_special(),
we defer rcu_read_unlock_special()".
This kind locks include rnp->lock, scheduler locks, perf ctx->lock, locks
in printk()/WARN_ON() and all locks nested in these locks or chained nested
in these locks.

The problem is reduced to "how to distinguish all these locks(context)",
We don't distinguish all these locks, we know that all these locks
should be nested in local_irqs_disable().

we just consider if rcu_read_unlock_special() is called in irqs-disabled
context, it may be called in these suspect locks, we should defer
rcu_read_unlock_special().

The algorithm enlarges the probability of deferring, but the probability
is still very very low.

Deferring does add a small overhead, but it offers us:
	1) really deadlock-immunity for rcu read site
	2) remove the overhead of the irq-work(250 times per second in avg.)

Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
---
 include/linux/rcupdate.h |    2 +-
 kernel/rcupdate.c        |    2 +-
 kernel/rcutree_plugin.h  |   47 +++++++++++++++++++++++++++++++++++++++++----
 3 files changed, 44 insertions(+), 7 deletions(-)

diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 4b14bdc..00b4220 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -180,7 +180,7 @@ extern void synchronize_sched(void);
 
 extern void __rcu_read_lock(void);
 extern void __rcu_read_unlock(void);
-extern void rcu_read_unlock_special(struct task_struct *t);
+extern void rcu_read_unlock_special(struct task_struct *t, bool unlock);
 void synchronize_rcu(void);
 
 /*
diff --git a/kernel/rcupdate.c b/kernel/rcupdate.c
index cce6ba8..33b89a3 100644
--- a/kernel/rcupdate.c
+++ b/kernel/rcupdate.c
@@ -90,7 +90,7 @@ void __rcu_read_unlock(void)
 #endif /* #ifdef CONFIG_PROVE_RCU_DELAY */
 		barrier();  /* assign before ->rcu_read_unlock_special load */
 		if (unlikely(ACCESS_ONCE(t->rcu_read_unlock_special)))
-			rcu_read_unlock_special(t);
+			rcu_read_unlock_special(t, true);
 		barrier();  /* ->rcu_read_unlock_special load before assign */
 		t->rcu_read_lock_nesting = 0;
 	}
diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
index fc8b36f..997b424 100644
--- a/kernel/rcutree_plugin.h
+++ b/kernel/rcutree_plugin.h
@@ -242,15 +242,16 @@ static void rcu_preempt_note_context_switch(int cpu)
 				       ? rnp->gpnum
 				       : rnp->gpnum + 1);
 		raw_spin_unlock_irqrestore(&rnp->lock, flags);
-	} else if (t->rcu_read_lock_nesting < 0 &&
-		   !WARN_ON_ONCE(t->rcu_read_lock_nesting != INT_MIN) &&
-		   t->rcu_read_unlock_special) {
+	} else if (t->rcu_read_lock_nesting == 0 ||
+		   (t->rcu_read_lock_nesting < 0 &&
+		   !WARN_ON_ONCE(t->rcu_read_lock_nesting != INT_MIN))) {
 
 		/*
 		 * Complete exit from RCU read-side critical section on
 		 * behalf of preempted instance of __rcu_read_unlock().
 		 */
-		rcu_read_unlock_special(t);
+		if (t->rcu_read_unlock_special)
+			rcu_read_unlock_special(t, false);
 	}
 
 	/*
@@ -333,7 +334,7 @@ static struct list_head *rcu_next_node_entry(struct task_struct *t,
  * notify RCU core processing or task having blocked during the RCU
  * read-side critical section.
  */
-void rcu_read_unlock_special(struct task_struct *t)
+void rcu_read_unlock_special(struct task_struct *t, bool unlock)
 {
 	int empty;
 	int empty_exp;
@@ -364,6 +365,42 @@ void rcu_read_unlock_special(struct task_struct *t)
 
 	/* Clean up if blocked during RCU read-side critical section. */
 	if (special & RCU_READ_UNLOCK_BLOCKED) {
+		/*
+		 * If rcu read lock overlaps with scheduler lock,
+		 * rcu_read_unlock_special() may lead to deadlock:
+		 *
+		 * rcu_read_lock();
+		 * preempt_schedule[_irq]() (when preemption)
+		 * scheduler lock; (or some other locks can be (chained) nested
+		 *                  in rcu_read_unlock_special()/rnp->lock)
+		 * access and check rcu data
+		 * rcu_read_unlock();
+		 *   rcu_read_unlock_special();
+		 *     wake_up();                 DEAD LOCK
+		 *
+		 * To avoid all these kinds of deadlock, we should quit
+		 * rcu_read_unlock_special() here and defer it to
+		 * rcu_preempt_note_context_switch() or next outmost
+		 * rcu_read_unlock() if we consider this case may happen.
+		 *
+		 * Although we can't know whether current _special()
+		 * is nested in scheduler lock or not. But we know that
+		 * irqs are always disabled in this case. so we just quit
+		 * and defer it to rcu_preempt_note_context_switch()
+		 * when irqs are disabled.
+		 *
+		 * It means we always defer _special() when it is
+		 * nested in irqs disabled context, but
+		 *	(special & RCU_READ_UNLOCK_BLOCKED) &&
+		 *	irqs_disabled_flags(flags)
+		 * is still unlikely to be true.
+		 */
+		if (unlikely(unlock && irqs_disabled_flags(flags))) {
+			set_need_resched();
+			local_irq_restore(flags);
+			return;
+		}
+
 		t->rcu_read_unlock_special &= ~RCU_READ_UNLOCK_BLOCKED;
 
 		/*
-- 
1.7.4.4


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 6/8] rcu: call rcu_read_unlock_special() in rcu_preempt_check_callbacks()
  2013-08-07 10:24 [PATCH 0/8] rcu: Ensure rcu read site is deadlock-immunity Lai Jiangshan
                   ` (4 preceding siblings ...)
  2013-08-07 10:25 ` [PATCH 5/8] rcu: eliminate deadlock for rcu read site Lai Jiangshan
@ 2013-08-07 10:25 ` Lai Jiangshan
  2013-08-07 10:25 ` [PATCH 7/8] rcu: add # of deferred _special() statistics Lai Jiangshan
                   ` (2 subsequent siblings)
  8 siblings, 0 replies; 49+ messages in thread
From: Lai Jiangshan @ 2013-08-07 10:25 UTC (permalink / raw)
  To: Paul E. McKenney, Steven Rostedt, Peter Zijlstra, linux-kernel
  Cc: Lai Jiangshan, Dipankar Sarma

if rcu_read_unlock_special() is deferred, we can invoke it earlier
in the schedule-tick.

Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
---
 kernel/rcutree_plugin.h |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
index 997b424..c9ff9f1 100644
--- a/kernel/rcutree_plugin.h
+++ b/kernel/rcutree_plugin.h
@@ -684,8 +684,11 @@ static void rcu_preempt_check_callbacks(int cpu)
 {
 	struct task_struct *t = current;
 
-	if (t->rcu_read_lock_nesting == 0) {
+	if (t->rcu_read_lock_nesting == 0 ||
+	    t->rcu_read_lock_nesting == INT_MIN) {
 		rcu_preempt_qs(cpu);
+		if (t->rcu_read_unlock_special)
+			rcu_read_unlock_special(t, false);
 		return;
 	}
 	if (t->rcu_read_lock_nesting > 0 &&
-- 
1.7.4.4


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 7/8] rcu: add # of deferred _special() statistics
  2013-08-07 10:24 [PATCH 0/8] rcu: Ensure rcu read site is deadlock-immunity Lai Jiangshan
                   ` (5 preceding siblings ...)
  2013-08-07 10:25 ` [PATCH 6/8] rcu: call rcu_read_unlock_special() in rcu_preempt_check_callbacks() Lai Jiangshan
@ 2013-08-07 10:25 ` Lai Jiangshan
  2013-08-07 16:42   ` Paul E. McKenney
  2013-08-07 10:25 ` [PATCH 8/8] rcu: remove irq work for rsp_wakeup() Lai Jiangshan
  2013-08-07 12:38 ` [PATCH 0/8] rcu: Ensure rcu read site is deadlock-immunity Paul E. McKenney
  8 siblings, 1 reply; 49+ messages in thread
From: Lai Jiangshan @ 2013-08-07 10:25 UTC (permalink / raw)
  To: Paul E. McKenney, Steven Rostedt, Peter Zijlstra, linux-kernel
  Cc: Lai Jiangshan, Dipankar Sarma

Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
---
 kernel/rcutree.h        |    1 +
 kernel/rcutree_plugin.h |    1 +
 kernel/rcutree_trace.c  |    1 +
 3 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/kernel/rcutree.h b/kernel/rcutree.h
index 4a39d36..a5e9643 100644
--- a/kernel/rcutree.h
+++ b/kernel/rcutree.h
@@ -290,6 +290,7 @@ struct rcu_data {
 	unsigned long	n_force_qs_snap;
 					/* did other CPU force QS recently? */
 	long		blimit;		/* Upper limit on a processed batch */
+	unsigned long	n_defer_special;/* # of deferred _special() */
 
 	/* 3) dynticks interface. */
 	struct rcu_dynticks *dynticks;	/* Shared per-CPU dynticks state. */
diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
index c9ff9f1..d828eec 100644
--- a/kernel/rcutree_plugin.h
+++ b/kernel/rcutree_plugin.h
@@ -396,6 +396,7 @@ void rcu_read_unlock_special(struct task_struct *t, bool unlock)
 		 * is still unlikey to be true.
 		 */
 		if (unlikely(unlock && irqs_disabled_flags(flags))) {
+			this_cpu_ptr(&rcu_preempt_data)->n_defer_special++;
 			set_need_resched();
 			local_irq_restore(flags);
 			return;
diff --git a/kernel/rcutree_trace.c b/kernel/rcutree_trace.c
index cf6c174..17d8b2c 100644
--- a/kernel/rcutree_trace.c
+++ b/kernel/rcutree_trace.c
@@ -149,6 +149,7 @@ static void print_one_rcu_data(struct seq_file *m, struct rcu_data *rdp)
 	seq_printf(m, " ci=%lu nci=%lu co=%lu ca=%lu\n",
 		   rdp->n_cbs_invoked, rdp->n_nocbs_invoked,
 		   rdp->n_cbs_orphaned, rdp->n_cbs_adopted);
+	seq_printf(m, " ds=%lu\n", rdp->n_defer_special);
 }
 
 static int show_rcudata(struct seq_file *m, void *v)
-- 
1.7.4.4


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 8/8] rcu: remove irq work for rsp_wakeup()
  2013-08-07 10:24 [PATCH 0/8] rcu: Ensure rcu read site is deadlock-immunity Lai Jiangshan
                   ` (6 preceding siblings ...)
  2013-08-07 10:25 ` [PATCH 7/8] rcu: add # of deferred _special() statistics Lai Jiangshan
@ 2013-08-07 10:25 ` Lai Jiangshan
  2013-08-07 12:38 ` [PATCH 0/8] rcu: Ensure rcu read site is deadlock-immunity Paul E. McKenney
  8 siblings, 0 replies; 49+ messages in thread
From: Lai Jiangshan @ 2013-08-07 10:25 UTC (permalink / raw)
  To: Paul E. McKenney, Steven Rostedt, Peter Zijlstra, linux-kernel
  Cc: Lai Jiangshan, Dipankar Sarma

It is safe to aquire scheduler lock in rnp->lock since the rcu read lock is
always deadlock-immunity(rnp->lock is always can't be nested in scheduler lock)

it partial revert patch 016a8d5b.

Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
---
 kernel/rcutree.c |   17 ++---------------
 kernel/rcutree.h |    1 -
 2 files changed, 2 insertions(+), 16 deletions(-)

diff --git a/kernel/rcutree.c b/kernel/rcutree.c
index e08abb9..6c91edc 100644
--- a/kernel/rcutree.c
+++ b/kernel/rcutree.c
@@ -1524,14 +1524,6 @@ static int __noreturn rcu_gp_kthread(void *arg)
 	}
 }
 
-static void rsp_wakeup(struct irq_work *work)
-{
-	struct rcu_state *rsp = container_of(work, struct rcu_state, wakeup_work);
-
-	/* Wake up rcu_gp_kthread() to start the grace period. */
-	wake_up(&rsp->gp_wq);
-}
-
 /*
  * Start a new RCU grace period if warranted, re-initializing the hierarchy
  * in preparation for detecting the next grace period.  The caller must hold
@@ -1556,12 +1548,8 @@ rcu_start_gp_advanced(struct rcu_state *rsp, struct rcu_node *rnp,
 	}
 	rsp->gp_flags = RCU_GP_FLAG_INIT;
 
-	/*
-	 * We can't do wakeups while holding the rnp->lock, as that
-	 * could cause possible deadlocks with the rq->lock. Deter
-	 * the wakeup to interrupt context.
-	 */
-	irq_work_queue(&rsp->wakeup_work);
+	/* Wake up rcu_gp_kthread() to start the grace period. */
+	wake_up(&rsp->gp_wq);
 }
 
 /*
@@ -3153,7 +3141,6 @@ static void __init rcu_init_one(struct rcu_state *rsp,
 
 	rsp->rda = rda;
 	init_waitqueue_head(&rsp->gp_wq);
-	init_irq_work(&rsp->wakeup_work, rsp_wakeup);
 	rnp = rsp->level[rcu_num_lvls - 1];
 	for_each_possible_cpu(i) {
 		while (i > rnp->grphi)
diff --git a/kernel/rcutree.h b/kernel/rcutree.h
index a5e9643..5892a43 100644
--- a/kernel/rcutree.h
+++ b/kernel/rcutree.h
@@ -449,7 +449,6 @@ struct rcu_state {
 	char *name;				/* Name of structure. */
 	char abbr;				/* Abbreviated name. */
 	struct list_head flavors;		/* List of RCU flavors. */
-	struct irq_work wakeup_work;		/* Postponed wakeups */
 };
 
 /* Values for rcu_state structure's gp_flags field. */
-- 
1.7.4.4


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* Re: [PATCH 0/8] rcu: Ensure rcu read site is deadlock-immunity
  2013-08-07 10:24 [PATCH 0/8] rcu: Ensure rcu read site is deadlock-immunity Lai Jiangshan
                   ` (7 preceding siblings ...)
  2013-08-07 10:25 ` [PATCH 8/8] rcu: remove irq work for rsp_wakeup() Lai Jiangshan
@ 2013-08-07 12:38 ` Paul E. McKenney
  2013-08-07 19:29   ` Carsten Emde
  2013-08-08  0:36   ` Paul E. McKenney
  8 siblings, 2 replies; 49+ messages in thread
From: Paul E. McKenney @ 2013-08-07 12:38 UTC (permalink / raw)
  To: Lai Jiangshan; +Cc: Steven Rostedt, Peter Zijlstra, linux-kernel, C.Emde

On Wed, Aug 07, 2013 at 06:24:56PM +0800, Lai Jiangshan wrote:
> Although all articles declare that rcu read site is deadlock-immunity.
> It is not true for rcu-preempt, it will be deadlock if rcu read site
> overlaps with scheduler lock.

The real rule is that if the scheduler does its outermost rcu_read_unlock()
with one of those locks held, it has to have avoided enabling preemption
through the entire RCU read-side critical section.

That said, avoiding the need for this rule would be a good thing.

How did you test this?  The rcutorture tests will not exercise this.
(Intentionally so, given that it can deadlock!)

> ec433f0c, 10f39bb1 and 016a8d5b just partially solve it. But rcu read site
> is still not deadlock-immunity. And the problem described in 016a8d5b
> is still existed(rcu_read_unlock_special() calls wake_up).
> 
> The problem is fixed in patch5.

This is going to require some serious review and testing.  One requirement
is that RCU priority boosting not persist significantly beyond the
re-enabling of interrupts associated with the irq-disabled lock.  To do
otherwise breaks RCU priority boosting.  At first glance, the added
set_need_resched() might handle this, but that is part of the review
and testing required.

Steven, would you and Carsten be willing to try this and see if it
helps with the issues you are seeing in -rt?  (My guess is "no", since
a deadlock would block forever rather than waking up after a couple
thousand seconds, but worth a try.)

							Thanx, Paul

> Lai Jiangshan (8):
>   rcu: add a warn to rcu_preempt_note_context_switch()
>   rcu: rcu_read_unlock_special() can be nested in irq/softirq 10f39bb1
>   rcu: keep irqs disabled in rcu_read_unlock_special()
>   rcu: delay task rcu state cleanup in exit_rcu()
>   rcu: eliminate rcu read site deadlock
>   rcu: call rcu_read_unlock_special() in rcu_preempt_check_callbacks()
>   rcu: add # of deferred _special() statistics
>   rcu: remove irq work for rsp_wakeup()
> 
>  include/linux/rcupdate.h |    2 +-
>  kernel/rcupdate.c        |    2 +-
>  kernel/rcutree.c         |   17 +--------
>  kernel/rcutree.h         |    2 +-
>  kernel/rcutree_plugin.h  |   82 ++++++++++++++++++++++++++++++++++-----------
>  kernel/rcutree_trace.c   |    1 +
>  6 files changed, 68 insertions(+), 38 deletions(-)
> 
> -- 
> 1.7.4.4
> 


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 7/8] rcu: add # of deferred _special() statistics
  2013-08-07 10:25 ` [PATCH 7/8] rcu: add # of deferred _special() statistics Lai Jiangshan
@ 2013-08-07 16:42   ` Paul E. McKenney
  0 siblings, 0 replies; 49+ messages in thread
From: Paul E. McKenney @ 2013-08-07 16:42 UTC (permalink / raw)
  To: Lai Jiangshan
  Cc: Steven Rostedt, Peter Zijlstra, linux-kernel, Dipankar Sarma

On Wed, Aug 07, 2013 at 06:25:03PM +0800, Lai Jiangshan wrote:
> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
> ---
>  kernel/rcutree.h        |    1 +
>  kernel/rcutree_plugin.h |    1 +
>  kernel/rcutree_trace.c  |    1 +
>  3 files changed, 3 insertions(+), 0 deletions(-)
> 
> diff --git a/kernel/rcutree.h b/kernel/rcutree.h
> index 4a39d36..a5e9643 100644
> --- a/kernel/rcutree.h
> +++ b/kernel/rcutree.h
> @@ -290,6 +290,7 @@ struct rcu_data {
>  	unsigned long	n_force_qs_snap;
>  					/* did other CPU force QS recently? */
>  	long		blimit;		/* Upper limit on a processed batch */
> +	unsigned long	n_defer_special;/* # of deferred _special() */
> 
>  	/* 3) dynticks interface. */
>  	struct rcu_dynticks *dynticks;	/* Shared per-CPU dynticks state. */
> diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
> index c9ff9f1..d828eec 100644
> --- a/kernel/rcutree_plugin.h
> +++ b/kernel/rcutree_plugin.h
> @@ -396,6 +396,7 @@ void rcu_read_unlock_special(struct task_struct *t, bool unlock)
>  		 * is still unlikey to be true.
>  		 */
>  		if (unlikely(unlock && irqs_disabled_flags(flags))) {
> +			this_cpu_ptr(&rcu_preempt_data)->n_defer_special++;
>  			set_need_resched();
>  			local_irq_restore(flags);
>  			return;
> diff --git a/kernel/rcutree_trace.c b/kernel/rcutree_trace.c
> index cf6c174..17d8b2c 100644
> --- a/kernel/rcutree_trace.c
> +++ b/kernel/rcutree_trace.c
> @@ -149,6 +149,7 @@ static void print_one_rcu_data(struct seq_file *m, struct rcu_data *rdp)
>  	seq_printf(m, " ci=%lu nci=%lu co=%lu ca=%lu\n",

The above "\n" needs to be removed.  (Fixed while queueing.)

							Thanx, Paul

>  		   rdp->n_cbs_invoked, rdp->n_nocbs_invoked,
>  		   rdp->n_cbs_orphaned, rdp->n_cbs_adopted);
> +	seq_printf(m, " ds=%lu\n", rdp->n_defer_special);
>  }
> 
>  static int show_rcudata(struct seq_file *m, void *v)
> -- 
> 1.7.4.4
> 


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 0/8] rcu: Ensure rcu read site is deadlock-immunity
  2013-08-07 12:38 ` [PATCH 0/8] rcu: Ensure rcu read site is deadlock-immunity Paul E. McKenney
@ 2013-08-07 19:29   ` Carsten Emde
  2013-08-07 19:52     ` Paul E. McKenney
  2013-08-08  1:17     ` Lai Jiangshan
  2013-08-08  0:36   ` Paul E. McKenney
  1 sibling, 2 replies; 49+ messages in thread
From: Carsten Emde @ 2013-08-07 19:29 UTC (permalink / raw)
  To: paulmck; +Cc: Lai Jiangshan, Steven Rostedt, Peter Zijlstra, linux-kernel

Hi Paul,

>> Although all articles declare that rcu read site is deadlock-immunity.
>> It is not true for rcu-preempt, it will be deadlock if rcu read site
>> overlaps with scheduler lock.
>
> The real rule is that if the scheduler does its outermost rcu_read_unlock()
> with one of those locks held, it has to have avoided enabling preemption
> through the entire RCU read-side critical section.
>
> That said, avoiding the need for this rule would be a good thing.
>
> How did you test this?  The rcutorture tests will not exercise this.
> (Intentionally so, given that it can deadlock!)
>
>> ec433f0c, 10f39bb1 and 016a8d5b just partially solve it. But rcu read site
>> is still not deadlock-immunity. And the problem described in 016a8d5b
>> is still existed(rcu_read_unlock_special() calls wake_up).
>>
>> The problem is fixed in patch5.
>
> This is going to require some serious review and testing.  One requirement
> is that RCU priority boosting not persist significantly beyond the
> re-enabling of interrupts associated with the irq-disabled lock.  To do
> otherwise breaks RCU priority boosting.  At first glance, the added
> set_need_resched() might handle this, but that is part of the review
> and testing required.
>
> Steven, would you and Carsten be willing to try this and see if it
> helps with the issues you are seeing in -rt?  (My guess is "no", since
> a deadlock would block forever rather than waking up after a couple
> thousand seconds, but worth a try.)
Your guess was correct, applying this patch doesn't heal the 
NO_HZ_FULL+PREEMPT_RT_FULL 3.10.4 based system; it still is hanging at 
-> synchronize_rcu -> wait_rcu_gp.

	-Carsten.

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 0/8] rcu: Ensure rcu read site is deadlock-immunity
  2013-08-07 19:29   ` Carsten Emde
@ 2013-08-07 19:52     ` Paul E. McKenney
  2013-08-08  1:17     ` Lai Jiangshan
  1 sibling, 0 replies; 49+ messages in thread
From: Paul E. McKenney @ 2013-08-07 19:52 UTC (permalink / raw)
  To: Carsten Emde; +Cc: Lai Jiangshan, Steven Rostedt, Peter Zijlstra, linux-kernel

On Wed, Aug 07, 2013 at 09:29:07PM +0200, Carsten Emde wrote:
> Hi Paul,
> 
> >>Although all articles declare that rcu read site is deadlock-immunity.
> >>It is not true for rcu-preempt, it will be deadlock if rcu read site
> >>overlaps with scheduler lock.
> >
> >The real rule is that if the scheduler does its outermost rcu_read_unlock()
> >with one of those locks held, it has to have avoided enabling preemption
> >through the entire RCU read-side critical section.
> >
> >That said, avoiding the need for this rule would be a good thing.
> >
> >How did you test this?  The rcutorture tests will not exercise this.
> >(Intentionally so, given that it can deadlock!)
> >
> >>ec433f0c, 10f39bb1 and 016a8d5b just partially solve it. But rcu read site
> >>is still not deadlock-immunity. And the problem described in 016a8d5b
> >>is still existed(rcu_read_unlock_special() calls wake_up).
> >>
> >>The problem is fixed in patch5.
> >
> >This is going to require some serious review and testing.  One requirement
> >is that RCU priority boosting not persist significantly beyond the
> >re-enabling of interrupts associated with the irq-disabled lock.  To do
> >otherwise breaks RCU priority boosting.  At first glance, the added
> >set_need_resched() might handle this, but that is part of the review
> >and testing required.
> >
> >Steven, would you and Carsten be willing to try this and see if it
> >helps with the issues you are seeing in -rt?  (My guess is "no", since
> >a deadlock would block forever rather than waking up after a couple
> >thousand seconds, but worth a try.)
> Your guess was correct, applying this patch doesn't heal the
> NO_HZ_FULL+PREEMPT_RT_FULL 3.10.4 based system; it still is hanging
> at -> synchronize_rcu -> wait_rcu_gp.

I would rather have been wrong, but thank you for trying it out!

							Thanx, Paul


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 0/8] rcu: Ensure rcu read site is deadlock-immunity
  2013-08-07 12:38 ` [PATCH 0/8] rcu: Ensure rcu read site is deadlock-immunity Paul E. McKenney
  2013-08-07 19:29   ` Carsten Emde
@ 2013-08-08  0:36   ` Paul E. McKenney
  2013-08-08  1:47     ` Lai Jiangshan
  1 sibling, 1 reply; 49+ messages in thread
From: Paul E. McKenney @ 2013-08-08  0:36 UTC (permalink / raw)
  To: Lai Jiangshan; +Cc: Steven Rostedt, Peter Zijlstra, linux-kernel, C.Emde

[-- Attachment #1: Type: text/plain, Size: 6894 bytes --]

On Wed, Aug 07, 2013 at 05:38:27AM -0700, Paul E. McKenney wrote:
> On Wed, Aug 07, 2013 at 06:24:56PM +0800, Lai Jiangshan wrote:
> > Although all articles declare that rcu read site is deadlock-immunity.
> > It is not true for rcu-preempt, it will be deadlock if rcu read site
> > overlaps with scheduler lock.
> 
> The real rule is that if the scheduler does its outermost rcu_read_unlock()
> with one of those locks held, it has to have avoided enabling preemption
> through the entire RCU read-side critical section.
> 
> That said, avoiding the need for this rule would be a good thing.
> 
> How did you test this?  The rcutorture tests will not exercise this.
> (Intentionally so, given that it can deadlock!)
> 
> > ec433f0c, 10f39bb1 and 016a8d5b just partially solve it. But rcu read site
> > is still not deadlock-immunity. And the problem described in 016a8d5b
> > is still existed(rcu_read_unlock_special() calls wake_up).
> > 
> > The problem is fixed in patch5.
> 
> This is going to require some serious review and testing.  One requirement
> is that RCU priority boosting not persist significantly beyond the
> re-enabling of interrupts associated with the irq-disabled lock.  To do
> otherwise breaks RCU priority boosting.  At first glance, the added
> set_need_resched() might handle this, but that is part of the review
> and testing required.
> 
> Steven, would you and Carsten be willing to try this and see if it
> helps with the issues you are seeing in -rt?  (My guess is "no", since
> a deadlock would block forever rather than waking up after a couple
> thousand seconds, but worth a try.)

No joy from either Steven or Carsten on the -rt hangs.

I pushed this to -rcu and ran tests.  I hit this in one of the
configurations:

[  393.641012] =================================
[  393.641012] [ INFO: inconsistent lock state ]
[  393.641012] 3.11.0-rc1+ #1 Not tainted
[  393.641012] ---------------------------------
[  393.641012] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
[  393.641012] rcu_torture_rea/697 [HC1[1]:SC0[0]:HE0:SE1] takes:
[  393.641012]  (&lock->wait_lock){?.+...}, at: [<ffffffff818860f3>] rt_mutex_unlock+0x53/0x100
[  393.641012] {HARDIRQ-ON-W} state was registered at:
[  393.641012]   [<ffffffff810aecb1>] __lock_acquire+0x651/0x1d40
[  393.641012]   [<ffffffff810b0a65>] lock_acquire+0x95/0x210
[  393.641012]   [<ffffffff81886d26>] _raw_spin_lock+0x36/0x50
[  393.641012]   [<ffffffff81886329>] rt_mutex_slowlock+0x39/0x170
[  393.641012]   [<ffffffff818864ca>] rt_mutex_lock+0x2a/0x30
[  393.641012]   [<ffffffff810ebc03>] rcu_boost_kthread+0x173/0x800
[  393.641012]   [<ffffffff810759d6>] kthread+0xd6/0xe0
[  393.641012]   [<ffffffff8188f52c>] ret_from_fork+0x7c/0xb0
[  393.641012] irq event stamp: 96581116
[  393.641012] hardirqs last  enabled at (96581115): [<ffffffff81887ba0>] restore_args+0x0/0x30
[  393.641012] hardirqs last disabled at (96581116): [<ffffffff8189022a>] apic_timer_interrupt+0x6a/0x80
[  393.641012] softirqs last  enabled at (96576304): [<ffffffff81051844>] __do_softirq+0x174/0x470
[  393.641012] softirqs last disabled at (96576275): [<ffffffff81051ca6>] irq_exit+0x96/0xc0
[  393.641012] 
[  393.641012] other info that might help us debug this:
[  393.641012]  Possible unsafe locking scenario:
[  393.641012] 
[  393.641012]        CPU0
[  393.641012]        ----
[  393.641012]   lock(&lock->wait_lock);
[  393.641012]   <Interrupt>
[  393.641012]     lock(&lock->wait_lock);
[  393.641012] 
[  393.641012]  *** DEADLOCK ***
[  393.641012] 
[  393.641012] no locks held by rcu_torture_rea/697.
[  393.641012] 
[  393.641012] stack backtrace:
[  393.641012] CPU: 3 PID: 697 Comm: rcu_torture_rea Not tainted 3.11.0-rc1+ #1
[  393.641012] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
[  393.641012]  ffffffff8586fea0 ffff88001fcc3a78 ffffffff8187b4cb ffffffff8104a261
[  393.641012]  ffff88001e1a20c0 ffff88001fcc3ad8 ffffffff818773e4 0000000000000000
[  393.641012]  ffff880000000000 ffff880000000001 ffffffff81010a0a 0000000000000001
[  393.641012] Call Trace:
[  393.641012]  <IRQ>  [<ffffffff8187b4cb>] dump_stack+0x4f/0x84
[  393.641012]  [<ffffffff8104a261>] ? console_unlock+0x291/0x410
[  393.641012]  [<ffffffff818773e4>] print_usage_bug+0x1f5/0x206
[  393.641012]  [<ffffffff81010a0a>] ? save_stack_trace+0x2a/0x50
[  393.641012]  [<ffffffff810ae603>] mark_lock+0x283/0x2e0
[  393.641012]  [<ffffffff810ada10>] ? print_irq_inversion_bug.part.40+0x1f0/0x1f0
[  393.641012]  [<ffffffff810aef66>] __lock_acquire+0x906/0x1d40
[  393.641012]  [<ffffffff810ae94b>] ? __lock_acquire+0x2eb/0x1d40
[  393.641012]  [<ffffffff810ae94b>] ? __lock_acquire+0x2eb/0x1d40
[  393.641012]  [<ffffffff810b0a65>] lock_acquire+0x95/0x210
[  393.641012]  [<ffffffff818860f3>] ? rt_mutex_unlock+0x53/0x100
[  393.641012]  [<ffffffff81886d26>] _raw_spin_lock+0x36/0x50
[  393.641012]  [<ffffffff818860f3>] ? rt_mutex_unlock+0x53/0x100
[  393.641012]  [<ffffffff818860f3>] rt_mutex_unlock+0x53/0x100
[  393.641012]  [<ffffffff810ee3ca>] rcu_read_unlock_special+0x17a/0x2a0
[  393.641012]  [<ffffffff810ee803>] rcu_check_callbacks+0x313/0x950
[  393.641012]  [<ffffffff8107a6bd>] ? hrtimer_run_queues+0x1d/0x180
[  393.641012]  [<ffffffff810abb9d>] ? trace_hardirqs_off+0xd/0x10
[  393.641012]  [<ffffffff8105bae3>] update_process_times+0x43/0x80
[  393.641012]  [<ffffffff810a9801>] tick_sched_handle.isra.10+0x31/0x40
[  393.641012]  [<ffffffff810a98f7>] tick_sched_timer+0x47/0x70
[  393.641012]  [<ffffffff8107941c>] __run_hrtimer+0x7c/0x490
[  393.641012]  [<ffffffff810a260d>] ? ktime_get_update_offsets+0x4d/0xe0
[  393.641012]  [<ffffffff810a98b0>] ? tick_nohz_handler+0xa0/0xa0
[  393.641012]  [<ffffffff8107a017>] hrtimer_interrupt+0x107/0x260
[  393.641012]  [<ffffffff81030173>] local_apic_timer_interrupt+0x33/0x60
[  393.641012]  [<ffffffff8103059e>] smp_apic_timer_interrupt+0x3e/0x60
[  393.641012]  [<ffffffff8189022f>] apic_timer_interrupt+0x6f/0x80
[  393.641012]  <EOI>  [<ffffffff810ee250>] ? rcu_scheduler_starting+0x60/0x60
[  393.641012]  [<ffffffff81072101>] ? __rcu_read_unlock+0x91/0xa0
[  393.641012]  [<ffffffff810e80e3>] rcu_torture_read_unlock+0x33/0x70
[  393.641012]  [<ffffffff810e8f54>] rcu_torture_reader+0xe4/0x450
[  393.641012]  [<ffffffff810e92c0>] ? rcu_torture_reader+0x450/0x450
[  393.641012]  [<ffffffff810e8e70>] ? rcutorture_trace_dump+0x30/0x30
[  393.641012]  [<ffffffff810759d6>] kthread+0xd6/0xe0
[  393.641012]  [<ffffffff818874bb>] ? _raw_spin_unlock_irq+0x2b/0x60
[  393.641012]  [<ffffffff81075900>] ? flush_kthread_worker+0x130/0x130
[  393.641012]  [<ffffffff8188f52c>] ret_from_fork+0x7c/0xb0
[  393.641012]  [<ffffffff81075900>] ? flush_kthread_worker+0x130/0x130

I don't see this without your patches.

.config attached.  The other configurations completed without errors.
Short tests, 30 minutes per configuration.

Thoughts?

							Thanx, Paul

[-- Attachment #2: .config --]
[-- Type: text/plain, Size: 90981 bytes --]

#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 3.11.0-rc1 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_HAVE_LATENCYTOP_SUPPORT=y
CONFIG_MMU=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_CPU_AUTOPROBE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_64_SMP=y
CONFIG_X86_HT=y
CONFIG_ARCH_HWEIGHT_CFLAGS="-fcall-saved-rdi -fcall-saved-rsi -fcall-saved-rdx -fcall-saved-rcx -fcall-saved-r8 -fcall-saved-r9 -fcall-saved-r10 -fcall-saved-r11"
CONFIG_ARCH_CPU_PROBE_RELEASE=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
# CONFIG_FHANDLE is not set
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y
# CONFIG_AUDIT_LOGINUID_IMMUTABLE is not set
CONFIG_HAVE_GENERIC_HARDIRQS=y

#
# IRQ subsystem
#
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y

#
# RCU Subsystem
#
CONFIG_TREE_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
CONFIG_RCU_STALL_COMMON=y
# CONFIG_RCU_USER_QS is not set
CONFIG_RCU_FANOUT=6
CONFIG_RCU_FANOUT_LEAF=6
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_RCU_FAST_NO_HZ is not set
# CONFIG_TREE_RCU_TRACE is not set
CONFIG_RCU_BOOST=y
CONFIG_RCU_BOOST_PRIO=2
CONFIG_RCU_BOOST_DELAY=500
# CONFIG_RCU_NOCB_CPU is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=18
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANTS_PROT_NUMA_PROT_NONE=y
# CONFIG_NUMA_BALANCING is not set
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_CGROUP_FREEZER=y
# CONFIG_CGROUP_DEVICE is not set
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_RESOURCE_COUNTERS=y
# CONFIG_MEMCG is not set
# CONFIG_CGROUP_HUGETLB is not set
# CONFIG_CGROUP_PERF is not set
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
# CONFIG_CFS_BANDWIDTH is not set
# CONFIG_RT_GROUP_SCHED is not set
# CONFIG_BLK_CGROUP is not set
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
# CONFIG_USER_NS is not set
CONFIG_PID_NS=y
CONFIG_NET_NS=y
CONFIG_UIDGID_CONVERTED=y
# CONFIG_UIDGID_STRICT_TYPE_CHECKS is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE="/home/paulmck/rcu-kvm/initrd"
CONFIG_INITRAMFS_ROOT_UID=0
CONFIG_INITRAMFS_ROOT_GID=0
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y
CONFIG_INITRAMFS_COMPRESSION_NONE=y
# CONFIG_INITRAMFS_COMPRESSION_GZIP is not set
# CONFIG_INITRAMFS_COMPRESSION_BZIP2 is not set
# CONFIG_INITRAMFS_COMPRESSION_LZMA is not set
# CONFIG_INITRAMFS_COMPRESSION_XZ is not set
# CONFIG_INITRAMFS_COMPRESSION_LZO is not set
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
# CONFIG_EXPERT is not set
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_PCI_QUIRKS=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_COMPAT_BRK is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
CONFIG_SLUB_CPU_PARTIAL=y
CONFIG_PROFILING=y
CONFIG_TRACEPOINTS=y
# CONFIG_OPROFILE is not set
CONFIG_HAVE_OPROFILE=y
CONFIG_OPROFILE_NMI_TIMER=y
CONFIG_KPROBES=y
# CONFIG_JUMP_LABEL is not set
# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_ARCH_USE_BUILTIN_BSWAP=y
CONFIG_KRETPROBES=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_OPTPROBES=y
CONFIG_HAVE_KPROBES_ON_FTRACE=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_USE_GENERIC_SMP_HELPERS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y
CONFIG_HAVE_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_PERF_EVENTS_NMI=y
CONFIG_HAVE_PERF_REGS=y
CONFIG_HAVE_PERF_USER_STACK_DUMP=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y
CONFIG_HAVE_ALIGNED_STRUCT_PAGE=y
CONFIG_HAVE_CMPXCHG_LOCAL=y
CONFIG_HAVE_CMPXCHG_DOUBLE=y
CONFIG_ARCH_WANT_COMPAT_IPC_PARSE_VERSION=y
CONFIG_ARCH_WANT_OLD_COMPAT_IPC=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_SECCOMP_FILTER=y
CONFIG_HAVE_CONTEXT_TRACKING=y
CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
CONFIG_HAVE_ARCH_SOFT_DIRTY=y
CONFIG_MODULES_USE_ELF_RELA=y
CONFIG_OLD_SIGSUSPEND3=y
CONFIG_COMPAT_OLD_SIGACTION=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
# CONFIG_HAVE_GENERIC_DMA_COHERENT is not set
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
# CONFIG_MODULE_SIG is not set
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_BLK_DEV_BSG=y
# CONFIG_BLK_DEV_BSGLIB is not set
# CONFIG_BLK_DEV_INTEGRITY is not set

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_AIX_PARTITION is not set
CONFIG_OSF_PARTITION=y
CONFIG_AMIGA_PARTITION=y
# CONFIG_ATARI_PARTITION is not set
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_MINIX_SUBPARTITION=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
# CONFIG_LDM_PARTITION is not set
CONFIG_SGI_PARTITION=y
# CONFIG_ULTRIX_PARTITION is not set
CONFIG_SUN_PARTITION=y
CONFIG_KARMA_PARTITION=y
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set
CONFIG_BLOCK_COMPAT=y

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_UNINLINE_SPIN_UNLOCK=y
CONFIG_FREEZER=y

#
# Processor type and features
#
CONFIG_ZONE_DMA=y
CONFIG_SMP=y
CONFIG_X86_MPPARSE=y
CONFIG_X86_EXTENDED_PLATFORM=y
# CONFIG_X86_VSMP is not set
# CONFIG_X86_INTEL_LPSS is not set
CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y
CONFIG_SCHED_OMIT_FRAME_POINTER=y
# CONFIG_HYPERVISOR_GUEST is not set
CONFIG_NO_BOOTMEM=y
# CONFIG_MEMTEST is not set
# CONFIG_MK8 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_MATOM is not set
CONFIG_GENERIC_CPU=y
CONFIG_X86_INTERNODE_CACHE_SHIFT=6
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=64
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_CENTAUR=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_DMI=y
CONFIG_GART_IOMMU=y
CONFIG_CALGARY_IOMMU=y
CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT=y
CONFIG_SWIOTLB=y
CONFIG_IOMMU_HELPER=y
# CONFIG_MAXSMP is not set
CONFIG_NR_CPUS=8
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_COUNT=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_INTEL=y
CONFIG_X86_MCE_AMD=y
CONFIG_X86_MCE_THRESHOLD=y
# CONFIG_X86_MCE_INJECT is not set
CONFIG_X86_THERMAL_VECTOR=y
# CONFIG_I8K is not set
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_AMD=y
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_MICROCODE_INTEL_LIB=y
CONFIG_MICROCODE_INTEL_EARLY=y
CONFIG_MICROCODE_AMD_EARLY=y
CONFIG_MICROCODE_EARLY=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
CONFIG_ARCH_PHYS_ADDR_T_64BIT=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_DIRECT_GBPAGES=y
CONFIG_NUMA=y
CONFIG_AMD_NUMA=y
CONFIG_X86_64_ACPI_NUMA=y
CONFIG_NODES_SPAN_OTHER_NODES=y
# CONFIG_NUMA_EMU is not set
CONFIG_NODES_SHIFT=6
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_PROC_KCORE_TEXT=y
CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_NEED_MULTIPLE_NODES=y
CONFIG_HAVE_MEMORY_PRESENT=y
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
CONFIG_SPARSEMEM_ALLOC_MEM_MAP_TOGETHER=y
CONFIG_SPARSEMEM_VMEMMAP=y
CONFIG_HAVE_MEMBLOCK=y
CONFIG_HAVE_MEMBLOCK_NODE_MAP=y
CONFIG_ARCH_DISCARD_MEMBLOCK=y
# CONFIG_MOVABLE_NODE is not set
# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set
# CONFIG_MEMORY_HOTPLUG is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=999999
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y
# CONFIG_MEMORY_FAILURE is not set
# CONFIG_TRANSPARENT_HUGEPAGE is not set
CONFIG_CROSS_MEMORY_ATTACH=y
# CONFIG_CLEANCACHE is not set
# CONFIG_FRONTSWAP is not set
# CONFIG_ZBUD is not set
CONFIG_X86_CHECK_BIOS_CORRUPTION=y
CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y
CONFIG_X86_RESERVE_LOW=64
CONFIG_MTRR=y
# CONFIG_MTRR_SANITIZER is not set
CONFIG_X86_PAT=y
CONFIG_ARCH_USES_PG_UNCACHED=y
CONFIG_ARCH_RANDOM=y
CONFIG_X86_SMAP=y
CONFIG_EFI=y
# CONFIG_EFI_STUB is not set
CONFIG_SECCOMP=y
# CONFIG_CC_STACKPROTECTOR is not set
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_SCHED_HRTICK=y
CONFIG_KEXEC=y
CONFIG_CRASH_DUMP=y
# CONFIG_KEXEC_JUMP is not set
CONFIG_PHYSICAL_START=0x1000000
CONFIG_RELOCATABLE=y
CONFIG_PHYSICAL_ALIGN=0x1000000
CONFIG_HOTPLUG_CPU=y
# CONFIG_BOOTPARAM_HOTPLUG_CPU0 is not set
# CONFIG_DEBUG_HOTPLUG_CPU0 is not set
# CONFIG_COMPAT_VDSO is not set
# CONFIG_CMDLINE_BOOL is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_USE_PERCPU_NUMA_NODE_ID=y

#
# Power management and ACPI options
#
CONFIG_ARCH_HIBERNATION_HEADER=y
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_HIBERNATE_CALLBACKS=y
CONFIG_HIBERNATION=y
CONFIG_PM_STD_PARTITION=""
CONFIG_PM_SLEEP=y
CONFIG_PM_SLEEP_SMP=y
# CONFIG_PM_AUTOSLEEP is not set
# CONFIG_PM_WAKELOCKS is not set
# CONFIG_PM_RUNTIME is not set
CONFIG_PM=y
CONFIG_PM_DEBUG=y
# CONFIG_PM_ADVANCED_DEBUG is not set
# CONFIG_PM_TEST_SUSPEND is not set
CONFIG_PM_SLEEP_DEBUG=y
CONFIG_PM_TRACE=y
CONFIG_PM_TRACE_RTC=y
# CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_PROCFS=y
# CONFIG_ACPI_PROCFS_POWER is not set
# CONFIG_ACPI_EC_DEBUGFS is not set
CONFIG_ACPI_PROC_EVENT=y
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=y
CONFIG_ACPI_FAN=y
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_I2C=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_HOTPLUG_CPU=y
# CONFIG_ACPI_PROCESSOR_AGGREGATOR is not set
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_NUMA=y
# CONFIG_ACPI_CUSTOM_DSDT is not set
# CONFIG_ACPI_INITRD_TABLE_OVERRIDE is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
# CONFIG_ACPI_PCI_SLOT is not set
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=y
# CONFIG_ACPI_SBS is not set
# CONFIG_ACPI_HED is not set
# CONFIG_ACPI_CUSTOM_METHOD is not set
# CONFIG_ACPI_BGRT is not set
# CONFIG_ACPI_APEI is not set
# CONFIG_SFI is not set

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
CONFIG_CPU_FREQ_GOV_COMMON=y
# CONFIG_CPU_FREQ_STAT is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_GOV_POWERSAVE is not set
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
# CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set

#
# x86 CPU frequency scaling drivers
#
# CONFIG_X86_INTEL_PSTATE is not set
# CONFIG_X86_PCC_CPUFREQ is not set
CONFIG_X86_ACPI_CPUFREQ=y
CONFIG_X86_ACPI_CPUFREQ_CPB=y
# CONFIG_X86_POWERNOW_K8 is not set
# CONFIG_X86_AMD_FREQ_SENSITIVITY is not set
# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
# CONFIG_X86_P4_CLOCKMOD is not set

#
# shared options
#
# CONFIG_X86_SPEEDSTEP_LIB is not set
CONFIG_CPU_IDLE=y
# CONFIG_CPU_IDLE_MULTIPLE_DRIVERS is not set
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y
# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set
# CONFIG_INTEL_IDLE is not set

#
# Memory power savings
#
# CONFIG_I7300_IDLE is not set

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCIEPORTBUS=y
# CONFIG_HOTPLUG_PCI_PCIE is not set
CONFIG_PCIEAER=y
# CONFIG_PCIE_ECRC is not set
# CONFIG_PCIEAER_INJECT is not set
CONFIG_PCIEASPM=y
# CONFIG_PCIEASPM_DEBUG is not set
CONFIG_PCIEASPM_DEFAULT=y
# CONFIG_PCIEASPM_POWERSAVE is not set
# CONFIG_PCIEASPM_PERFORMANCE is not set
CONFIG_ARCH_SUPPORTS_MSI=y
CONFIG_PCI_MSI=y
# CONFIG_PCI_DEBUG is not set
# CONFIG_PCI_REALLOC_ENABLE_AUTO is not set
# CONFIG_PCI_STUB is not set
CONFIG_HT_IRQ=y
CONFIG_PCI_ATS=y
# CONFIG_PCI_IOV is not set
CONFIG_PCI_PRI=y
CONFIG_PCI_PASID=y
# CONFIG_PCI_IOAPIC is not set
CONFIG_PCI_LABEL=y

#
# PCI host controller drivers
#
CONFIG_ISA_DMA_API=y
CONFIG_AMD_NB=y
CONFIG_PCCARD=y
CONFIG_PCMCIA=y
CONFIG_PCMCIA_LOAD_CIS=y
CONFIG_CARDBUS=y

#
# PC-card bridges
#
CONFIG_YENTA=y
CONFIG_YENTA_O2=y
CONFIG_YENTA_RICOH=y
CONFIG_YENTA_TI=y
CONFIG_YENTA_ENE_TUNE=y
CONFIG_YENTA_TOSHIBA=y
# CONFIG_PD6729 is not set
# CONFIG_I82092 is not set
CONFIG_PCCARD_NONSTATIC=y
CONFIG_HOTPLUG_PCI=y
# CONFIG_HOTPLUG_PCI_ACPI is not set
# CONFIG_HOTPLUG_PCI_CPCI is not set
# CONFIG_HOTPLUG_PCI_SHPC is not set
# CONFIG_RAPIDIO is not set

#
# Executable file formats / Emulations
#
CONFIG_BINFMT_ELF=y
CONFIG_COMPAT_BINFMT_ELF=y
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_BINFMT_SCRIPT=y
# CONFIG_HAVE_AOUT is not set
CONFIG_BINFMT_MISC=y
CONFIG_COREDUMP=y
CONFIG_IA32_EMULATION=y
# CONFIG_IA32_AOUT is not set
# CONFIG_X86_X32 is not set
CONFIG_COMPAT=y
CONFIG_COMPAT_FOR_U64_ALIGNMENT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_KEYS_COMPAT=y
CONFIG_HAVE_TEXT_POKE_SMP=y
CONFIG_X86_DEV_DMA_OPS=y
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_DIAG is not set
CONFIG_UNIX=y
# CONFIG_UNIX_DIAG is not set
CONFIG_XFRM=y
CONFIG_XFRM_ALGO=y
CONFIG_XFRM_USER=y
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_XFRM_STATISTICS is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
# CONFIG_IP_FIB_TRIE_STATS is not set
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_VERBOSE=y
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE_DEMUX is not set
CONFIG_NET_IP_TUNNEL=y
CONFIG_IP_MROUTE=y
# CONFIG_IP_MROUTE_MULTIPLE_TABLES is not set
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
CONFIG_INET_TUNNEL=y
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
CONFIG_INET_LRO=y
# CONFIG_INET_DIAG is not set
CONFIG_TCP_CONG_ADVANCED=y
# CONFIG_TCP_CONG_BIC is not set
CONFIG_TCP_CONG_CUBIC=y
# CONFIG_TCP_CONG_WESTWOOD is not set
# CONFIG_TCP_CONG_HTCP is not set
# CONFIG_TCP_CONG_HSTCP is not set
# CONFIG_TCP_CONG_HYBLA is not set
# CONFIG_TCP_CONG_VEGAS is not set
# CONFIG_TCP_CONG_SCALABLE is not set
# CONFIG_TCP_CONG_LP is not set
# CONFIG_TCP_CONG_VENO is not set
# CONFIG_TCP_CONG_YEAH is not set
# CONFIG_TCP_CONG_ILLINOIS is not set
CONFIG_DEFAULT_CUBIC=y
# CONFIG_DEFAULT_RENO is not set
CONFIG_DEFAULT_TCP_CONG="cubic"
CONFIG_TCP_MD5SIG=y
CONFIG_IPV6=y
# CONFIG_IPV6_PRIVACY is not set
# CONFIG_IPV6_ROUTER_PREF is not set
# CONFIG_IPV6_OPTIMISTIC_DAD is not set
CONFIG_INET6_AH=y
CONFIG_INET6_ESP=y
# CONFIG_INET6_IPCOMP is not set
# CONFIG_IPV6_MIP6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
CONFIG_INET6_XFRM_MODE_TRANSPORT=y
CONFIG_INET6_XFRM_MODE_TUNNEL=y
CONFIG_INET6_XFRM_MODE_BEET=y
# CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
CONFIG_IPV6_SIT=y
# CONFIG_IPV6_SIT_6RD is not set
CONFIG_IPV6_NDISC_NODETYPE=y
# CONFIG_IPV6_TUNNEL is not set
# CONFIG_IPV6_GRE is not set
# CONFIG_IPV6_MULTIPLE_TABLES is not set
# CONFIG_IPV6_MROUTE is not set
CONFIG_NETLABEL=y
CONFIG_NETWORK_SECMARK=y
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
# CONFIG_NETFILTER_ADVANCED is not set

#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=y
CONFIG_NETFILTER_NETLINK_LOG=y
CONFIG_NF_CONNTRACK=y
CONFIG_NF_CONNTRACK_SECMARK=y
CONFIG_NF_CONNTRACK_PROCFS=y
CONFIG_NF_CONNTRACK_FTP=y
CONFIG_NF_CONNTRACK_IRC=y
# CONFIG_NF_CONNTRACK_NETBIOS_NS is not set
CONFIG_NF_CONNTRACK_SIP=y
CONFIG_NF_CT_NETLINK=y
CONFIG_NF_NAT=m
CONFIG_NF_NAT_NEEDED=y
# CONFIG_NF_NAT_AMANDA is not set
CONFIG_NF_NAT_FTP=m
CONFIG_NF_NAT_IRC=m
CONFIG_NF_NAT_SIP=m
# CONFIG_NF_NAT_TFTP is not set
CONFIG_NETFILTER_XTABLES=y

#
# Xtables combined modules
#
CONFIG_NETFILTER_XT_MARK=m

#
# Xtables targets
#
CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=y
CONFIG_NETFILTER_XT_TARGET_LOG=m
# CONFIG_NETFILTER_XT_TARGET_NETMAP is not set
CONFIG_NETFILTER_XT_TARGET_NFLOG=y
# CONFIG_NETFILTER_XT_TARGET_REDIRECT is not set
CONFIG_NETFILTER_XT_TARGET_SECMARK=y
CONFIG_NETFILTER_XT_TARGET_TCPMSS=y

#
# Xtables matches
#
CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y
CONFIG_NETFILTER_XT_MATCH_POLICY=y
CONFIG_NETFILTER_XT_MATCH_STATE=y
# CONFIG_IP_SET is not set
# CONFIG_IP_VS is not set

#
# IP: Netfilter Configuration
#
CONFIG_NF_DEFRAG_IPV4=y
CONFIG_NF_CONNTRACK_IPV4=y
CONFIG_NF_CONNTRACK_PROC_COMPAT=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_ULOG=y
CONFIG_NF_NAT_IPV4=m
CONFIG_IP_NF_TARGET_MASQUERADE=m
# CONFIG_NF_NAT_PPTP is not set
# CONFIG_NF_NAT_H323 is not set
CONFIG_IP_NF_MANGLE=y
# CONFIG_IP_NF_RAW is not set

#
# IPv6: Netfilter Configuration
#
CONFIG_NF_DEFRAG_IPV6=y
CONFIG_NF_CONNTRACK_IPV6=y
CONFIG_IP6_NF_IPTABLES=y
CONFIG_IP6_NF_MATCH_IPV6HEADER=y
CONFIG_IP6_NF_FILTER=y
CONFIG_IP6_NF_TARGET_REJECT=y
CONFIG_IP6_NF_MANGLE=y
# CONFIG_IP6_NF_RAW is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_L2TP is not set
# CONFIG_BRIDGE is not set
CONFIG_HAVE_NET_DSA=y
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
CONFIG_NET_SCHED=y

#
# Queueing/Scheduling
#
# CONFIG_NET_SCH_CBQ is not set
# CONFIG_NET_SCH_HTB is not set
# CONFIG_NET_SCH_HFSC is not set
# CONFIG_NET_SCH_PRIO is not set
# CONFIG_NET_SCH_MULTIQ is not set
# CONFIG_NET_SCH_RED is not set
# CONFIG_NET_SCH_SFB is not set
# CONFIG_NET_SCH_SFQ is not set
# CONFIG_NET_SCH_TEQL is not set
# CONFIG_NET_SCH_TBF is not set
# CONFIG_NET_SCH_GRED is not set
# CONFIG_NET_SCH_DSMARK is not set
# CONFIG_NET_SCH_NETEM is not set
# CONFIG_NET_SCH_DRR is not set
# CONFIG_NET_SCH_MQPRIO is not set
# CONFIG_NET_SCH_CHOKE is not set
# CONFIG_NET_SCH_QFQ is not set
# CONFIG_NET_SCH_CODEL is not set
# CONFIG_NET_SCH_FQ_CODEL is not set
# CONFIG_NET_SCH_INGRESS is not set
# CONFIG_NET_SCH_PLUG is not set

#
# Classification
#
CONFIG_NET_CLS=y
# CONFIG_NET_CLS_BASIC is not set
# CONFIG_NET_CLS_TCINDEX is not set
# CONFIG_NET_CLS_ROUTE4 is not set
# CONFIG_NET_CLS_FW is not set
# CONFIG_NET_CLS_U32 is not set
# CONFIG_NET_CLS_RSVP is not set
# CONFIG_NET_CLS_RSVP6 is not set
# CONFIG_NET_CLS_FLOW is not set
# CONFIG_NET_CLS_CGROUP is not set
CONFIG_NET_EMATCH=y
CONFIG_NET_EMATCH_STACK=32
# CONFIG_NET_EMATCH_CMP is not set
# CONFIG_NET_EMATCH_NBYTE is not set
# CONFIG_NET_EMATCH_U32 is not set
# CONFIG_NET_EMATCH_META is not set
# CONFIG_NET_EMATCH_TEXT is not set
CONFIG_NET_CLS_ACT=y
# CONFIG_NET_ACT_POLICE is not set
# CONFIG_NET_ACT_GACT is not set
# CONFIG_NET_ACT_MIRRED is not set
# CONFIG_NET_ACT_IPT is not set
# CONFIG_NET_ACT_NAT is not set
# CONFIG_NET_ACT_PEDIT is not set
# CONFIG_NET_ACT_SIMP is not set
# CONFIG_NET_ACT_SKBEDIT is not set
# CONFIG_NET_ACT_CSUM is not set
CONFIG_NET_SCH_FIFO=y
# CONFIG_DCB is not set
CONFIG_DNS_RESOLVER=y
# CONFIG_BATMAN_ADV is not set
# CONFIG_OPENVSWITCH is not set
# CONFIG_VSOCKETS is not set
# CONFIG_NETLINK_MMAP is not set
# CONFIG_NETLINK_DIAG is not set
# CONFIG_NET_MPLS_GSO is not set
CONFIG_RPS=y
CONFIG_RFS_ACCEL=y
CONFIG_XPS=y
# CONFIG_NETPRIO_CGROUP is not set
CONFIG_NET_LL_RX_POLL=y
CONFIG_BQL=y
# CONFIG_BPF_JIT is not set
CONFIG_NET_FLOW_LIMIT=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NET_TCPPROBE is not set
# CONFIG_NET_DROP_MONITOR is not set
CONFIG_HAMRADIO=y

#
# Packet Radio protocols
#
# CONFIG_AX25 is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
CONFIG_FIB_RULES=y
CONFIG_WIRELESS=y
CONFIG_CFG80211=y
# CONFIG_NL80211_TESTMODE is not set
# CONFIG_CFG80211_DEVELOPER_WARNINGS is not set
# CONFIG_CFG80211_REG_DEBUG is not set
CONFIG_CFG80211_DEFAULT_PS=y
# CONFIG_CFG80211_DEBUGFS is not set
# CONFIG_CFG80211_INTERNAL_REGDB is not set
# CONFIG_CFG80211_WEXT is not set
# CONFIG_LIB80211 is not set
CONFIG_MAC80211=y
CONFIG_MAC80211_HAS_RC=y
CONFIG_MAC80211_RC_MINSTREL=y
CONFIG_MAC80211_RC_MINSTREL_HT=y
CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y
CONFIG_MAC80211_RC_DEFAULT="minstrel_ht"
# CONFIG_MAC80211_MESH is not set
CONFIG_MAC80211_LEDS=y
# CONFIG_MAC80211_DEBUGFS is not set
# CONFIG_MAC80211_MESSAGE_TRACING is not set
# CONFIG_MAC80211_DEBUG_MENU is not set
# CONFIG_WIMAX is not set
CONFIG_RFKILL=y
CONFIG_RFKILL_LEDS=y
CONFIG_RFKILL_INPUT=y
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set
# CONFIG_NFC is not set
CONFIG_HAVE_BPF_JIT=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"
# CONFIG_DEVTMPFS is not set
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
CONFIG_FW_LOADER_USER_HELPER=y
# CONFIG_DEBUG_DRIVER is not set
CONFIG_DEBUG_DEVRES=y
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_GENERIC_CPU_DEVICES is not set
CONFIG_DMA_SHARED_BUFFER=y

#
# Bus devices
#
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
# CONFIG_MTD is not set
# CONFIG_PARPORT is not set
CONFIG_PNP=y
CONFIG_PNP_DEBUG_MESSAGES=y

#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_DEV_PCIESSD_MTIP32XX is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_DRBD is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_NVME is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_VIRTIO_BLK is not set
# CONFIG_BLK_DEV_HD is not set
# CONFIG_BLK_DEV_RBD is not set
# CONFIG_BLK_DEV_RSXX is not set

#
# Misc devices
#
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_AD525X_DPOT is not set
# CONFIG_DUMMY_IRQ is not set
# CONFIG_IBM_ASM is not set
# CONFIG_PHANTOM is not set
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set
# CONFIG_ICS932S401 is not set
# CONFIG_ATMEL_SSC is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_HP_ILO is not set
# CONFIG_APDS9802ALS is not set
# CONFIG_ISL29003 is not set
# CONFIG_ISL29020 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_SENSORS_BH1780 is not set
# CONFIG_SENSORS_BH1770 is not set
# CONFIG_SENSORS_APDS990X is not set
# CONFIG_HMC6352 is not set
# CONFIG_DS1682 is not set
# CONFIG_BMP085_I2C is not set
# CONFIG_PCH_PHUB is not set
# CONFIG_USB_SWITCH_FSA9480 is not set
# CONFIG_SRAM is not set
# CONFIG_C2PORT is not set

#
# EEPROM support
#
# CONFIG_EEPROM_AT24 is not set
# CONFIG_EEPROM_LEGACY is not set
# CONFIG_EEPROM_MAX6875 is not set
# CONFIG_EEPROM_93CX6 is not set
# CONFIG_CB710_CORE is not set

#
# Texas Instruments shared transport line discipline
#
# CONFIG_SENSORS_LIS3_I2C is not set

#
# Altera FPGA firmware download module
#
# CONFIG_ALTERA_STAPL is not set
# CONFIG_VMWARE_VMCI is not set
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=y
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=y
# CONFIG_CHR_DEV_SCH is not set
# CONFIG_SCSI_MULTI_LUN is not set
CONFIG_SCSI_CONSTANTS=y
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set

#
# SCSI Transports
#
CONFIG_SCSI_SPI_ATTRS=y
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
# CONFIG_SCSI_LOWLEVEL is not set
# CONFIG_SCSI_LOWLEVEL_PCMCIA is not set
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_VERBOSE_ERROR=y
CONFIG_ATA_ACPI=y
# CONFIG_SATA_ZPODD is not set
CONFIG_SATA_PMP=y

#
# Controllers with non-SFF native interface
#
CONFIG_SATA_AHCI=y
# CONFIG_SATA_AHCI_PLATFORM is not set
# CONFIG_SATA_INIC162X is not set
# CONFIG_SATA_ACARD_AHCI is not set
# CONFIG_SATA_SIL24 is not set
CONFIG_ATA_SFF=y

#
# SFF controllers with custom DMA interface
#
# CONFIG_PDC_ADMA is not set
# CONFIG_SATA_QSTOR is not set
# CONFIG_SATA_SX4 is not set
CONFIG_ATA_BMDMA=y

#
# SATA SFF controllers with BMDMA
#
CONFIG_ATA_PIIX=y
# CONFIG_SATA_HIGHBANK is not set
# CONFIG_SATA_MV is not set
# CONFIG_SATA_NV is not set
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_RCAR is not set
# CONFIG_SATA_SIL is not set
# CONFIG_SATA_SIS is not set
# CONFIG_SATA_SVW is not set
# CONFIG_SATA_ULI is not set
# CONFIG_SATA_VIA is not set
# CONFIG_SATA_VITESSE is not set

#
# PATA SFF controllers with BMDMA
#
# CONFIG_PATA_ALI is not set
CONFIG_PATA_AMD=y
# CONFIG_PATA_ARASAN_CF is not set
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_ATP867X is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CS5536 is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT8213 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_JMICRON is not set
# CONFIG_PATA_MARVELL is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NINJA32 is not set
# CONFIG_PATA_NS87415 is not set
CONFIG_PATA_OLDPIIX=y
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PDC2027X is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RDC is not set
# CONFIG_PATA_SC1200 is not set
CONFIG_PATA_SCH=y
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not set
# CONFIG_PATA_TOSHIBA is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set

#
# PIO-only SFF controllers
#
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_PCMCIA is not set
# CONFIG_PATA_RZ1000 is not set

#
# Generic fallback / legacy drivers
#
# CONFIG_PATA_ACPI is not set
# CONFIG_ATA_GENERIC is not set
# CONFIG_PATA_LEGACY is not set
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_AUTODETECT=y
# CONFIG_MD_LINEAR is not set
# CONFIG_MD_RAID0 is not set
# CONFIG_MD_RAID1 is not set
# CONFIG_MD_RAID10 is not set
# CONFIG_MD_RAID456 is not set
# CONFIG_MD_MULTIPATH is not set
# CONFIG_MD_FAULTY is not set
# CONFIG_BCACHE is not set
CONFIG_BLK_DEV_DM=y
# CONFIG_DM_DEBUG is not set
# CONFIG_DM_CRYPT is not set
# CONFIG_DM_SNAPSHOT is not set
# CONFIG_DM_THIN_PROVISIONING is not set
# CONFIG_DM_CACHE is not set
CONFIG_DM_MIRROR=y
# CONFIG_DM_RAID is not set
# CONFIG_DM_LOG_USERSPACE is not set
CONFIG_DM_ZERO=y
# CONFIG_DM_MULTIPATH is not set
# CONFIG_DM_DELAY is not set
# CONFIG_DM_UEVENT is not set
# CONFIG_DM_FLAKEY is not set
# CONFIG_DM_VERITY is not set
# CONFIG_DM_SWITCH is not set
# CONFIG_TARGET_CORE is not set
# CONFIG_FUSION is not set

#
# IEEE 1394 (FireWire) support
#
# CONFIG_FIREWIRE is not set
# CONFIG_FIREWIRE_NOSY is not set
# CONFIG_I2O is not set
CONFIG_MACINTOSH_DRIVERS=y
CONFIG_MAC_EMUMOUSEBTN=y
CONFIG_NETDEVICES=y
CONFIG_MII=y
CONFIG_NET_CORE=y
# CONFIG_BONDING is not set
# CONFIG_DUMMY is not set
# CONFIG_EQUALIZER is not set
# CONFIG_NET_FC is not set
# CONFIG_IFB is not set
# CONFIG_NET_TEAM is not set
# CONFIG_MACVLAN is not set
# CONFIG_VXLAN is not set
CONFIG_NETCONSOLE=y
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y
# CONFIG_TUN is not set
# CONFIG_VETH is not set
# CONFIG_VIRTIO_NET is not set
# CONFIG_NLMON is not set
# CONFIG_ARCNET is not set

#
# CAIF transport drivers
#
# CONFIG_VHOST_NET is not set

#
# Distributed Switch Architecture drivers
#
# CONFIG_NET_DSA_MV88E6XXX is not set
# CONFIG_NET_DSA_MV88E6060 is not set
# CONFIG_NET_DSA_MV88E6XXX_NEED_PPU is not set
# CONFIG_NET_DSA_MV88E6131 is not set
# CONFIG_NET_DSA_MV88E6123_61_65 is not set
CONFIG_ETHERNET=y
CONFIG_NET_VENDOR_3COM=y
# CONFIG_PCMCIA_3C574 is not set
# CONFIG_PCMCIA_3C589 is not set
# CONFIG_VORTEX is not set
# CONFIG_TYPHOON is not set
CONFIG_NET_VENDOR_ADAPTEC=y
# CONFIG_ADAPTEC_STARFIRE is not set
CONFIG_NET_VENDOR_ALTEON=y
# CONFIG_ACENIC is not set
CONFIG_NET_VENDOR_AMD=y
# CONFIG_AMD8111_ETH is not set
# CONFIG_PCNET32 is not set
# CONFIG_PCMCIA_NMCLAN is not set
CONFIG_NET_VENDOR_ARC=y
CONFIG_NET_VENDOR_ATHEROS=y
# CONFIG_ATL2 is not set
# CONFIG_ATL1 is not set
# CONFIG_ATL1E is not set
# CONFIG_ATL1C is not set
# CONFIG_ALX is not set
CONFIG_NET_CADENCE=y
# CONFIG_ARM_AT91_ETHER is not set
# CONFIG_MACB is not set
CONFIG_NET_VENDOR_BROADCOM=y
# CONFIG_B44 is not set
# CONFIG_BNX2 is not set
# CONFIG_CNIC is not set
CONFIG_TIGON3=y
# CONFIG_BNX2X is not set
CONFIG_NET_VENDOR_BROCADE=y
# CONFIG_BNA is not set
# CONFIG_NET_CALXEDA_XGMAC is not set
CONFIG_NET_VENDOR_CHELSIO=y
# CONFIG_CHELSIO_T1 is not set
# CONFIG_CHELSIO_T3 is not set
# CONFIG_CHELSIO_T4 is not set
# CONFIG_CHELSIO_T4VF is not set
CONFIG_NET_VENDOR_CISCO=y
# CONFIG_ENIC is not set
# CONFIG_DNET is not set
CONFIG_NET_VENDOR_DEC=y
CONFIG_NET_TULIP=y
# CONFIG_DE2104X is not set
# CONFIG_TULIP is not set
# CONFIG_DE4X5 is not set
# CONFIG_WINBOND_840 is not set
# CONFIG_DM9102 is not set
# CONFIG_ULI526X is not set
# CONFIG_PCMCIA_XIRCOM is not set
CONFIG_NET_VENDOR_DLINK=y
# CONFIG_DL2K is not set
# CONFIG_SUNDANCE is not set
CONFIG_NET_VENDOR_EMULEX=y
# CONFIG_BE2NET is not set
CONFIG_NET_VENDOR_EXAR=y
# CONFIG_S2IO is not set
# CONFIG_VXGE is not set
CONFIG_NET_VENDOR_FUJITSU=y
# CONFIG_PCMCIA_FMVJ18X is not set
CONFIG_NET_VENDOR_HP=y
# CONFIG_HP100 is not set
CONFIG_NET_VENDOR_INTEL=y
CONFIG_E100=y
CONFIG_E1000=y
# CONFIG_E1000E is not set
# CONFIG_IGB is not set
# CONFIG_IGBVF is not set
# CONFIG_IXGB is not set
# CONFIG_IXGBE is not set
# CONFIG_IXGBEVF is not set
CONFIG_NET_VENDOR_I825XX=y
# CONFIG_IP1000 is not set
# CONFIG_JME is not set
CONFIG_NET_VENDOR_MARVELL=y
# CONFIG_MVMDIO is not set
# CONFIG_SKGE is not set
CONFIG_SKY2=y
# CONFIG_SKY2_DEBUG is not set
CONFIG_NET_VENDOR_MELLANOX=y
# CONFIG_MLX4_EN is not set
# CONFIG_MLX4_CORE is not set
# CONFIG_MLX5_CORE is not set
CONFIG_NET_VENDOR_MICREL=y
# CONFIG_KS8851_MLL is not set
# CONFIG_KSZ884X_PCI is not set
CONFIG_NET_VENDOR_MYRI=y
# CONFIG_MYRI10GE is not set
# CONFIG_FEALNX is not set
CONFIG_NET_VENDOR_NATSEMI=y
# CONFIG_NATSEMI is not set
# CONFIG_NS83820 is not set
CONFIG_NET_VENDOR_8390=y
# CONFIG_PCMCIA_AXNET is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_PCMCIA_PCNET is not set
CONFIG_NET_VENDOR_NVIDIA=y
CONFIG_FORCEDETH=y
CONFIG_NET_VENDOR_OKI=y
# CONFIG_PCH_GBE is not set
# CONFIG_ETHOC is not set
CONFIG_NET_PACKET_ENGINE=y
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
CONFIG_NET_VENDOR_QLOGIC=y
# CONFIG_QLA3XXX is not set
# CONFIG_QLCNIC is not set
# CONFIG_QLGE is not set
# CONFIG_NETXEN_NIC is not set
CONFIG_NET_VENDOR_REALTEK=y
# CONFIG_8139CP is not set
CONFIG_8139TOO=y
CONFIG_8139TOO_PIO=y
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_8139_OLD_RX_RESET is not set
# CONFIG_R8169 is not set
# CONFIG_SH_ETH is not set
CONFIG_NET_VENDOR_RDC=y
# CONFIG_R6040 is not set
CONFIG_NET_VENDOR_SEEQ=y
CONFIG_NET_VENDOR_SILAN=y
# CONFIG_SC92031 is not set
CONFIG_NET_VENDOR_SIS=y
# CONFIG_SIS900 is not set
# CONFIG_SIS190 is not set
# CONFIG_SFC is not set
CONFIG_NET_VENDOR_SMSC=y
# CONFIG_PCMCIA_SMC91C92 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SMSC911X is not set
# CONFIG_SMSC9420 is not set
CONFIG_NET_VENDOR_STMICRO=y
# CONFIG_STMMAC_ETH is not set
CONFIG_NET_VENDOR_SUN=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NIU is not set
CONFIG_NET_VENDOR_TEHUTI=y
# CONFIG_TEHUTI is not set
CONFIG_NET_VENDOR_TI=y
# CONFIG_TLAN is not set
CONFIG_NET_VENDOR_VIA=y
# CONFIG_VIA_RHINE is not set
# CONFIG_VIA_VELOCITY is not set
CONFIG_NET_VENDOR_WIZNET=y
# CONFIG_WIZNET_W5100 is not set
# CONFIG_WIZNET_W5300 is not set
CONFIG_NET_VENDOR_XIRCOM=y
# CONFIG_PCMCIA_XIRC2PS is not set
CONFIG_FDDI=y
# CONFIG_DEFXX is not set
# CONFIG_SKFP is not set
# CONFIG_HIPPI is not set
# CONFIG_NET_SB1000 is not set
CONFIG_PHYLIB=y

#
# MII PHY device drivers
#
# CONFIG_AT803X_PHY is not set
# CONFIG_AMD_PHY is not set
# CONFIG_MARVELL_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_QSEMI_PHY is not set
# CONFIG_LXT_PHY is not set
# CONFIG_CICADA_PHY is not set
# CONFIG_VITESSE_PHY is not set
# CONFIG_SMSC_PHY is not set
# CONFIG_BROADCOM_PHY is not set
# CONFIG_BCM87XX_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_REALTEK_PHY is not set
# CONFIG_NATIONAL_PHY is not set
# CONFIG_STE10XP is not set
# CONFIG_LSI_ET1011C_PHY is not set
# CONFIG_MICREL_PHY is not set
# CONFIG_FIXED_PHY is not set
# CONFIG_MDIO_BITBANG is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set

#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_RTL8152 is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_HSO is not set
# CONFIG_USB_IPHETH is not set
CONFIG_WLAN=y
# CONFIG_PCMCIA_RAYCS is not set
# CONFIG_LIBERTAS_THINFIRM is not set
# CONFIG_AIRO is not set
# CONFIG_ATMEL is not set
# CONFIG_AT76C50X_USB is not set
# CONFIG_AIRO_CS is not set
# CONFIG_PCMCIA_WL3501 is not set
# CONFIG_PRISM54 is not set
# CONFIG_USB_ZD1201 is not set
# CONFIG_USB_NET_RNDIS_WLAN is not set
# CONFIG_RTL8180 is not set
# CONFIG_RTL8187 is not set
# CONFIG_ADM8211 is not set
# CONFIG_MAC80211_HWSIM is not set
# CONFIG_MWL8K is not set
# CONFIG_ATH_CARDS is not set
# CONFIG_B43 is not set
# CONFIG_B43LEGACY is not set
# CONFIG_BRCMFMAC is not set
# CONFIG_HOSTAP is not set
# CONFIG_IPW2100 is not set
# CONFIG_IWLWIFI is not set
# CONFIG_IWL4965 is not set
# CONFIG_IWL3945 is not set
# CONFIG_LIBERTAS is not set
# CONFIG_P54_COMMON is not set
# CONFIG_RT2X00 is not set
# CONFIG_RTLWIFI is not set
# CONFIG_WL_TI is not set
# CONFIG_ZD1211RW is not set
# CONFIG_MWIFIEX is not set
# CONFIG_CW1200 is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
# CONFIG_WAN is not set
# CONFIG_VMXNET3 is not set
# CONFIG_ISDN is not set

#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_FF_MEMLESS=y
CONFIG_INPUT_POLLDEV=y
CONFIG_INPUT_SPARSEKMAP=y
# CONFIG_INPUT_MATRIXKMAP is not set

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ADP5588 is not set
# CONFIG_KEYBOARD_ADP5589 is not set
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_QT1070 is not set
# CONFIG_KEYBOARD_QT2160 is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_TCA6416 is not set
# CONFIG_KEYBOARD_TCA8418 is not set
# CONFIG_KEYBOARD_LM8323 is not set
# CONFIG_KEYBOARD_LM8333 is not set
# CONFIG_KEYBOARD_MAX7359 is not set
# CONFIG_KEYBOARD_MCS is not set
# CONFIG_KEYBOARD_MPR121 is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_OPENCORES is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_CYPRESS=y
CONFIG_MOUSE_PS2_LIFEBOOK=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
# CONFIG_MOUSE_PS2_ELANTECH is not set
# CONFIG_MOUSE_PS2_SENTELIC is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_BCM5974 is not set
# CONFIG_MOUSE_CYAPA is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_MOUSE_SYNAPTICS_I2C is not set
# CONFIG_MOUSE_SYNAPTICS_USB is not set
CONFIG_INPUT_JOYSTICK=y
# CONFIG_JOYSTICK_ANALOG is not set
# CONFIG_JOYSTICK_A3D is not set
# CONFIG_JOYSTICK_ADI is not set
# CONFIG_JOYSTICK_COBRA is not set
# CONFIG_JOYSTICK_GF2K is not set
# CONFIG_JOYSTICK_GRIP is not set
# CONFIG_JOYSTICK_GRIP_MP is not set
# CONFIG_JOYSTICK_GUILLEMOT is not set
# CONFIG_JOYSTICK_INTERACT is not set
# CONFIG_JOYSTICK_SIDEWINDER is not set
# CONFIG_JOYSTICK_TMDC is not set
# CONFIG_JOYSTICK_IFORCE is not set
# CONFIG_JOYSTICK_WARRIOR is not set
# CONFIG_JOYSTICK_MAGELLAN is not set
# CONFIG_JOYSTICK_SPACEORB is not set
# CONFIG_JOYSTICK_SPACEBALL is not set
# CONFIG_JOYSTICK_STINGER is not set
# CONFIG_JOYSTICK_TWIDJOY is not set
# CONFIG_JOYSTICK_ZHENHUA is not set
# CONFIG_JOYSTICK_AS5011 is not set
# CONFIG_JOYSTICK_JOYDUMP is not set
# CONFIG_JOYSTICK_XPAD is not set
CONFIG_INPUT_TABLET=y
# CONFIG_TABLET_USB_ACECAD is not set
# CONFIG_TABLET_USB_AIPTEK is not set
# CONFIG_TABLET_USB_GTCO is not set
# CONFIG_TABLET_USB_HANWANG is not set
# CONFIG_TABLET_USB_KBTAB is not set
# CONFIG_TABLET_USB_WACOM is not set
CONFIG_INPUT_TOUCHSCREEN=y
# CONFIG_TOUCHSCREEN_AD7879 is not set
# CONFIG_TOUCHSCREEN_ATMEL_MXT is not set
# CONFIG_TOUCHSCREEN_BU21013 is not set
# CONFIG_TOUCHSCREEN_CYTTSP_CORE is not set
# CONFIG_TOUCHSCREEN_CYTTSP4_CORE is not set
# CONFIG_TOUCHSCREEN_DYNAPRO is not set
# CONFIG_TOUCHSCREEN_HAMPSHIRE is not set
# CONFIG_TOUCHSCREEN_EETI is not set
# CONFIG_TOUCHSCREEN_FUJITSU is not set
# CONFIG_TOUCHSCREEN_ILI210X is not set
# CONFIG_TOUCHSCREEN_GUNZE is not set
# CONFIG_TOUCHSCREEN_ELO is not set
# CONFIG_TOUCHSCREEN_WACOM_W8001 is not set
# CONFIG_TOUCHSCREEN_WACOM_I2C is not set
# CONFIG_TOUCHSCREEN_MAX11801 is not set
# CONFIG_TOUCHSCREEN_MCS5000 is not set
# CONFIG_TOUCHSCREEN_MMS114 is not set
# CONFIG_TOUCHSCREEN_MTOUCH is not set
# CONFIG_TOUCHSCREEN_INEXIO is not set
# CONFIG_TOUCHSCREEN_MK712 is not set
# CONFIG_TOUCHSCREEN_PENMOUNT is not set
# CONFIG_TOUCHSCREEN_EDT_FT5X06 is not set
# CONFIG_TOUCHSCREEN_TOUCHRIGHT is not set
# CONFIG_TOUCHSCREEN_TOUCHWIN is not set
# CONFIG_TOUCHSCREEN_PIXCIR is not set
# CONFIG_TOUCHSCREEN_USB_COMPOSITE is not set
# CONFIG_TOUCHSCREEN_TOUCHIT213 is not set
# CONFIG_TOUCHSCREEN_TSC_SERIO is not set
# CONFIG_TOUCHSCREEN_TSC2007 is not set
# CONFIG_TOUCHSCREEN_ST1232 is not set
# CONFIG_TOUCHSCREEN_TPS6507X is not set
CONFIG_INPUT_MISC=y
# CONFIG_INPUT_AD714X is not set
# CONFIG_INPUT_BMA150 is not set
# CONFIG_INPUT_PCSPKR is not set
# CONFIG_INPUT_MMA8450 is not set
# CONFIG_INPUT_MPU3050 is not set
# CONFIG_INPUT_APANEL is not set
# CONFIG_INPUT_ATLAS_BTNS is not set
# CONFIG_INPUT_ATI_REMOTE2 is not set
# CONFIG_INPUT_KEYSPAN_REMOTE is not set
# CONFIG_INPUT_KXTJ9 is not set
# CONFIG_INPUT_POWERMATE is not set
# CONFIG_INPUT_YEALINK is not set
# CONFIG_INPUT_CM109 is not set
# CONFIG_INPUT_UINPUT is not set
# CONFIG_INPUT_PCF8574 is not set
# CONFIG_INPUT_ADXL34X is not set
# CONFIG_INPUT_IMS_PCU is not set
# CONFIG_INPUT_CMA3000 is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_SERIO_ALTERA_PS2 is not set
# CONFIG_SERIO_PS2MULT is not set
# CONFIG_SERIO_ARC_PS2 is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_TTY=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
# CONFIG_LEGACY_PTYS is not set
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_ROCKETPORT is not set
# CONFIG_CYCLADES is not set
# CONFIG_MOXA_INTELLIO is not set
# CONFIG_MOXA_SMARTIO is not set
# CONFIG_SYNCLINK is not set
# CONFIG_SYNCLINKMP is not set
# CONFIG_SYNCLINK_GT is not set
# CONFIG_NOZOMI is not set
# CONFIG_ISI is not set
# CONFIG_N_HDLC is not set
# CONFIG_N_GSM is not set
# CONFIG_TRACE_SINK is not set
CONFIG_DEVKMEM=y

#
# Serial drivers
#
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_DEPRECATED_OPTIONS=y
CONFIG_SERIAL_8250_PNP=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_SERIAL_8250_DMA=y
CONFIG_SERIAL_8250_PCI=y
# CONFIG_SERIAL_8250_CS is not set
CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
CONFIG_SERIAL_8250_DETECT_IRQ=y
CONFIG_SERIAL_8250_RSA=y
# CONFIG_SERIAL_8250_DW is not set

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_MFD_HSU is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not set
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_PCH_UART is not set
# CONFIG_SERIAL_ARC is not set
# CONFIG_SERIAL_RP2 is not set
# CONFIG_SERIAL_FSL_LPUART is not set
CONFIG_HVC_DRIVER=y
CONFIG_VIRTIO_CONSOLE=y
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
# CONFIG_HW_RANDOM_INTEL is not set
# CONFIG_HW_RANDOM_AMD is not set
CONFIG_HW_RANDOM_VIA=y
# CONFIG_HW_RANDOM_VIRTIO is not set
CONFIG_NVRAM=y
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set

#
# PCMCIA character devices
#
# CONFIG_SYNCLINK_CS is not set
# CONFIG_CARDMAN_4000 is not set
# CONFIG_CARDMAN_4040 is not set
# CONFIG_IPWIRELESS is not set
# CONFIG_MWAVE is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_HPET=y
# CONFIG_HPET_MMAP is not set
# CONFIG_HANGCHECK_TIMER is not set
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set
CONFIG_DEVPORT=y
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
# CONFIG_I2C_CHARDEV is not set
# CONFIG_I2C_MUX is not set
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_ALGOBIT=y

#
# I2C Hardware Bus support
#

#
# PC SMBus host controller drivers
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
CONFIG_I2C_I801=y
# CONFIG_I2C_ISCH is not set
# CONFIG_I2C_ISMT is not set
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set

#
# ACPI drivers
#
# CONFIG_I2C_SCMI is not set

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_DESIGNWARE_PCI is not set
# CONFIG_I2C_EG20T is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_PXA_PCI is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_XILINX is not set

#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_DIOLAN_U2C is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set
# CONFIG_I2C_TINY_USB is not set

#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_SPI is not set
# CONFIG_HSI is not set

#
# PPS support
#
CONFIG_PPS=y
# CONFIG_PPS_DEBUG is not set

#
# PPS clients support
#
# CONFIG_PPS_CLIENT_KTIMER is not set
# CONFIG_PPS_CLIENT_LDISC is not set
# CONFIG_PPS_CLIENT_GPIO is not set

#
# PPS generators support
#

#
# PTP clock support
#
CONFIG_PTP_1588_CLOCK=y

#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
# CONFIG_PTP_1588_CLOCK_PCH is not set
CONFIG_ARCH_WANT_OPTIONAL_GPIOLIB=y
CONFIG_GPIO_DEVRES=y
# CONFIG_GPIOLIB is not set
# CONFIG_W1 is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_TEST_POWER is not set
# CONFIG_BATTERY_DS2780 is not set
# CONFIG_BATTERY_DS2781 is not set
# CONFIG_BATTERY_DS2782 is not set
# CONFIG_BATTERY_SBS is not set
# CONFIG_BATTERY_BQ27x00 is not set
# CONFIG_BATTERY_MAX17040 is not set
# CONFIG_BATTERY_MAX17042 is not set
# CONFIG_CHARGER_MAX8903 is not set
# CONFIG_CHARGER_LP8727 is not set
# CONFIG_CHARGER_BQ2415X is not set
# CONFIG_CHARGER_SMB347 is not set
# CONFIG_BATTERY_GOLDFISH is not set
# CONFIG_POWER_RESET is not set
# CONFIG_POWER_AVS is not set
CONFIG_HWMON=y
# CONFIG_HWMON_VID is not set
# CONFIG_HWMON_DEBUG_CHIP is not set

#
# Native drivers
#
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_ABITUGURU3 is not set
# CONFIG_SENSORS_AD7414 is not set
# CONFIG_SENSORS_AD7418 is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ADT7410 is not set
# CONFIG_SENSORS_ADT7411 is not set
# CONFIG_SENSORS_ADT7462 is not set
# CONFIG_SENSORS_ADT7470 is not set
# CONFIG_SENSORS_ADT7475 is not set
# CONFIG_SENSORS_ASC7621 is not set
# CONFIG_SENSORS_K8TEMP is not set
# CONFIG_SENSORS_K10TEMP is not set
# CONFIG_SENSORS_FAM15H_POWER is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS620 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_I5K_AMB is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_F71882FG is not set
# CONFIG_SENSORS_F75375S is not set
# CONFIG_SENSORS_FSCHMD is not set
# CONFIG_SENSORS_G760A is not set
# CONFIG_SENSORS_G762 is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_HIH6130 is not set
# CONFIG_SENSORS_CORETEMP is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_JC42 is not set
# CONFIG_SENSORS_LINEAGE is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM73 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_LM93 is not set
# CONFIG_SENSORS_LTC4151 is not set
# CONFIG_SENSORS_LTC4215 is not set
# CONFIG_SENSORS_LTC4245 is not set
# CONFIG_SENSORS_LTC4261 is not set
# CONFIG_SENSORS_LM95234 is not set
# CONFIG_SENSORS_LM95241 is not set
# CONFIG_SENSORS_LM95245 is not set
# CONFIG_SENSORS_MAX16065 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_MAX1668 is not set
# CONFIG_SENSORS_MAX197 is not set
# CONFIG_SENSORS_MAX6639 is not set
# CONFIG_SENSORS_MAX6642 is not set
# CONFIG_SENSORS_MAX6650 is not set
# CONFIG_SENSORS_MAX6697 is not set
# CONFIG_SENSORS_MCP3021 is not set
# CONFIG_SENSORS_NCT6775 is not set
# CONFIG_SENSORS_NTC_THERMISTOR is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_PMBUS is not set
# CONFIG_SENSORS_SHT21 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_SMM665 is not set
# CONFIG_SENSORS_DME1737 is not set
# CONFIG_SENSORS_EMC1403 is not set
# CONFIG_SENSORS_EMC2103 is not set
# CONFIG_SENSORS_EMC6W201 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_SCH56XX_COMMON is not set
# CONFIG_SENSORS_SCH5627 is not set
# CONFIG_SENSORS_SCH5636 is not set
# CONFIG_SENSORS_ADS1015 is not set
# CONFIG_SENSORS_ADS7828 is not set
# CONFIG_SENSORS_AMC6821 is not set
# CONFIG_SENSORS_INA209 is not set
# CONFIG_SENSORS_INA2XX is not set
# CONFIG_SENSORS_THMC50 is not set
# CONFIG_SENSORS_TMP102 is not set
# CONFIG_SENSORS_TMP401 is not set
# CONFIG_SENSORS_TMP421 is not set
# CONFIG_SENSORS_VIA_CPUTEMP is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_VT8231 is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83795 is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83L786NG is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_SENSORS_APPLESMC is not set

#
# ACPI drivers
#
# CONFIG_SENSORS_ACPI_POWER is not set
# CONFIG_SENSORS_ATK0110 is not set
CONFIG_THERMAL=y
CONFIG_THERMAL_HWMON=y
CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE=y
# CONFIG_THERMAL_DEFAULT_GOV_FAIR_SHARE is not set
# CONFIG_THERMAL_DEFAULT_GOV_USER_SPACE is not set
# CONFIG_THERMAL_GOV_FAIR_SHARE is not set
CONFIG_THERMAL_GOV_STEP_WISE=y
CONFIG_THERMAL_GOV_USER_SPACE=y
# CONFIG_CPU_THERMAL is not set
# CONFIG_THERMAL_EMULATION is not set
# CONFIG_INTEL_POWERCLAMP is not set
CONFIG_X86_PKG_TEMP_THERMAL=m

#
# Texas Instruments thermal drivers
#
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_CORE is not set
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
# CONFIG_ACQUIRE_WDT is not set
# CONFIG_ADVANTECH_WDT is not set
# CONFIG_ALIM1535_WDT is not set
# CONFIG_ALIM7101_WDT is not set
# CONFIG_F71808E_WDT is not set
# CONFIG_SP5100_TCO is not set
# CONFIG_SC520_WDT is not set
# CONFIG_SBC_FITPC2_WATCHDOG is not set
# CONFIG_EUROTECH_WDT is not set
# CONFIG_IB700_WDT is not set
# CONFIG_IBMASR is not set
# CONFIG_WAFER_WDT is not set
# CONFIG_I6300ESB_WDT is not set
# CONFIG_IE6XX_WDT is not set
# CONFIG_ITCO_WDT is not set
# CONFIG_IT8712F_WDT is not set
# CONFIG_IT87_WDT is not set
# CONFIG_HP_WATCHDOG is not set
# CONFIG_SC1200_WDT is not set
# CONFIG_PC87413_WDT is not set
# CONFIG_NV_TCO is not set
# CONFIG_60XX_WDT is not set
# CONFIG_SBC8360_WDT is not set
# CONFIG_CPU5_WDT is not set
# CONFIG_SMSC_SCH311X_WDT is not set
# CONFIG_SMSC37B787_WDT is not set
# CONFIG_VIA_WDT is not set
# CONFIG_W83627HF_WDT is not set
# CONFIG_W83697HF_WDT is not set
# CONFIG_W83697UG_WDT is not set
# CONFIG_W83877F_WDT is not set
# CONFIG_W83977F_WDT is not set
# CONFIG_MACHZ_WDT is not set
# CONFIG_SBC_EPX_C3_WATCHDOG is not set

#
# PCI-based Watchdog Cards
#
# CONFIG_PCIPCWATCHDOG is not set
# CONFIG_WDTPCI is not set

#
# USB-based Watchdog Cards
#
# CONFIG_USBPCWATCHDOG is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set

#
# Multifunction device drivers
#
# CONFIG_MFD_CORE is not set
# CONFIG_MFD_CS5535 is not set
# CONFIG_MFD_AS3711 is not set
# CONFIG_PMIC_ADP5520 is not set
# CONFIG_MFD_CROS_EC is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_MFD_DA9052_I2C is not set
# CONFIG_MFD_DA9055 is not set
# CONFIG_MFD_MC13XXX_I2C is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_LPC_ICH is not set
# CONFIG_LPC_SCH is not set
# CONFIG_MFD_JANZ_CMODIO is not set
# CONFIG_MFD_KEMPLD is not set
# CONFIG_MFD_88PM800 is not set
# CONFIG_MFD_88PM805 is not set
# CONFIG_MFD_88PM860X is not set
# CONFIG_MFD_MAX77686 is not set
# CONFIG_MFD_MAX77693 is not set
# CONFIG_MFD_MAX8907 is not set
# CONFIG_MFD_MAX8925 is not set
# CONFIG_MFD_MAX8997 is not set
# CONFIG_MFD_MAX8998 is not set
# CONFIG_MFD_VIPERBOARD is not set
# CONFIG_MFD_RETU is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_MFD_RDC321X is not set
# CONFIG_MFD_RTSX_PCI is not set
# CONFIG_MFD_RC5T583 is not set
# CONFIG_MFD_SEC_CORE is not set
# CONFIG_MFD_SI476X_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_MFD_SMSC is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_MFD_STMPE is not set
# CONFIG_MFD_SYSCON is not set
# CONFIG_MFD_TI_AM335X_TSCADC is not set
# CONFIG_MFD_LP8788 is not set
# CONFIG_MFD_PALMAS is not set
# CONFIG_TPS6105X is not set
# CONFIG_TPS6507X is not set
# CONFIG_MFD_TPS65090 is not set
# CONFIG_MFD_TPS65217 is not set
# CONFIG_MFD_TPS6586X is not set
# CONFIG_MFD_TPS80031 is not set
# CONFIG_TWL4030_CORE is not set
# CONFIG_TWL6040_CORE is not set
# CONFIG_MFD_WL1273_CORE is not set
# CONFIG_MFD_LM3533 is not set
# CONFIG_MFD_TC3589X is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_VX855 is not set
# CONFIG_MFD_ARIZONA_I2C is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM831X_I2C is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_WM8994 is not set
# CONFIG_REGULATOR is not set
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
CONFIG_AGP=y
CONFIG_AGP_AMD64=y
CONFIG_AGP_INTEL=y
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_VIA is not set
CONFIG_VGA_ARB=y
CONFIG_VGA_ARB_MAX_GPUS=16
# CONFIG_VGA_SWITCHEROO is not set
CONFIG_DRM=y
CONFIG_DRM_KMS_HELPER=y
# CONFIG_DRM_LOAD_EDID_FIRMWARE is not set

#
# I2C encoder or helper chips
#
# CONFIG_DRM_I2C_CH7006 is not set
# CONFIG_DRM_I2C_SIL164 is not set
# CONFIG_DRM_I2C_NXP_TDA998X is not set
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
# CONFIG_DRM_RADEON is not set
# CONFIG_DRM_NOUVEAU is not set
CONFIG_DRM_I915=y
CONFIG_DRM_I915_KMS=y
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set
# CONFIG_DRM_VMWGFX is not set
# CONFIG_DRM_GMA500 is not set
# CONFIG_DRM_UDL is not set
# CONFIG_DRM_AST is not set
# CONFIG_DRM_MGAG200 is not set
# CONFIG_DRM_CIRRUS_QEMU is not set
# CONFIG_DRM_QXL is not set
# CONFIG_VGASTATE is not set
CONFIG_VIDEO_OUTPUT_CONTROL=y
CONFIG_HDMI=y
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
# CONFIG_FB_DDC is not set
# CONFIG_FB_BOOT_VESA_SUPPORT is not set
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
# CONFIG_FB_SYS_FILLRECT is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_FOREIGN_ENDIAN is not set
# CONFIG_FB_SYS_FOPS is not set
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
CONFIG_FB_TILEBLITTING=y

#
# Frame buffer hardware drivers
#
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
# CONFIG_FB_UVESA is not set
# CONFIG_FB_VESA is not set
CONFIG_FB_EFI=y
# CONFIG_FB_N411 is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_I740 is not set
# CONFIG_FB_LE80578 is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_VIA is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_CARMINE is not set
# CONFIG_FB_SMSCUFX is not set
# CONFIG_FB_UDL is not set
# CONFIG_FB_GOLDFISH is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_MB862XX is not set
# CONFIG_FB_BROADSHEET is not set
# CONFIG_FB_AUO_K190X is not set
# CONFIG_EXYNOS_VIDEO is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
# CONFIG_LCD_CLASS_DEVICE is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_BACKLIGHT_GENERIC=y
# CONFIG_BACKLIGHT_APPLE is not set
# CONFIG_BACKLIGHT_SAHARA is not set
# CONFIG_BACKLIGHT_ADP8860 is not set
# CONFIG_BACKLIGHT_ADP8870 is not set
# CONFIG_BACKLIGHT_LM3630 is not set
# CONFIG_BACKLIGHT_LM3639 is not set
# CONFIG_BACKLIGHT_LP855X is not set

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
CONFIG_LOGO_LINUX_CLUT224=y
CONFIG_SOUND=y
CONFIG_SOUND_OSS_CORE=y
CONFIG_SOUND_OSS_CORE_PRECLAIM=y
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
CONFIG_SND_HWDEP=y
CONFIG_SND_SEQUENCER=y
CONFIG_SND_SEQ_DUMMY=y
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
CONFIG_SND_PCM_OSS_PLUGINS=y
CONFIG_SND_SEQUENCER_OSS=y
CONFIG_SND_HRTIMER=y
CONFIG_SND_SEQ_HRTIMER_DEFAULT=y
# CONFIG_SND_DYNAMIC_MINORS is not set
CONFIG_SND_SUPPORT_OLD_API=y
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
CONFIG_SND_VMASTER=y
CONFIG_SND_KCTL_JACK=y
CONFIG_SND_DMA_SGBUF=y
# CONFIG_SND_RAWMIDI_SEQ is not set
# CONFIG_SND_OPL3_LIB_SEQ is not set
# CONFIG_SND_OPL4_LIB_SEQ is not set
# CONFIG_SND_SBAWE_SEQ is not set
# CONFIG_SND_EMU10K1_SEQ is not set
CONFIG_SND_DRIVERS=y
# CONFIG_SND_PCSP is not set
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_ALOOP is not set
# CONFIG_SND_VIRMIDI is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set
CONFIG_SND_PCI=y
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ASIHPI is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AW2 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_OXYGEN is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS5530 is not set
# CONFIG_SND_CS5535AUDIO is not set
# CONFIG_SND_CTXFI is not set
# CONFIG_SND_DARLA20 is not set
# CONFIG_SND_GINA20 is not set
# CONFIG_SND_LAYLA20 is not set
# CONFIG_SND_DARLA24 is not set
# CONFIG_SND_GINA24 is not set
# CONFIG_SND_LAYLA24 is not set
# CONFIG_SND_MONA is not set
# CONFIG_SND_MIA is not set
# CONFIG_SND_ECHO3G is not set
# CONFIG_SND_INDIGO is not set
# CONFIG_SND_INDIGOIO is not set
# CONFIG_SND_INDIGODJ is not set
# CONFIG_SND_INDIGOIOX is not set
# CONFIG_SND_INDIGODJX is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_FM801 is not set
CONFIG_SND_HDA_INTEL=y
CONFIG_SND_HDA_PREALLOC_SIZE=64
CONFIG_SND_HDA_HWDEP=y
# CONFIG_SND_HDA_RECONFIG is not set
# CONFIG_SND_HDA_INPUT_BEEP is not set
# CONFIG_SND_HDA_INPUT_JACK is not set
# CONFIG_SND_HDA_PATCH_LOADER is not set
CONFIG_SND_HDA_CODEC_REALTEK=y
CONFIG_SND_HDA_CODEC_ANALOG=y
CONFIG_SND_HDA_CODEC_SIGMATEL=y
CONFIG_SND_HDA_CODEC_VIA=y
CONFIG_SND_HDA_CODEC_HDMI=y
# CONFIG_SND_HDA_I915 is not set
CONFIG_SND_HDA_CODEC_CIRRUS=y
CONFIG_SND_HDA_CODEC_CONEXANT=y
CONFIG_SND_HDA_CODEC_CA0110=y
CONFIG_SND_HDA_CODEC_CA0132=y
# CONFIG_SND_HDA_CODEC_CA0132_DSP is not set
CONFIG_SND_HDA_CODEC_CMEDIA=y
CONFIG_SND_HDA_CODEC_SI3054=y
CONFIG_SND_HDA_GENERIC=y
CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
# CONFIG_SND_INTEL8X0 is not set
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_LOLA is not set
# CONFIG_SND_LX6464ES is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_PCXHR is not set
# CONFIG_SND_RIPTIDE is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VIRTUOSO is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI is not set
CONFIG_SND_USB=y
# CONFIG_SND_USB_AUDIO is not set
# CONFIG_SND_USB_UA101 is not set
# CONFIG_SND_USB_USX2Y is not set
# CONFIG_SND_USB_CAIAQ is not set
# CONFIG_SND_USB_US122L is not set
# CONFIG_SND_USB_6FIRE is not set
# CONFIG_SND_USB_HIFACE is not set
CONFIG_SND_PCMCIA=y
# CONFIG_SND_VXPOCKET is not set
# CONFIG_SND_PDAUDIOCF is not set
# CONFIG_SND_SOC is not set
# CONFIG_SOUND_PRIME is not set

#
# HID support
#
CONFIG_HID=y
# CONFIG_HID_BATTERY_STRENGTH is not set
CONFIG_HIDRAW=y
# CONFIG_UHID is not set
CONFIG_HID_GENERIC=y

#
# Special HID drivers
#
CONFIG_HID_A4TECH=y
# CONFIG_HID_ACRUX is not set
CONFIG_HID_APPLE=y
# CONFIG_HID_APPLEIR is not set
# CONFIG_HID_AUREAL is not set
CONFIG_HID_BELKIN=y
CONFIG_HID_CHERRY=y
CONFIG_HID_CHICONY=y
# CONFIG_HID_PRODIKEYS is not set
CONFIG_HID_CYPRESS=y
# CONFIG_HID_DRAGONRISE is not set
# CONFIG_HID_EMS_FF is not set
# CONFIG_HID_ELECOM is not set
# CONFIG_HID_ELO is not set
CONFIG_HID_EZKEY=y
# CONFIG_HID_HOLTEK is not set
# CONFIG_HID_HUION is not set
# CONFIG_HID_KEYTOUCH is not set
# CONFIG_HID_KYE is not set
# CONFIG_HID_UCLOGIC is not set
# CONFIG_HID_WALTOP is not set
CONFIG_HID_GYRATION=y
# CONFIG_HID_ICADE is not set
# CONFIG_HID_TWINHAN is not set
CONFIG_HID_KENSINGTON=y
# CONFIG_HID_LCPOWER is not set
# CONFIG_HID_LENOVO_TPKBD is not set
CONFIG_HID_LOGITECH=y
# CONFIG_HID_LOGITECH_DJ is not set
CONFIG_LOGITECH_FF=y
# CONFIG_LOGIRUMBLEPAD2_FF is not set
# CONFIG_LOGIG940_FF is not set
CONFIG_LOGIWHEELS_FF=y
# CONFIG_HID_MAGICMOUSE is not set
CONFIG_HID_MICROSOFT=y
CONFIG_HID_MONTEREY=y
# CONFIG_HID_MULTITOUCH is not set
CONFIG_HID_NTRIG=y
# CONFIG_HID_ORTEK is not set
CONFIG_HID_PANTHERLORD=y
CONFIG_PANTHERLORD_FF=y
CONFIG_HID_PETALYNX=y
# CONFIG_HID_PICOLCD is not set
# CONFIG_HID_PRIMAX is not set
# CONFIG_HID_ROCCAT is not set
# CONFIG_HID_SAITEK is not set
CONFIG_HID_SAMSUNG=y
CONFIG_HID_SONY=y
# CONFIG_HID_SPEEDLINK is not set
# CONFIG_HID_STEELSERIES is not set
CONFIG_HID_SUNPLUS=y
# CONFIG_HID_GREENASIA is not set
# CONFIG_HID_SMARTJOYPLUS is not set
# CONFIG_HID_TIVO is not set
CONFIG_HID_TOPSEED=y
# CONFIG_HID_THINGM is not set
# CONFIG_HID_THRUSTMASTER is not set
# CONFIG_HID_WACOM is not set
# CONFIG_HID_WIIMOTE is not set
# CONFIG_HID_ZEROPLUS is not set
# CONFIG_HID_ZYDACRON is not set
# CONFIG_HID_SENSOR_HUB is not set

#
# USB HID support
#
CONFIG_USB_HID=y
CONFIG_HID_PID=y
CONFIG_USB_HIDDEV=y

#
# I2C HID support
#
# CONFIG_I2C_HID is not set
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB=y
CONFIG_USB_DEBUG=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y

#
# Miscellaneous USB options
#
CONFIG_USB_DEFAULT_PERSIST=y
# CONFIG_USB_DYNAMIC_MINORS is not set
CONFIG_USB_MON=y
# CONFIG_USB_WUSB_CBAF is not set

#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
# CONFIG_USB_XHCI_HCD is not set
CONFIG_USB_EHCI_HCD=y
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
CONFIG_USB_EHCI_PCI=y
# CONFIG_USB_EHCI_HCD_PLATFORM is not set
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_ISP1760_HCD is not set
# CONFIG_USB_ISP1362_HCD is not set
# CONFIG_USB_FUSBH200_HCD is not set
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_OHCI_HCD_PCI=y
# CONFIG_USB_OHCI_HCD_PLATFORM is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=y
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set

#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
CONFIG_USB_PRINTER=y
# CONFIG_USB_WDM is not set
# CONFIG_USB_TMC is not set

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#

#
# also be needed; see USB_STORAGE Help for more info
#
CONFIG_USB_STORAGE=y
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_REALTEK is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_ISD200 is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_ONETOUCH is not set
# CONFIG_USB_STORAGE_KARMA is not set
# CONFIG_USB_STORAGE_CYPRESS_ATACB is not set
# CONFIG_USB_STORAGE_ENE_UB6250 is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
# CONFIG_USB_DWC3 is not set
# CONFIG_USB_CHIPIDEA is not set

#
# USB port drivers
#
# CONFIG_USB_SERIAL is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_SEVSEG is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_YUREX is not set
# CONFIG_USB_EZUSB_FX2 is not set
# CONFIG_USB_HSIC_USB3503 is not set
# CONFIG_USB_PHY is not set
# CONFIG_USB_GADGET is not set
# CONFIG_UWB is not set
# CONFIG_MMC is not set
# CONFIG_MEMSTICK is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
# CONFIG_LEDS_LM3530 is not set
# CONFIG_LEDS_LM3642 is not set
# CONFIG_LEDS_PCA9532 is not set
# CONFIG_LEDS_LP3944 is not set
# CONFIG_LEDS_LP5521 is not set
# CONFIG_LEDS_LP5523 is not set
# CONFIG_LEDS_LP5562 is not set
# CONFIG_LEDS_CLEVO_MAIL is not set
# CONFIG_LEDS_PCA955X is not set
# CONFIG_LEDS_PCA9633 is not set
# CONFIG_LEDS_BD2802 is not set
# CONFIG_LEDS_INTEL_SS4200 is not set
# CONFIG_LEDS_TCA6507 is not set
# CONFIG_LEDS_LM355x is not set
# CONFIG_LEDS_OT200 is not set
# CONFIG_LEDS_BLINKM is not set

#
# LED Triggers
#
CONFIG_LEDS_TRIGGERS=y
# CONFIG_LEDS_TRIGGER_TIMER is not set
# CONFIG_LEDS_TRIGGER_ONESHOT is not set
# CONFIG_LEDS_TRIGGER_HEARTBEAT is not set
# CONFIG_LEDS_TRIGGER_BACKLIGHT is not set
# CONFIG_LEDS_TRIGGER_CPU is not set
# CONFIG_LEDS_TRIGGER_DEFAULT_ON is not set

#
# iptables trigger is under Netfilter config (LED target)
#
# CONFIG_LEDS_TRIGGER_TRANSIENT is not set
# CONFIG_LEDS_TRIGGER_CAMERA is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_INFINIBAND is not set
CONFIG_EDAC=y
CONFIG_EDAC_LEGACY_SYSFS=y
# CONFIG_EDAC_DEBUG is not set
CONFIG_EDAC_DECODE_MCE=y
# CONFIG_EDAC_MCE_INJ is not set
# CONFIG_EDAC_MM_EDAC is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
# CONFIG_RTC_HCTOSYS is not set
CONFIG_RTC_SYSTOHC=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_DEBUG is not set

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set

#
# I2C RTC drivers
#
# CONFIG_RTC_DRV_DS1307 is not set
# CONFIG_RTC_DRV_DS1374 is not set
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_DS3232 is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_ISL12022 is not set
# CONFIG_RTC_DRV_X1205 is not set
# CONFIG_RTC_DRV_PCF2127 is not set
# CONFIG_RTC_DRV_PCF8523 is not set
# CONFIG_RTC_DRV_PCF8563 is not set
# CONFIG_RTC_DRV_PCF8583 is not set
# CONFIG_RTC_DRV_M41T80 is not set
# CONFIG_RTC_DRV_BQ32K is not set
# CONFIG_RTC_DRV_S35390A is not set
# CONFIG_RTC_DRV_FM3130 is not set
# CONFIG_RTC_DRV_RX8581 is not set
# CONFIG_RTC_DRV_RX8025 is not set
# CONFIG_RTC_DRV_EM3027 is not set
# CONFIG_RTC_DRV_RV3029C2 is not set

#
# SPI RTC drivers
#

#
# Platform RTC drivers
#
CONFIG_RTC_DRV_CMOS=y
# CONFIG_RTC_DRV_DS1286 is not set
# CONFIG_RTC_DRV_DS1511 is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T35 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_MSM6242 is not set
# CONFIG_RTC_DRV_BQ4802 is not set
# CONFIG_RTC_DRV_RP5C01 is not set
# CONFIG_RTC_DRV_V3020 is not set
# CONFIG_RTC_DRV_DS2404 is not set

#
# on-CPU RTC drivers
#

#
# HID Sensor RTC drivers
#
# CONFIG_RTC_DRV_HID_SENSOR_TIME is not set
CONFIG_DMADEVICES=y
# CONFIG_DMADEVICES_DEBUG is not set

#
# DMA Devices
#
# CONFIG_INTEL_MID_DMAC is not set
# CONFIG_INTEL_IOATDMA is not set
# CONFIG_DW_DMAC_CORE is not set
# CONFIG_DW_DMAC is not set
# CONFIG_DW_DMAC_PCI is not set
# CONFIG_TIMB_DMA is not set
# CONFIG_PCH_DMA is not set
CONFIG_DMA_ACPI=y
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
# CONFIG_VFIO is not set
# CONFIG_VIRT_DRIVERS is not set
CONFIG_VIRTIO=y

#
# Virtio drivers
#
CONFIG_VIRTIO_PCI=y
# CONFIG_VIRTIO_BALLOON is not set
# CONFIG_VIRTIO_MMIO is not set

#
# Microsoft Hyper-V guest support
#
# CONFIG_STAGING is not set
CONFIG_X86_PLATFORM_DEVICES=y
# CONFIG_ACERHDF is not set
# CONFIG_ASUS_LAPTOP is not set
# CONFIG_CHROMEOS_LAPTOP is not set
# CONFIG_FUJITSU_LAPTOP is not set
# CONFIG_FUJITSU_TABLET is not set
# CONFIG_AMILO_RFKILL is not set
# CONFIG_HP_ACCEL is not set
# CONFIG_MSI_LAPTOP is not set
# CONFIG_PANASONIC_LAPTOP is not set
# CONFIG_COMPAL_LAPTOP is not set
# CONFIG_SONY_LAPTOP is not set
# CONFIG_IDEAPAD_LAPTOP is not set
# CONFIG_THINKPAD_ACPI is not set
# CONFIG_SENSORS_HDAPS is not set
# CONFIG_INTEL_MENLOW is not set
CONFIG_EEEPC_LAPTOP=y
# CONFIG_ACPI_WMI is not set
# CONFIG_TOPSTAR_LAPTOP is not set
# CONFIG_TOSHIBA_BT_RFKILL is not set
# CONFIG_ACPI_CMPC is not set
# CONFIG_INTEL_IPS is not set
# CONFIG_IBM_RTL is not set
# CONFIG_XO15_EBOOK is not set
# CONFIG_SAMSUNG_LAPTOP is not set
# CONFIG_INTEL_OAKTRAIL is not set
# CONFIG_SAMSUNG_Q10 is not set
# CONFIG_APPLE_GMUX is not set
# CONFIG_INTEL_RST is not set
# CONFIG_INTEL_SMARTCONNECT is not set
# CONFIG_PVPANIC is not set

#
# Hardware Spinlock drivers
#
CONFIG_CLKEVT_I8253=y
CONFIG_I8253_LOCK=y
CONFIG_CLKBLD_I8253=y
# CONFIG_MAILBOX is not set
CONFIG_IOMMU_API=y
CONFIG_IOMMU_SUPPORT=y
CONFIG_AMD_IOMMU=y
CONFIG_AMD_IOMMU_STATS=y
# CONFIG_AMD_IOMMU_V2 is not set
CONFIG_DMAR_TABLE=y
CONFIG_INTEL_IOMMU=y
# CONFIG_INTEL_IOMMU_DEFAULT_ON is not set
CONFIG_INTEL_IOMMU_FLOPPY_WA=y
# CONFIG_IRQ_REMAP is not set

#
# Remoteproc drivers
#
# CONFIG_STE_MODEM_RPROC is not set

#
# Rpmsg drivers
#
# CONFIG_PM_DEVFREQ is not set
# CONFIG_EXTCON is not set
# CONFIG_MEMORY is not set
# CONFIG_IIO is not set
# CONFIG_NTB is not set
# CONFIG_VME_BUS is not set
# CONFIG_PWM is not set
# CONFIG_IPACK_BUS is not set
# CONFIG_RESET_CONTROLLER is not set
# CONFIG_FMC is not set

#
# Firmware Drivers
#
# CONFIG_EDD is not set
CONFIG_FIRMWARE_MEMMAP=y
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not set
CONFIG_DMIID=y
# CONFIG_DMI_SYSFS is not set
# CONFIG_ISCSI_IBFT_FIND is not set
# CONFIG_GOOGLE_FIRMWARE is not set

#
# EFI (Extensible Firmware Interface) Support
#
CONFIG_EFI_VARS=y

#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
CONFIG_EXT4_FS=y
CONFIG_EXT4_USE_FOR_EXT23=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
# CONFIG_EXT4_DEBUG is not set
CONFIG_JBD2=y
# CONFIG_JBD2_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
CONFIG_QUOTA=y
CONFIG_QUOTA_NETLINK_INTERFACE=y
# CONFIG_PRINT_QUOTA_WARNING is not set
# CONFIG_QUOTA_DEBUG is not set
CONFIG_QUOTA_TREE=y
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
CONFIG_QUOTACTL_COMPAT=y
CONFIG_AUTOFS4_FS=y
# CONFIG_FUSE_FS is not set
CONFIG_GENERIC_ACL=y

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_VMCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_TMPFS_XATTR=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
# CONFIG_CONFIGFS_FS is not set
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_ECRYPT_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_LOGFS is not set
# CONFIG_CRAMFS is not set
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX6FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_PSTORE is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_F2FS_FS is not set
# CONFIG_EFIVAR_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V2=y
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
# CONFIG_NFS_SWAP is not set
# CONFIG_NFS_V4_1 is not set
CONFIG_ROOT_NFS=y
# CONFIG_NFS_USE_LEGACY_DNS is not set
CONFIG_NFS_USE_KERNEL_DNS=y
# CONFIG_NFSD is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_ACL_SUPPORT=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
# CONFIG_SUNRPC_DEBUG is not set
# CONFIG_CEPH_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_MAC_ROMAN is not set
# CONFIG_NLS_MAC_CELTIC is not set
# CONFIG_NLS_MAC_CENTEURO is not set
# CONFIG_NLS_MAC_CROATIAN is not set
# CONFIG_NLS_MAC_CYRILLIC is not set
# CONFIG_NLS_MAC_GAELIC is not set
# CONFIG_NLS_MAC_GREEK is not set
# CONFIG_NLS_MAC_ICELAND is not set
# CONFIG_NLS_MAC_INUIT is not set
# CONFIG_NLS_MAC_ROMANIAN is not set
# CONFIG_NLS_MAC_TURKISH is not set
CONFIG_NLS_UTF8=y

#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y

#
# printk and dmesg options
#
CONFIG_PRINTK_TIME=y
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=4
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_DYNAMIC_DEBUG is not set

#
# Compile-time checks and compiler options
#
# CONFIG_DEBUG_INFO is not set
# CONFIG_ENABLE_WARN_DEPRECATED is not set
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=2048
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_READABLE_ASM is not set
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
CONFIG_ARCH_WANT_FRAME_POINTERS=y
CONFIG_FRAME_POINTER=y
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_KERNEL=y

#
# Memory Debugging
#
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
CONFIG_HAVE_DEBUG_KMEMLEAK=y
# CONFIG_DEBUG_KMEMLEAK is not set
CONFIG_DEBUG_STACK_USAGE=y
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_VIRTUAL is not set
CONFIG_DEBUG_MEMORY_INIT=y
# CONFIG_DEBUG_PER_CPU_MAPS is not set
CONFIG_HAVE_DEBUG_STACKOVERFLOW=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_HAVE_ARCH_KMEMCHECK=y
# CONFIG_KMEMCHECK is not set
# CONFIG_DEBUG_SHIRQ is not set

#
# Debug Lockups and Hangs
#
# CONFIG_LOCKUP_DETECTOR is not set
# CONFIG_DETECT_HUNG_TASK is not set
# CONFIG_PANIC_ON_OOPS is not set
CONFIG_PANIC_ON_OOPS_VALUE=0
# CONFIG_SCHED_DEBUG is not set
CONFIG_SCHEDSTATS=y
CONFIG_TIMER_STATS=y
CONFIG_DEBUG_PREEMPT=y

#
# Lock Debugging (spinlocks, mutexes, etc...)
#
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
# CONFIG_DEBUG_WW_MUTEX_SLOWPATH is not set
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_LOCKDEP is not set
# CONFIG_DEBUG_ATOMIC_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
CONFIG_TRACE_IRQFLAGS=y
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_WRITECOUNT is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set

#
# RCU Debugging
#
CONFIG_PROVE_RCU=y
# CONFIG_PROVE_RCU_REPEATEDLY is not set
# CONFIG_PROVE_RCU_DELAY is not set
# CONFIG_SPARSE_RCU_POINTER is not set
CONFIG_RCU_TORTURE_TEST=y
# CONFIG_RCU_TORTURE_TEST_RUNNABLE is not set
CONFIG_RCU_CPU_STALL_TIMEOUT=21
CONFIG_RCU_CPU_STALL_VERBOSE=y
# CONFIG_RCU_CPU_STALL_INFO is not set
# CONFIG_RCU_TRACE is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_NOTIFIER_ERROR_INJECTION is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_LATENCYTOP is not set
CONFIG_ARCH_HAS_DEBUG_STRICT_USER_COPY_CHECKS=y
# CONFIG_DEBUG_STRICT_USER_COPY_CHECKS is not set
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST=y
CONFIG_HAVE_FUNCTION_TRACE_MCOUNT_TEST=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_DYNAMIC_FTRACE_WITH_REGS=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_FENTRY=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACE_CLOCK=y
CONFIG_RING_BUFFER=y
CONFIG_EVENT_TRACING=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_TRACING=y
CONFIG_GENERIC_TRACER=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
# CONFIG_FUNCTION_TRACER is not set
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_PREEMPT_TRACER is not set
# CONFIG_SCHED_TRACER is not set
# CONFIG_FTRACE_SYSCALLS is not set
# CONFIG_TRACER_SNAPSHOT is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
# CONFIG_STACK_TRACER is not set
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_KPROBE_EVENT=y
# CONFIG_UPROBE_EVENT is not set
CONFIG_PROBE_EVENTS=y
# CONFIG_FTRACE_STARTUP_TEST is not set
# CONFIG_MMIOTRACE is not set
# CONFIG_RING_BUFFER_BENCHMARK is not set
# CONFIG_RING_BUFFER_STARTUP_TEST is not set

#
# Runtime Testing
#
# CONFIG_LKDTM is not set
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_KPROBES_SANITY_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_RBTREE_TEST is not set
# CONFIG_INTERVAL_TREE_TEST is not set
# CONFIG_ATOMIC64_SELFTEST is not set
# CONFIG_TEST_STRING_HELPERS is not set
# CONFIG_TEST_KSTRTOX is not set
CONFIG_PROVIDE_OHCI1394_DMA_INIT=y
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
# CONFIG_STRICT_DEVMEM is not set
CONFIG_X86_VERBOSE_BOOTUP=y
CONFIG_EARLY_PRINTK=y
CONFIG_EARLY_PRINTK_DBGP=y
# CONFIG_X86_PTDUMP is not set
CONFIG_DEBUG_RODATA=y
# CONFIG_DEBUG_RODATA_TEST is not set
# CONFIG_DEBUG_SET_MODULE_RONX is not set
# CONFIG_DEBUG_NX_TEST is not set
CONFIG_DOUBLEFAULT=y
# CONFIG_DEBUG_TLBFLUSH is not set
# CONFIG_IOMMU_DEBUG is not set
# CONFIG_IOMMU_STRESS is not set
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
# CONFIG_X86_DECODER_SELFTEST is not set
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
CONFIG_IO_DELAY_0X80=y
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not set
CONFIG_DEFAULT_IO_DELAY_TYPE=0
CONFIG_DEBUG_BOOT_PARAMS=y
# CONFIG_CPA_DEBUG is not set
CONFIG_OPTIMIZE_INLINING=y
# CONFIG_DEBUG_NMI_SELFTEST is not set
# CONFIG_X86_DEBUG_STATIC_CPU_HAS is not set

#
# Security options
#
CONFIG_KEYS=y
# CONFIG_ENCRYPTED_KEYS is not set
CONFIG_KEYS_DEBUG_PROC_KEYS=y
# CONFIG_SECURITY_DMESG_RESTRICT is not set
CONFIG_SECURITY=y
# CONFIG_SECURITYFS is not set
CONFIG_SECURITY_NETWORK=y
# CONFIG_SECURITY_NETWORK_XFRM is not set
# CONFIG_SECURITY_PATH is not set
# CONFIG_INTEL_TXT is not set
CONFIG_LSM_MMAP_MIN_ADDR=65536
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
# CONFIG_SECURITY_SELINUX_POLICYDB_VERSION_MAX is not set
# CONFIG_SECURITY_SMACK is not set
# CONFIG_SECURITY_TOMOYO is not set
# CONFIG_SECURITY_APPARMOR is not set
# CONFIG_SECURITY_YAMA is not set
# CONFIG_IMA is not set
# CONFIG_EVM is not set
CONFIG_DEFAULT_SECURITY_SELINUX=y
# CONFIG_DEFAULT_SECURITY_DAC is not set
CONFIG_DEFAULT_SECURITY="selinux"
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_PCOMP2=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_USER is not set
CONFIG_CRYPTO_MANAGER_DISABLE_TESTS=y
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_PCRYPT is not set
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
CONFIG_CRYPTO_AUTHENC=y
# CONFIG_CRYPTO_TEST is not set

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set

#
# Block modes
#
CONFIG_CRYPTO_CBC=y
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
# CONFIG_CRYPTO_ECB is not set
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set

#
# Hash modes
#
# CONFIG_CRYPTO_CMAC is not set
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set

#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CRC32C_INTEL is not set
# CONFIG_CRYPTO_CRC32 is not set
# CONFIG_CRYPTO_CRC32_PCLMUL is not set
# CONFIG_CRYPTO_CRCT10DIF is not set
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
CONFIG_CRYPTO_SHA1=y
# CONFIG_CRYPTO_SHA1_SSSE3 is not set
# CONFIG_CRYPTO_SHA256_SSSE3 is not set
# CONFIG_CRYPTO_SHA512_SSSE3 is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_X86_64 is not set
# CONFIG_CRYPTO_AES_NI_INTEL is not set
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_ARC4=y
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_BLOWFISH_X86_64 is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAMELLIA_X86_64 is not set
# CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64 is not set
# CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64 is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST5_AVX_X86_64 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_CAST6_AVX_X86_64 is not set
CONFIG_CRYPTO_DES=y
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SALSA20_X86_64 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_SERPENT_SSE2_X86_64 is not set
# CONFIG_CRYPTO_SERPENT_AVX_X86_64 is not set
# CONFIG_CRYPTO_SERPENT_AVX2_X86_64 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_X86_64 is not set
# CONFIG_CRYPTO_TWOFISH_X86_64_3WAY is not set
# CONFIG_CRYPTO_TWOFISH_AVX_X86_64 is not set

#
# Compression
#
# CONFIG_CRYPTO_DEFLATE is not set
# CONFIG_CRYPTO_ZLIB is not set
# CONFIG_CRYPTO_LZO is not set
# CONFIG_CRYPTO_LZ4 is not set
# CONFIG_CRYPTO_LZ4HC is not set

#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
# CONFIG_CRYPTO_USER_API_HASH is not set
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
CONFIG_CRYPTO_HW=y
# CONFIG_CRYPTO_DEV_PADLOCK is not set
# CONFIG_ASYMMETRIC_KEY_TYPE is not set
CONFIG_HAVE_KVM=y
CONFIG_VIRTUALIZATION=y
# CONFIG_KVM is not set
CONFIG_BINARY_PRINTF=y

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_NET_UTILS=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_IO=y
# CONFIG_CRC_CCITT is not set
CONFIG_CRC16=y
# CONFIG_CRC_T10DIF is not set
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
# CONFIG_CRC8 is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_LZ4_DECOMPRESS=y
CONFIG_XZ_DEC=y
CONFIG_XZ_DEC_X86=y
# CONFIG_XZ_DEC_POWERPC is not set
# CONFIG_XZ_DEC_IA64 is not set
# CONFIG_XZ_DEC_ARM is not set
# CONFIG_XZ_DEC_ARMTHUMB is not set
# CONFIG_XZ_DEC_SPARC is not set
CONFIG_XZ_DEC_BCJ=y
# CONFIG_XZ_DEC_TEST is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=y
CONFIG_DECOMPRESS_XZ=y
CONFIG_DECOMPRESS_LZO=y
CONFIG_DECOMPRESS_LZ4=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_CHECK_SIGNATURE=y
CONFIG_CPU_RMAP=y
CONFIG_DQL=y
CONFIG_NLATTR=y
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
CONFIG_AVERAGE=y
# CONFIG_CORDIC is not set
# CONFIG_DDR is not set
CONFIG_OID_REGISTRY=y
CONFIG_UCS2_STRING=y
CONFIG_FONT_SUPPORT=y
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 0/8] rcu: Ensure rcu read site is deadlock-immunity
  2013-08-07 19:29   ` Carsten Emde
  2013-08-07 19:52     ` Paul E. McKenney
@ 2013-08-08  1:17     ` Lai Jiangshan
  1 sibling, 0 replies; 49+ messages in thread
From: Lai Jiangshan @ 2013-08-08  1:17 UTC (permalink / raw)
  To: Carsten Emde; +Cc: paulmck, Steven Rostedt, Peter Zijlstra, linux-kernel

On 08/08/2013 03:29 AM, Carsten Emde wrote:
> Hi Paul,
> 
>>> Although all articles declare that rcu read site is deadlock-immunity.
>>> It is not true for rcu-preempt, it will be deadlock if rcu read site
>>> overlaps with scheduler lock.
>>
>> The real rule is that if the scheduler does its outermost rcu_read_unlock()
>> with one of those locks held, it has to have avoided enabling preemption
>> through the entire RCU read-side critical section.
>>
>> That said, avoiding the need for this rule would be a good thing.
>>
>> How did you test this?  The rcutorture tests will not exercise this.
>> (Intentionally so, given that it can deadlock!)
>>
>>> ec433f0c, 10f39bb1 and 016a8d5b just partially solve it. But rcu read site
>>> is still not deadlock-immunity. And the problem described in 016a8d5b
>>> is still existed(rcu_read_unlock_special() calls wake_up).
>>>
>>> The problem is fixed in patch5.
>>
>> This is going to require some serious review and testing.  One requirement
>> is that RCU priority boosting not persist significantly beyond the
>> re-enabling of interrupts associated with the irq-disabled lock.  To do
>> otherwise breaks RCU priority boosting.  At first glance, the added
>> set_need_resched() might handle this, but that is part of the review
>> and testing required.
>>
>> Steven, would you and Carsten be willing to try this and see if it
>> helps with the issues you are seeing in -rt?  (My guess is "no", since
>> a deadlock would block forever rather than waking up after a couple
>> thousand seconds, but worth a try.)
> Your guess was correct, applying this patch doesn't heal the NO_HZ_FULL+PREEMPT_RT_FULL 3.10.4 based system; it still is hanging at -> synchronize_rcu -> wait_rcu_gp.
> 
>     -Carsten.
> 

I didn't find the problem you reported, could you give me a url?

Thanx,
Lai

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 0/8] rcu: Ensure rcu read site is deadlock-immunity
  2013-08-08  0:36   ` Paul E. McKenney
@ 2013-08-08  1:47     ` Lai Jiangshan
  2013-08-08  2:12       ` Steven Rostedt
  0 siblings, 1 reply; 49+ messages in thread
From: Lai Jiangshan @ 2013-08-08  1:47 UTC (permalink / raw)
  To: paulmck; +Cc: Steven Rostedt, Peter Zijlstra, linux-kernel, C.Emde

On 08/08/2013 08:36 AM, Paul E. McKenney wrote:
> On Wed, Aug 07, 2013 at 05:38:27AM -0700, Paul E. McKenney wrote:
>> On Wed, Aug 07, 2013 at 06:24:56PM +0800, Lai Jiangshan wrote:
>>> Although all articles declare that rcu read site is deadlock-immunity.
>>> It is not true for rcu-preempt, it will be deadlock if rcu read site
>>> overlaps with scheduler lock.
>>
>> The real rule is that if the scheduler does its outermost rcu_read_unlock()
>> with one of those locks held, it has to have avoided enabling preemption
>> through the entire RCU read-side critical section.
>>
>> That said, avoiding the need for this rule would be a good thing.
>>
>> How did you test this?  The rcutorture tests will not exercise this.
>> (Intentionally so, given that it can deadlock!)
>>
>>> ec433f0c, 10f39bb1 and 016a8d5b just partially solve it. But rcu read site
>>> is still not deadlock-immunity. And the problem described in 016a8d5b
>>> is still existed(rcu_read_unlock_special() calls wake_up).
>>>
>>> The problem is fixed in patch5.
>>
>> This is going to require some serious review and testing.  One requirement
>> is that RCU priority boosting not persist significantly beyond the
>> re-enabling of interrupts associated with the irq-disabled lock.  To do
>> otherwise breaks RCU priority boosting.  At first glance, the added
>> set_need_resched() might handle this, but that is part of the review
>> and testing required.
>>
>> Steven, would you and Carsten be willing to try this and see if it
>> helps with the issues you are seeing in -rt?  (My guess is "no", since
>> a deadlock would block forever rather than waking up after a couple
>> thousand seconds, but worth a try.)
> 
> No joy from either Steven or Carsten on the -rt hangs.
> 
> I pushed this to -rcu and ran tests.  I hit this in one of the
> configurations:
> 
> [  393.641012] =================================
> [  393.641012] [ INFO: inconsistent lock state ]
> [  393.641012] 3.11.0-rc1+ #1 Not tainted
> [  393.641012] ---------------------------------
> [  393.641012] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
> [  393.641012] rcu_torture_rea/697 [HC1[1]:SC0[0]:HE0:SE1] takes:
> [  393.641012]  (&lock->wait_lock){?.+...}, at: [<ffffffff818860f3>] rt_mutex_unlock+0x53/0x100
> [  393.641012] {HARDIRQ-ON-W} state was registered at:
> [  393.641012]   [<ffffffff810aecb1>] __lock_acquire+0x651/0x1d40
> [  393.641012]   [<ffffffff810b0a65>] lock_acquire+0x95/0x210
> [  393.641012]   [<ffffffff81886d26>] _raw_spin_lock+0x36/0x50
> [  393.641012]   [<ffffffff81886329>] rt_mutex_slowlock+0x39/0x170
> [  393.641012]   [<ffffffff818864ca>] rt_mutex_lock+0x2a/0x30
> [  393.641012]   [<ffffffff810ebc03>] rcu_boost_kthread+0x173/0x800
> [  393.641012]   [<ffffffff810759d6>] kthread+0xd6/0xe0
> [  393.641012]   [<ffffffff8188f52c>] ret_from_fork+0x7c/0xb0
> [  393.641012] irq event stamp: 96581116
> [  393.641012] hardirqs last  enabled at (96581115): [<ffffffff81887ba0>] restore_args+0x0/0x30
> [  393.641012] hardirqs last disabled at (96581116): [<ffffffff8189022a>] apic_timer_interrupt+0x6a/0x80
> [  393.641012] softirqs last  enabled at (96576304): [<ffffffff81051844>] __do_softirq+0x174/0x470
> [  393.641012] softirqs last disabled at (96576275): [<ffffffff81051ca6>] irq_exit+0x96/0xc0
> [  393.641012] 
> [  393.641012] other info that might help us debug this:
> [  393.641012]  Possible unsafe locking scenario:
> [  393.641012] 
> [  393.641012]        CPU0
> [  393.641012]        ----
> [  393.641012]   lock(&lock->wait_lock);
> [  393.641012]   <Interrupt>
> [  393.641012]     lock(&lock->wait_lock);

Patch2 causes it!
When I found all lock which can (chained) nested in rcu_read_unlock_special(),
I didn't notice rtmutex's lock->wait_lock is not nested in irq-disabled.

Two ways to fix it:
1) change rtmutex's lock->wait_lock, make it alwasys irq-disabled.
2) revert my patch2

> [  393.641012] 
> [  393.641012]  *** DEADLOCK ***
> [  393.641012] 
> [  393.641012] no locks held by rcu_torture_rea/697.
> [  393.641012] 
> [  393.641012] stack backtrace:
> [  393.641012] CPU: 3 PID: 697 Comm: rcu_torture_rea Not tainted 3.11.0-rc1+ #1
> [  393.641012] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
> [  393.641012]  ffffffff8586fea0 ffff88001fcc3a78 ffffffff8187b4cb ffffffff8104a261
> [  393.641012]  ffff88001e1a20c0 ffff88001fcc3ad8 ffffffff818773e4 0000000000000000
> [  393.641012]  ffff880000000000 ffff880000000001 ffffffff81010a0a 0000000000000001
> [  393.641012] Call Trace:
> [  393.641012]  <IRQ>  [<ffffffff8187b4cb>] dump_stack+0x4f/0x84
> [  393.641012]  [<ffffffff8104a261>] ? console_unlock+0x291/0x410
> [  393.641012]  [<ffffffff818773e4>] print_usage_bug+0x1f5/0x206
> [  393.641012]  [<ffffffff81010a0a>] ? save_stack_trace+0x2a/0x50
> [  393.641012]  [<ffffffff810ae603>] mark_lock+0x283/0x2e0
> [  393.641012]  [<ffffffff810ada10>] ? print_irq_inversion_bug.part.40+0x1f0/0x1f0
> [  393.641012]  [<ffffffff810aef66>] __lock_acquire+0x906/0x1d40
> [  393.641012]  [<ffffffff810ae94b>] ? __lock_acquire+0x2eb/0x1d40
> [  393.641012]  [<ffffffff810ae94b>] ? __lock_acquire+0x2eb/0x1d40
> [  393.641012]  [<ffffffff810b0a65>] lock_acquire+0x95/0x210
> [  393.641012]  [<ffffffff818860f3>] ? rt_mutex_unlock+0x53/0x100
> [  393.641012]  [<ffffffff81886d26>] _raw_spin_lock+0x36/0x50
> [  393.641012]  [<ffffffff818860f3>] ? rt_mutex_unlock+0x53/0x100
> [  393.641012]  [<ffffffff818860f3>] rt_mutex_unlock+0x53/0x100
> [  393.641012]  [<ffffffff810ee3ca>] rcu_read_unlock_special+0x17a/0x2a0
> [  393.641012]  [<ffffffff810ee803>] rcu_check_callbacks+0x313/0x950
> [  393.641012]  [<ffffffff8107a6bd>] ? hrtimer_run_queues+0x1d/0x180
> [  393.641012]  [<ffffffff810abb9d>] ? trace_hardirqs_off+0xd/0x10
> [  393.641012]  [<ffffffff8105bae3>] update_process_times+0x43/0x80
> [  393.641012]  [<ffffffff810a9801>] tick_sched_handle.isra.10+0x31/0x40
> [  393.641012]  [<ffffffff810a98f7>] tick_sched_timer+0x47/0x70
> [  393.641012]  [<ffffffff8107941c>] __run_hrtimer+0x7c/0x490
> [  393.641012]  [<ffffffff810a260d>] ? ktime_get_update_offsets+0x4d/0xe0
> [  393.641012]  [<ffffffff810a98b0>] ? tick_nohz_handler+0xa0/0xa0
> [  393.641012]  [<ffffffff8107a017>] hrtimer_interrupt+0x107/0x260
> [  393.641012]  [<ffffffff81030173>] local_apic_timer_interrupt+0x33/0x60
> [  393.641012]  [<ffffffff8103059e>] smp_apic_timer_interrupt+0x3e/0x60
> [  393.641012]  [<ffffffff8189022f>] apic_timer_interrupt+0x6f/0x80
> [  393.641012]  <EOI>  [<ffffffff810ee250>] ? rcu_scheduler_starting+0x60/0x60
> [  393.641012]  [<ffffffff81072101>] ? __rcu_read_unlock+0x91/0xa0
> [  393.641012]  [<ffffffff810e80e3>] rcu_torture_read_unlock+0x33/0x70
> [  393.641012]  [<ffffffff810e8f54>] rcu_torture_reader+0xe4/0x450
> [  393.641012]  [<ffffffff810e92c0>] ? rcu_torture_reader+0x450/0x450
> [  393.641012]  [<ffffffff810e8e70>] ? rcutorture_trace_dump+0x30/0x30
> [  393.641012]  [<ffffffff810759d6>] kthread+0xd6/0xe0
> [  393.641012]  [<ffffffff818874bb>] ? _raw_spin_unlock_irq+0x2b/0x60
> [  393.641012]  [<ffffffff81075900>] ? flush_kthread_worker+0x130/0x130
> [  393.641012]  [<ffffffff8188f52c>] ret_from_fork+0x7c/0xb0
> [  393.641012]  [<ffffffff81075900>] ? flush_kthread_worker+0x130/0x130
> 
> I don't see this without your patches.
> 
> .config attached.  The other configurations completed without errors.
> Short tests, 30 minutes per configuration.
> 
> Thoughts?
> 
> 							Thanx, Paul


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 0/8] rcu: Ensure rcu read site is deadlock-immunity
  2013-08-08  1:47     ` Lai Jiangshan
@ 2013-08-08  2:12       ` Steven Rostedt
  2013-08-08  2:33         ` Lai Jiangshan
  2013-08-08  2:45         ` Lai Jiangshan
  0 siblings, 2 replies; 49+ messages in thread
From: Steven Rostedt @ 2013-08-08  2:12 UTC (permalink / raw)
  To: Lai Jiangshan; +Cc: paulmck, Peter Zijlstra, linux-kernel, C.Emde

On Thu, 2013-08-08 at 09:47 +0800, Lai Jiangshan wrote:

> > [  393.641012]        CPU0
> > [  393.641012]        ----
> > [  393.641012]   lock(&lock->wait_lock);
> > [  393.641012]   <Interrupt>
> > [  393.641012]     lock(&lock->wait_lock);
> 
> Patch2 causes it!
> When I found all lock which can (chained) nested in rcu_read_unlock_special(),
> I didn't notice rtmutex's lock->wait_lock is not nested in irq-disabled.
> 
> Two ways to fix it:
> 1) change rtmutex's lock->wait_lock, make it alwasys irq-disabled.
> 2) revert my patch2

Your patch 2 states:

"After patch 10f39bb1, "special & RCU_READ_UNLOCK_BLOCKED" can't be true
in irq nor softirq.(due to RCU_READ_UNLOCK_BLOCKED can only be set
when preemption)"

But then below we have:


> 
> > [  393.641012] 
> > [  393.641012]  *** DEADLOCK ***
> > [  393.641012] 
> > [  393.641012] no locks held by rcu_torture_rea/697.
> > [  393.641012] 
> > [  393.641012] stack backtrace:
> > [  393.641012] CPU: 3 PID: 697 Comm: rcu_torture_rea Not tainted 3.11.0-rc1+ #1
> > [  393.641012] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
> > [  393.641012]  ffffffff8586fea0 ffff88001fcc3a78 ffffffff8187b4cb ffffffff8104a261
> > [  393.641012]  ffff88001e1a20c0 ffff88001fcc3ad8 ffffffff818773e4 0000000000000000
> > [  393.641012]  ffff880000000000 ffff880000000001 ffffffff81010a0a 0000000000000001
> > [  393.641012] Call Trace:
> > [  393.641012]  <IRQ>  [<ffffffff8187b4cb>] dump_stack+0x4f/0x84
> > [  393.641012]  [<ffffffff8104a261>] ? console_unlock+0x291/0x410
> > [  393.641012]  [<ffffffff818773e4>] print_usage_bug+0x1f5/0x206
> > [  393.641012]  [<ffffffff81010a0a>] ? save_stack_trace+0x2a/0x50
> > [  393.641012]  [<ffffffff810ae603>] mark_lock+0x283/0x2e0
> > [  393.641012]  [<ffffffff810ada10>] ? print_irq_inversion_bug.part.40+0x1f0/0x1f0
> > [  393.641012]  [<ffffffff810aef66>] __lock_acquire+0x906/0x1d40
> > [  393.641012]  [<ffffffff810ae94b>] ? __lock_acquire+0x2eb/0x1d40
> > [  393.641012]  [<ffffffff810ae94b>] ? __lock_acquire+0x2eb/0x1d40
> > [  393.641012]  [<ffffffff810b0a65>] lock_acquire+0x95/0x210
> > [  393.641012]  [<ffffffff818860f3>] ? rt_mutex_unlock+0x53/0x100
> > [  393.641012]  [<ffffffff81886d26>] _raw_spin_lock+0x36/0x50
> > [  393.641012]  [<ffffffff818860f3>] ? rt_mutex_unlock+0x53/0x100
> > [  393.641012]  [<ffffffff818860f3>] rt_mutex_unlock+0x53/0x100
> > [  393.641012]  [<ffffffff810ee3ca>] rcu_read_unlock_special+0x17a/0x2a0
> > [  393.641012]  [<ffffffff810ee803>] rcu_check_callbacks+0x313/0x950
> > [  393.641012]  [<ffffffff8107a6bd>] ? hrtimer_run_queues+0x1d/0x180
> > [  393.641012]  [<ffffffff810abb9d>] ? trace_hardirqs_off+0xd/0x10
> > [  393.641012]  [<ffffffff8105bae3>] update_process_times+0x43/0x80
> > [  393.641012]  [<ffffffff810a9801>] tick_sched_handle.isra.10+0x31/0x40
> > [  393.641012]  [<ffffffff810a98f7>] tick_sched_timer+0x47/0x70
> > [  393.641012]  [<ffffffff8107941c>] __run_hrtimer+0x7c/0x490
> > [  393.641012]  [<ffffffff810a260d>] ? ktime_get_update_offsets+0x4d/0xe0
> > [  393.641012]  [<ffffffff810a98b0>] ? tick_nohz_handler+0xa0/0xa0
> > [  393.641012]  [<ffffffff8107a017>] hrtimer_interrupt+0x107/0x260

The hrtimer_interrupt is calling a rt_mutex_unlock? How did that happen?
Did it first call a rt_mutex_lock?

If patch two was the culprit, I'm thinking the idea behind patch two is
wrong. The only option is to remove patch number two!

Or perhaps I missed something.

-- Steve


> > [  393.641012]  [<ffffffff81030173>] local_apic_timer_interrupt+0x33/0x60
> > [  393.641012]  [<ffffffff8103059e>] smp_apic_timer_interrupt+0x3e/0x60
> > [  393.641012]  [<ffffffff8189022f>] apic_timer_interrupt+0x6f/0x80
> > [  393.641012]  <EOI>  [<ffffffff810ee250>] ? rcu_scheduler_starting+0x60/0x60
> > [  393.641012]  [<ffffffff81072101>] ? __rcu_read_unlock+0x91/0xa0
> > [  393.641012]  [<ffffffff810e80e3>] rcu_torture_read_unlock+0x33/0x70
> > [  393.641012]  [<ffffffff810e8f54>] rcu_torture_reader+0xe4/0x450
> > [  393.641012]  [<ffffffff810e92c0>] ? rcu_torture_reader+0x450/0x450
> > [  393.641012]  [<ffffffff810e8e70>] ? rcutorture_trace_dump+0x30/0x30
> > [  393.641012]  [<ffffffff810759d6>] kthread+0xd6/0xe0
> > [  393.641012]  [<ffffffff818874bb>] ? _raw_spin_unlock_irq+0x2b/0x60
> > [  393.641012]  [<ffffffff81075900>] ? flush_kthread_worker+0x130/0x130
> > [  393.641012]  [<ffffffff8188f52c>] ret_from_fork+0x7c/0xb0
> > [  393.641012]  [<ffffffff81075900>] ? flush_kthread_worker+0x130/0x130
> > 
> > I don't see this without your patches.
> > 
> > .config attached.  The other configurations completed without errors.
> > Short tests, 30 minutes per configuration.
> > 
> > Thoughts?
> > 
> > 							Thanx, Paul



^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 0/8] rcu: Ensure rcu read site is deadlock-immunity
  2013-08-08  2:12       ` Steven Rostedt
@ 2013-08-08  2:33         ` Lai Jiangshan
  2013-08-08  2:33           ` Paul E. McKenney
  2013-08-08  2:45         ` Lai Jiangshan
  1 sibling, 1 reply; 49+ messages in thread
From: Lai Jiangshan @ 2013-08-08  2:33 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: paulmck, Peter Zijlstra, linux-kernel, C.Emde

On 08/08/2013 10:12 AM, Steven Rostedt wrote:
> On Thu, 2013-08-08 at 09:47 +0800, Lai Jiangshan wrote:
> 
>>> [  393.641012]        CPU0
>>> [  393.641012]        ----
>>> [  393.641012]   lock(&lock->wait_lock);
>>> [  393.641012]   <Interrupt>
>>> [  393.641012]     lock(&lock->wait_lock);
>>
>> Patch2 causes it!
>> When I found all lock which can (chained) nested in rcu_read_unlock_special(),
>> I didn't notice rtmutex's lock->wait_lock is not nested in irq-disabled.
>>
>> Two ways to fix it:
>> 1) change rtmutex's lock->wait_lock, make it alwasys irq-disabled.
>> 2) revert my patch2
> 
> Your patch 2 states:
> 
> "After patch 10f39bb1, "special & RCU_READ_UNLOCK_BLOCKED" can't be true
> in irq nor softirq.(due to RCU_READ_UNLOCK_BLOCKED can only be set
> when preemption)"

Patch5 adds "special & RCU_READ_UNLOCK_BLOCKED" back in irq nor softirq.
This new thing is handle in patch5 if I did not do wrong things in patch5.
(I don't notice rtmutex's lock->wait_lock is not irqs-disabled in patch5)

> 
> But then below we have:
> 
> 
>>
>>> [  393.641012] 
>>> [  393.641012]  *** DEADLOCK ***
>>> [  393.641012] 
>>> [  393.641012] no locks held by rcu_torture_rea/697.
>>> [  393.641012] 
>>> [  393.641012] stack backtrace:
>>> [  393.641012] CPU: 3 PID: 697 Comm: rcu_torture_rea Not tainted 3.11.0-rc1+ #1
>>> [  393.641012] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
>>> [  393.641012]  ffffffff8586fea0 ffff88001fcc3a78 ffffffff8187b4cb ffffffff8104a261
>>> [  393.641012]  ffff88001e1a20c0 ffff88001fcc3ad8 ffffffff818773e4 0000000000000000
>>> [  393.641012]  ffff880000000000 ffff880000000001 ffffffff81010a0a 0000000000000001
>>> [  393.641012] Call Trace:
>>> [  393.641012]  <IRQ>  [<ffffffff8187b4cb>] dump_stack+0x4f/0x84
>>> [  393.641012]  [<ffffffff8104a261>] ? console_unlock+0x291/0x410
>>> [  393.641012]  [<ffffffff818773e4>] print_usage_bug+0x1f5/0x206
>>> [  393.641012]  [<ffffffff81010a0a>] ? save_stack_trace+0x2a/0x50
>>> [  393.641012]  [<ffffffff810ae603>] mark_lock+0x283/0x2e0
>>> [  393.641012]  [<ffffffff810ada10>] ? print_irq_inversion_bug.part.40+0x1f0/0x1f0
>>> [  393.641012]  [<ffffffff810aef66>] __lock_acquire+0x906/0x1d40
>>> [  393.641012]  [<ffffffff810ae94b>] ? __lock_acquire+0x2eb/0x1d40
>>> [  393.641012]  [<ffffffff810ae94b>] ? __lock_acquire+0x2eb/0x1d40
>>> [  393.641012]  [<ffffffff810b0a65>] lock_acquire+0x95/0x210
>>> [  393.641012]  [<ffffffff818860f3>] ? rt_mutex_unlock+0x53/0x100
>>> [  393.641012]  [<ffffffff81886d26>] _raw_spin_lock+0x36/0x50
>>> [  393.641012]  [<ffffffff818860f3>] ? rt_mutex_unlock+0x53/0x100
>>> [  393.641012]  [<ffffffff818860f3>] rt_mutex_unlock+0x53/0x100
>>> [  393.641012]  [<ffffffff810ee3ca>] rcu_read_unlock_special+0x17a/0x2a0
>>> [  393.641012]  [<ffffffff810ee803>] rcu_check_callbacks+0x313/0x950
>>> [  393.641012]  [<ffffffff8107a6bd>] ? hrtimer_run_queues+0x1d/0x180
>>> [  393.641012]  [<ffffffff810abb9d>] ? trace_hardirqs_off+0xd/0x10
>>> [  393.641012]  [<ffffffff8105bae3>] update_process_times+0x43/0x80
>>> [  393.641012]  [<ffffffff810a9801>] tick_sched_handle.isra.10+0x31/0x40
>>> [  393.641012]  [<ffffffff810a98f7>] tick_sched_timer+0x47/0x70
>>> [  393.641012]  [<ffffffff8107941c>] __run_hrtimer+0x7c/0x490
>>> [  393.641012]  [<ffffffff810a260d>] ? ktime_get_update_offsets+0x4d/0xe0
>>> [  393.641012]  [<ffffffff810a98b0>] ? tick_nohz_handler+0xa0/0xa0
>>> [  393.641012]  [<ffffffff8107a017>] hrtimer_interrupt+0x107/0x260
> 
> The hrtimer_interrupt is calling a rt_mutex_unlock? How did that happen?
> Did it first call a rt_mutex_lock?
> 
> If patch two was the culprit, I'm thinking the idea behind patch two is
> wrong. The only option is to remove patch number two!

removing patch number two can solve the problem found be Paul, but it is not the best.
because I can't declare that rcu is deadlock-immunity
(it will be deadlock if rcu read site overlaps with rtmutex's lock->wait_lock
if I only remove patch2)
I must do more things, but I think it is still better than changing rtmutex's lock->wait_lock.

Thanks,
Lai

> 
> Or perhaps I missed something.
> 
> -- Steve
> 
> 
>>> [  393.641012]  [<ffffffff81030173>] local_apic_timer_interrupt+0x33/0x60
>>> [  393.641012]  [<ffffffff8103059e>] smp_apic_timer_interrupt+0x3e/0x60
>>> [  393.641012]  [<ffffffff8189022f>] apic_timer_interrupt+0x6f/0x80
>>> [  393.641012]  <EOI>  [<ffffffff810ee250>] ? rcu_scheduler_starting+0x60/0x60
>>> [  393.641012]  [<ffffffff81072101>] ? __rcu_read_unlock+0x91/0xa0
>>> [  393.641012]  [<ffffffff810e80e3>] rcu_torture_read_unlock+0x33/0x70
>>> [  393.641012]  [<ffffffff810e8f54>] rcu_torture_reader+0xe4/0x450
>>> [  393.641012]  [<ffffffff810e92c0>] ? rcu_torture_reader+0x450/0x450
>>> [  393.641012]  [<ffffffff810e8e70>] ? rcutorture_trace_dump+0x30/0x30
>>> [  393.641012]  [<ffffffff810759d6>] kthread+0xd6/0xe0
>>> [  393.641012]  [<ffffffff818874bb>] ? _raw_spin_unlock_irq+0x2b/0x60
>>> [  393.641012]  [<ffffffff81075900>] ? flush_kthread_worker+0x130/0x130
>>> [  393.641012]  [<ffffffff8188f52c>] ret_from_fork+0x7c/0xb0
>>> [  393.641012]  [<ffffffff81075900>] ? flush_kthread_worker+0x130/0x130
>>>
>>> I don't see this without your patches.
>>>
>>> .config attached.  The other configurations completed without errors.
>>> Short tests, 30 minutes per configuration.
>>>
>>> Thoughts?
>>>
>>> 							Thanx, Paul
> 
> 
> 


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 0/8] rcu: Ensure rcu read site is deadlock-immunity
  2013-08-08  2:33         ` Lai Jiangshan
@ 2013-08-08  2:33           ` Paul E. McKenney
  2013-08-08  3:10             ` Lai Jiangshan
  0 siblings, 1 reply; 49+ messages in thread
From: Paul E. McKenney @ 2013-08-08  2:33 UTC (permalink / raw)
  To: Lai Jiangshan; +Cc: Steven Rostedt, Peter Zijlstra, linux-kernel, C.Emde

On Thu, Aug 08, 2013 at 10:33:15AM +0800, Lai Jiangshan wrote:
> On 08/08/2013 10:12 AM, Steven Rostedt wrote:
> > On Thu, 2013-08-08 at 09:47 +0800, Lai Jiangshan wrote:
> > 
> >>> [  393.641012]        CPU0
> >>> [  393.641012]        ----
> >>> [  393.641012]   lock(&lock->wait_lock);
> >>> [  393.641012]   <Interrupt>
> >>> [  393.641012]     lock(&lock->wait_lock);
> >>
> >> Patch2 causes it!
> >> When I found all lock which can (chained) nested in rcu_read_unlock_special(),
> >> I didn't notice rtmutex's lock->wait_lock is not nested in irq-disabled.
> >>
> >> Two ways to fix it:
> >> 1) change rtmutex's lock->wait_lock, make it alwasys irq-disabled.
> >> 2) revert my patch2
> > 
> > Your patch 2 states:
> > 
> > "After patch 10f39bb1, "special & RCU_READ_UNLOCK_BLOCKED" can't be true
> > in irq nor softirq.(due to RCU_READ_UNLOCK_BLOCKED can only be set
> > when preemption)"
> 
> Patch5 adds "special & RCU_READ_UNLOCK_BLOCKED" back in irq nor softirq.
> This new thing is handle in patch5 if I did not do wrong things in patch5.
> (I don't notice rtmutex's lock->wait_lock is not irqs-disabled in patch5)
> 
> > 
> > But then below we have:
> > 
> > 
> >>
> >>> [  393.641012] 
> >>> [  393.641012]  *** DEADLOCK ***
> >>> [  393.641012] 
> >>> [  393.641012] no locks held by rcu_torture_rea/697.
> >>> [  393.641012] 
> >>> [  393.641012] stack backtrace:
> >>> [  393.641012] CPU: 3 PID: 697 Comm: rcu_torture_rea Not tainted 3.11.0-rc1+ #1
> >>> [  393.641012] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
> >>> [  393.641012]  ffffffff8586fea0 ffff88001fcc3a78 ffffffff8187b4cb ffffffff8104a261
> >>> [  393.641012]  ffff88001e1a20c0 ffff88001fcc3ad8 ffffffff818773e4 0000000000000000
> >>> [  393.641012]  ffff880000000000 ffff880000000001 ffffffff81010a0a 0000000000000001
> >>> [  393.641012] Call Trace:
> >>> [  393.641012]  <IRQ>  [<ffffffff8187b4cb>] dump_stack+0x4f/0x84
> >>> [  393.641012]  [<ffffffff8104a261>] ? console_unlock+0x291/0x410
> >>> [  393.641012]  [<ffffffff818773e4>] print_usage_bug+0x1f5/0x206
> >>> [  393.641012]  [<ffffffff81010a0a>] ? save_stack_trace+0x2a/0x50
> >>> [  393.641012]  [<ffffffff810ae603>] mark_lock+0x283/0x2e0
> >>> [  393.641012]  [<ffffffff810ada10>] ? print_irq_inversion_bug.part.40+0x1f0/0x1f0
> >>> [  393.641012]  [<ffffffff810aef66>] __lock_acquire+0x906/0x1d40
> >>> [  393.641012]  [<ffffffff810ae94b>] ? __lock_acquire+0x2eb/0x1d40
> >>> [  393.641012]  [<ffffffff810ae94b>] ? __lock_acquire+0x2eb/0x1d40
> >>> [  393.641012]  [<ffffffff810b0a65>] lock_acquire+0x95/0x210
> >>> [  393.641012]  [<ffffffff818860f3>] ? rt_mutex_unlock+0x53/0x100
> >>> [  393.641012]  [<ffffffff81886d26>] _raw_spin_lock+0x36/0x50
> >>> [  393.641012]  [<ffffffff818860f3>] ? rt_mutex_unlock+0x53/0x100
> >>> [  393.641012]  [<ffffffff818860f3>] rt_mutex_unlock+0x53/0x100
> >>> [  393.641012]  [<ffffffff810ee3ca>] rcu_read_unlock_special+0x17a/0x2a0
> >>> [  393.641012]  [<ffffffff810ee803>] rcu_check_callbacks+0x313/0x950
> >>> [  393.641012]  [<ffffffff8107a6bd>] ? hrtimer_run_queues+0x1d/0x180
> >>> [  393.641012]  [<ffffffff810abb9d>] ? trace_hardirqs_off+0xd/0x10
> >>> [  393.641012]  [<ffffffff8105bae3>] update_process_times+0x43/0x80
> >>> [  393.641012]  [<ffffffff810a9801>] tick_sched_handle.isra.10+0x31/0x40
> >>> [  393.641012]  [<ffffffff810a98f7>] tick_sched_timer+0x47/0x70
> >>> [  393.641012]  [<ffffffff8107941c>] __run_hrtimer+0x7c/0x490
> >>> [  393.641012]  [<ffffffff810a260d>] ? ktime_get_update_offsets+0x4d/0xe0
> >>> [  393.641012]  [<ffffffff810a98b0>] ? tick_nohz_handler+0xa0/0xa0
> >>> [  393.641012]  [<ffffffff8107a017>] hrtimer_interrupt+0x107/0x260
> > 
> > The hrtimer_interrupt is calling a rt_mutex_unlock? How did that happen?
> > Did it first call a rt_mutex_lock?
> > 
> > If patch two was the culprit, I'm thinking the idea behind patch two is
> > wrong. The only option is to remove patch number two!
> 
> removing patch number two can solve the problem found be Paul, but it is not the best.
> because I can't declare that rcu is deadlock-immunity
> (it will be deadlock if rcu read site overlaps with rtmutex's lock->wait_lock
> if I only remove patch2)
> I must do more things, but I think it is still better than changing rtmutex's lock->wait_lock.

NP, I will remove your current patches and wait for an updated set.

							Thanx, Paul


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 0/8] rcu: Ensure rcu read site is deadlock-immunity
  2013-08-08  2:12       ` Steven Rostedt
  2013-08-08  2:33         ` Lai Jiangshan
@ 2013-08-08  2:45         ` Lai Jiangshan
  1 sibling, 0 replies; 49+ messages in thread
From: Lai Jiangshan @ 2013-08-08  2:45 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: paulmck, Peter Zijlstra, linux-kernel, C.Emde

On 08/08/2013 10:12 AM, Steven Rostedt wrote:
> On Thu, 2013-08-08 at 09:47 +0800, Lai Jiangshan wrote:
> 
>>> [  393.641012]        CPU0
>>> [  393.641012]        ----
>>> [  393.641012]   lock(&lock->wait_lock);
>>> [  393.641012]   <Interrupt>
>>> [  393.641012]     lock(&lock->wait_lock);
>>
>> Patch2 causes it!
>> When I found all lock which can (chained) nested in rcu_read_unlock_special(),
>> I didn't notice rtmutex's lock->wait_lock is not nested in irq-disabled.
>>
>> Two ways to fix it:
>> 1) change rtmutex's lock->wait_lock, make it alwasys irq-disabled.
>> 2) revert my patch2
> 
> Your patch 2 states:
> 
> "After patch 10f39bb1, "special & RCU_READ_UNLOCK_BLOCKED" can't be true
> in irq nor softirq.(due to RCU_READ_UNLOCK_BLOCKED can only be set
> when preemption)"
> 
> But then below we have:
> 
> 
>>
>>> [  393.641012] 
>>> [  393.641012]  *** DEADLOCK ***
>>> [  393.641012] 
>>> [  393.641012] no locks held by rcu_torture_rea/697.
>>> [  393.641012] 
>>> [  393.641012] stack backtrace:
>>> [  393.641012] CPU: 3 PID: 697 Comm: rcu_torture_rea Not tainted 3.11.0-rc1+ #1
>>> [  393.641012] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
>>> [  393.641012]  ffffffff8586fea0 ffff88001fcc3a78 ffffffff8187b4cb ffffffff8104a261
>>> [  393.641012]  ffff88001e1a20c0 ffff88001fcc3ad8 ffffffff818773e4 0000000000000000
>>> [  393.641012]  ffff880000000000 ffff880000000001 ffffffff81010a0a 0000000000000001
>>> [  393.641012] Call Trace:
>>> [  393.641012]  <IRQ>  [<ffffffff8187b4cb>] dump_stack+0x4f/0x84
>>> [  393.641012]  [<ffffffff8104a261>] ? console_unlock+0x291/0x410
>>> [  393.641012]  [<ffffffff818773e4>] print_usage_bug+0x1f5/0x206
>>> [  393.641012]  [<ffffffff81010a0a>] ? save_stack_trace+0x2a/0x50
>>> [  393.641012]  [<ffffffff810ae603>] mark_lock+0x283/0x2e0
>>> [  393.641012]  [<ffffffff810ada10>] ? print_irq_inversion_bug.part.40+0x1f0/0x1f0
>>> [  393.641012]  [<ffffffff810aef66>] __lock_acquire+0x906/0x1d40
>>> [  393.641012]  [<ffffffff810ae94b>] ? __lock_acquire+0x2eb/0x1d40
>>> [  393.641012]  [<ffffffff810ae94b>] ? __lock_acquire+0x2eb/0x1d40
>>> [  393.641012]  [<ffffffff810b0a65>] lock_acquire+0x95/0x210
>>> [  393.641012]  [<ffffffff818860f3>] ? rt_mutex_unlock+0x53/0x100
>>> [  393.641012]  [<ffffffff81886d26>] _raw_spin_lock+0x36/0x50
>>> [  393.641012]  [<ffffffff818860f3>] ? rt_mutex_unlock+0x53/0x100
>>> [  393.641012]  [<ffffffff818860f3>] rt_mutex_unlock+0x53/0x100
>>> [  393.641012]  [<ffffffff810ee3ca>] rcu_read_unlock_special+0x17a/0x2a0
>>> [  393.641012]  [<ffffffff810ee803>] rcu_check_callbacks+0x313/0x950
>>> [  393.641012]  [<ffffffff8107a6bd>] ? hrtimer_run_queues+0x1d/0x180
>>> [  393.641012]  [<ffffffff810abb9d>] ? trace_hardirqs_off+0xd/0x10
>>> [  393.641012]  [<ffffffff8105bae3>] update_process_times+0x43/0x80
>>> [  393.641012]  [<ffffffff810a9801>] tick_sched_handle.isra.10+0x31/0x40
>>> [  393.641012]  [<ffffffff810a98f7>] tick_sched_timer+0x47/0x70
>>> [  393.641012]  [<ffffffff8107941c>] __run_hrtimer+0x7c/0x490
>>> [  393.641012]  [<ffffffff810a260d>] ? ktime_get_update_offsets+0x4d/0xe0
>>> [  393.641012]  [<ffffffff810a98b0>] ? tick_nohz_handler+0xa0/0xa0
>>> [  393.641012]  [<ffffffff8107a017>] hrtimer_interrupt+0x107/0x260
> 
> The hrtimer_interrupt is calling a rt_mutex_unlock? How did that happen?
> Did it first call a rt_mutex_lock?

Sorry, I forgot to answer this question of yours.
rt_mutex_lock is held by a proxy way in rcu_boost thread.

	rt_mutex_init_proxy_locked(&mtx, t);
	t->rcu_boost_mutex = &mtx;
	raw_spin_unlock_irqrestore(&rnp->lock, flags);
	rt_mutex_lock(&mtx);  /* Side effect: boosts task t's priority. */
	rt_mutex_unlock(&mtx);  /* Keep lockdep happy. */

> 
> If patch two was the culprit, I'm thinking the idea behind patch two is
> wrong. The only option is to remove patch number two!
> 
> Or perhaps I missed something.
> 
> -- Steve
> 
> 
>>> [  393.641012]  [<ffffffff81030173>] local_apic_timer_interrupt+0x33/0x60
>>> [  393.641012]  [<ffffffff8103059e>] smp_apic_timer_interrupt+0x3e/0x60
>>> [  393.641012]  [<ffffffff8189022f>] apic_timer_interrupt+0x6f/0x80
>>> [  393.641012]  <EOI>  [<ffffffff810ee250>] ? rcu_scheduler_starting+0x60/0x60
>>> [  393.641012]  [<ffffffff81072101>] ? __rcu_read_unlock+0x91/0xa0
>>> [  393.641012]  [<ffffffff810e80e3>] rcu_torture_read_unlock+0x33/0x70
>>> [  393.641012]  [<ffffffff810e8f54>] rcu_torture_reader+0xe4/0x450
>>> [  393.641012]  [<ffffffff810e92c0>] ? rcu_torture_reader+0x450/0x450
>>> [  393.641012]  [<ffffffff810e8e70>] ? rcutorture_trace_dump+0x30/0x30
>>> [  393.641012]  [<ffffffff810759d6>] kthread+0xd6/0xe0
>>> [  393.641012]  [<ffffffff818874bb>] ? _raw_spin_unlock_irq+0x2b/0x60
>>> [  393.641012]  [<ffffffff81075900>] ? flush_kthread_worker+0x130/0x130
>>> [  393.641012]  [<ffffffff8188f52c>] ret_from_fork+0x7c/0xb0
>>> [  393.641012]  [<ffffffff81075900>] ? flush_kthread_worker+0x130/0x130
>>>
>>> I don't see this without your patches.
>>>
>>> .config attached.  The other configurations completed without errors.
>>> Short tests, 30 minutes per configuration.
>>>
>>> Thoughts?
>>>
>>> 							Thanx, Paul
> 
> 
> --
> 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/
> 


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 0/8] rcu: Ensure rcu read site is deadlock-immunity
  2013-08-08  2:33           ` Paul E. McKenney
@ 2013-08-08  3:10             ` Lai Jiangshan
  2013-08-08  4:18               ` Paul E. McKenney
  0 siblings, 1 reply; 49+ messages in thread
From: Lai Jiangshan @ 2013-08-08  3:10 UTC (permalink / raw)
  To: paulmck; +Cc: Steven Rostedt, Peter Zijlstra, linux-kernel, C.Emde

On 08/08/2013 10:33 AM, Paul E. McKenney wrote:
> On Thu, Aug 08, 2013 at 10:33:15AM +0800, Lai Jiangshan wrote:
>> On 08/08/2013 10:12 AM, Steven Rostedt wrote:
>>> On Thu, 2013-08-08 at 09:47 +0800, Lai Jiangshan wrote:
>>>
>>>>> [  393.641012]        CPU0
>>>>> [  393.641012]        ----
>>>>> [  393.641012]   lock(&lock->wait_lock);
>>>>> [  393.641012]   <Interrupt>
>>>>> [  393.641012]     lock(&lock->wait_lock);
>>>>
>>>> Patch2 causes it!
>>>> When I found all lock which can (chained) nested in rcu_read_unlock_special(),
>>>> I didn't notice rtmutex's lock->wait_lock is not nested in irq-disabled.
>>>>
>>>> Two ways to fix it:
>>>> 1) change rtmutex's lock->wait_lock, make it alwasys irq-disabled.
>>>> 2) revert my patch2
>>>
>>> Your patch 2 states:
>>>
>>> "After patch 10f39bb1, "special & RCU_READ_UNLOCK_BLOCKED" can't be true
>>> in irq nor softirq.(due to RCU_READ_UNLOCK_BLOCKED can only be set
>>> when preemption)"
>>
>> Patch5 adds "special & RCU_READ_UNLOCK_BLOCKED" back in irq nor softirq.
>> This new thing is handle in patch5 if I did not do wrong things in patch5.
>> (I don't notice rtmutex's lock->wait_lock is not irqs-disabled in patch5)
>>
>>>
>>> But then below we have:
>>>
>>>
>>>>
>>>>> [  393.641012] 
>>>>> [  393.641012]  *** DEADLOCK ***
>>>>> [  393.641012] 
>>>>> [  393.641012] no locks held by rcu_torture_rea/697.
>>>>> [  393.641012] 
>>>>> [  393.641012] stack backtrace:
>>>>> [  393.641012] CPU: 3 PID: 697 Comm: rcu_torture_rea Not tainted 3.11.0-rc1+ #1
>>>>> [  393.641012] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
>>>>> [  393.641012]  ffffffff8586fea0 ffff88001fcc3a78 ffffffff8187b4cb ffffffff8104a261
>>>>> [  393.641012]  ffff88001e1a20c0 ffff88001fcc3ad8 ffffffff818773e4 0000000000000000
>>>>> [  393.641012]  ffff880000000000 ffff880000000001 ffffffff81010a0a 0000000000000001
>>>>> [  393.641012] Call Trace:
>>>>> [  393.641012]  <IRQ>  [<ffffffff8187b4cb>] dump_stack+0x4f/0x84
>>>>> [  393.641012]  [<ffffffff8104a261>] ? console_unlock+0x291/0x410
>>>>> [  393.641012]  [<ffffffff818773e4>] print_usage_bug+0x1f5/0x206
>>>>> [  393.641012]  [<ffffffff81010a0a>] ? save_stack_trace+0x2a/0x50
>>>>> [  393.641012]  [<ffffffff810ae603>] mark_lock+0x283/0x2e0
>>>>> [  393.641012]  [<ffffffff810ada10>] ? print_irq_inversion_bug.part.40+0x1f0/0x1f0
>>>>> [  393.641012]  [<ffffffff810aef66>] __lock_acquire+0x906/0x1d40
>>>>> [  393.641012]  [<ffffffff810ae94b>] ? __lock_acquire+0x2eb/0x1d40
>>>>> [  393.641012]  [<ffffffff810ae94b>] ? __lock_acquire+0x2eb/0x1d40
>>>>> [  393.641012]  [<ffffffff810b0a65>] lock_acquire+0x95/0x210
>>>>> [  393.641012]  [<ffffffff818860f3>] ? rt_mutex_unlock+0x53/0x100
>>>>> [  393.641012]  [<ffffffff81886d26>] _raw_spin_lock+0x36/0x50
>>>>> [  393.641012]  [<ffffffff818860f3>] ? rt_mutex_unlock+0x53/0x100
>>>>> [  393.641012]  [<ffffffff818860f3>] rt_mutex_unlock+0x53/0x100
>>>>> [  393.641012]  [<ffffffff810ee3ca>] rcu_read_unlock_special+0x17a/0x2a0
>>>>> [  393.641012]  [<ffffffff810ee803>] rcu_check_callbacks+0x313/0x950
>>>>> [  393.641012]  [<ffffffff8107a6bd>] ? hrtimer_run_queues+0x1d/0x180
>>>>> [  393.641012]  [<ffffffff810abb9d>] ? trace_hardirqs_off+0xd/0x10
>>>>> [  393.641012]  [<ffffffff8105bae3>] update_process_times+0x43/0x80
>>>>> [  393.641012]  [<ffffffff810a9801>] tick_sched_handle.isra.10+0x31/0x40
>>>>> [  393.641012]  [<ffffffff810a98f7>] tick_sched_timer+0x47/0x70
>>>>> [  393.641012]  [<ffffffff8107941c>] __run_hrtimer+0x7c/0x490
>>>>> [  393.641012]  [<ffffffff810a260d>] ? ktime_get_update_offsets+0x4d/0xe0
>>>>> [  393.641012]  [<ffffffff810a98b0>] ? tick_nohz_handler+0xa0/0xa0
>>>>> [  393.641012]  [<ffffffff8107a017>] hrtimer_interrupt+0x107/0x260
>>>
>>> The hrtimer_interrupt is calling a rt_mutex_unlock? How did that happen?
>>> Did it first call a rt_mutex_lock?
>>>
>>> If patch two was the culprit, I'm thinking the idea behind patch two is
>>> wrong. The only option is to remove patch number two!
>>
>> removing patch number two can solve the problem found be Paul, but it is not the best.
>> because I can't declare that rcu is deadlock-immunity
>> (it will be deadlock if rcu read site overlaps with rtmutex's lock->wait_lock
>> if I only remove patch2)
>> I must do more things, but I think it is still better than changing rtmutex's lock->wait_lock.
> 
> NP, I will remove your current patches and wait for an updated set.

Hi, Paul

Could you agree that moving the rt_mutex_unlock() to rcu_preempt_note_context_switch()?

thanks,
Lai

> 
> 							Thanx, Paul
> 
> 


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 0/8] rcu: Ensure rcu read site is deadlock-immunity
  2013-08-08  3:10             ` Lai Jiangshan
@ 2013-08-08  4:18               ` Paul E. McKenney
  2013-08-08  5:27                 ` Lai Jiangshan
  0 siblings, 1 reply; 49+ messages in thread
From: Paul E. McKenney @ 2013-08-08  4:18 UTC (permalink / raw)
  To: Lai Jiangshan; +Cc: Steven Rostedt, Peter Zijlstra, linux-kernel, C.Emde

On Thu, Aug 08, 2013 at 11:10:47AM +0800, Lai Jiangshan wrote:
> On 08/08/2013 10:33 AM, Paul E. McKenney wrote:
> > On Thu, Aug 08, 2013 at 10:33:15AM +0800, Lai Jiangshan wrote:
> >> On 08/08/2013 10:12 AM, Steven Rostedt wrote:
> >>> On Thu, 2013-08-08 at 09:47 +0800, Lai Jiangshan wrote:
> >>>
> >>>>> [  393.641012]        CPU0
> >>>>> [  393.641012]        ----
> >>>>> [  393.641012]   lock(&lock->wait_lock);
> >>>>> [  393.641012]   <Interrupt>
> >>>>> [  393.641012]     lock(&lock->wait_lock);
> >>>>
> >>>> Patch2 causes it!
> >>>> When I found all lock which can (chained) nested in rcu_read_unlock_special(),
> >>>> I didn't notice rtmutex's lock->wait_lock is not nested in irq-disabled.
> >>>>
> >>>> Two ways to fix it:
> >>>> 1) change rtmutex's lock->wait_lock, make it alwasys irq-disabled.
> >>>> 2) revert my patch2
> >>>
> >>> Your patch 2 states:
> >>>
> >>> "After patch 10f39bb1, "special & RCU_READ_UNLOCK_BLOCKED" can't be true
> >>> in irq nor softirq.(due to RCU_READ_UNLOCK_BLOCKED can only be set
> >>> when preemption)"
> >>
> >> Patch5 adds "special & RCU_READ_UNLOCK_BLOCKED" back in irq nor softirq.
> >> This new thing is handle in patch5 if I did not do wrong things in patch5.
> >> (I don't notice rtmutex's lock->wait_lock is not irqs-disabled in patch5)
> >>
> >>>
> >>> But then below we have:
> >>>
> >>>
> >>>>
> >>>>> [  393.641012] 
> >>>>> [  393.641012]  *** DEADLOCK ***
> >>>>> [  393.641012] 
> >>>>> [  393.641012] no locks held by rcu_torture_rea/697.
> >>>>> [  393.641012] 
> >>>>> [  393.641012] stack backtrace:
> >>>>> [  393.641012] CPU: 3 PID: 697 Comm: rcu_torture_rea Not tainted 3.11.0-rc1+ #1
> >>>>> [  393.641012] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
> >>>>> [  393.641012]  ffffffff8586fea0 ffff88001fcc3a78 ffffffff8187b4cb ffffffff8104a261
> >>>>> [  393.641012]  ffff88001e1a20c0 ffff88001fcc3ad8 ffffffff818773e4 0000000000000000
> >>>>> [  393.641012]  ffff880000000000 ffff880000000001 ffffffff81010a0a 0000000000000001
> >>>>> [  393.641012] Call Trace:
> >>>>> [  393.641012]  <IRQ>  [<ffffffff8187b4cb>] dump_stack+0x4f/0x84
> >>>>> [  393.641012]  [<ffffffff8104a261>] ? console_unlock+0x291/0x410
> >>>>> [  393.641012]  [<ffffffff818773e4>] print_usage_bug+0x1f5/0x206
> >>>>> [  393.641012]  [<ffffffff81010a0a>] ? save_stack_trace+0x2a/0x50
> >>>>> [  393.641012]  [<ffffffff810ae603>] mark_lock+0x283/0x2e0
> >>>>> [  393.641012]  [<ffffffff810ada10>] ? print_irq_inversion_bug.part.40+0x1f0/0x1f0
> >>>>> [  393.641012]  [<ffffffff810aef66>] __lock_acquire+0x906/0x1d40
> >>>>> [  393.641012]  [<ffffffff810ae94b>] ? __lock_acquire+0x2eb/0x1d40
> >>>>> [  393.641012]  [<ffffffff810ae94b>] ? __lock_acquire+0x2eb/0x1d40
> >>>>> [  393.641012]  [<ffffffff810b0a65>] lock_acquire+0x95/0x210
> >>>>> [  393.641012]  [<ffffffff818860f3>] ? rt_mutex_unlock+0x53/0x100
> >>>>> [  393.641012]  [<ffffffff81886d26>] _raw_spin_lock+0x36/0x50
> >>>>> [  393.641012]  [<ffffffff818860f3>] ? rt_mutex_unlock+0x53/0x100
> >>>>> [  393.641012]  [<ffffffff818860f3>] rt_mutex_unlock+0x53/0x100

The really strange thing here is that I thought that your passing false
in as the new second parameter to rcu_read_unlock_special() was supposed
to prevent rt_mutex_unlock() from being called.

But then why is the call from rcu_preempt_note_context_switch() also
passing false?  I would have expected that one to pass true.  Probably
I don't understand your intent with the "unlock" argument.

> >>>>> [  393.641012]  [<ffffffff810ee3ca>] rcu_read_unlock_special+0x17a/0x2a0
> >>>>> [  393.641012]  [<ffffffff810ee803>] rcu_check_callbacks+0x313/0x950
> >>>>> [  393.641012]  [<ffffffff8107a6bd>] ? hrtimer_run_queues+0x1d/0x180
> >>>>> [  393.641012]  [<ffffffff810abb9d>] ? trace_hardirqs_off+0xd/0x10
> >>>>> [  393.641012]  [<ffffffff8105bae3>] update_process_times+0x43/0x80
> >>>>> [  393.641012]  [<ffffffff810a9801>] tick_sched_handle.isra.10+0x31/0x40
> >>>>> [  393.641012]  [<ffffffff810a98f7>] tick_sched_timer+0x47/0x70
> >>>>> [  393.641012]  [<ffffffff8107941c>] __run_hrtimer+0x7c/0x490
> >>>>> [  393.641012]  [<ffffffff810a260d>] ? ktime_get_update_offsets+0x4d/0xe0
> >>>>> [  393.641012]  [<ffffffff810a98b0>] ? tick_nohz_handler+0xa0/0xa0
> >>>>> [  393.641012]  [<ffffffff8107a017>] hrtimer_interrupt+0x107/0x260
> >>>
> >>> The hrtimer_interrupt is calling a rt_mutex_unlock? How did that happen?
> >>> Did it first call a rt_mutex_lock?
> >>>
> >>> If patch two was the culprit, I'm thinking the idea behind patch two is
> >>> wrong. The only option is to remove patch number two!
> >>
> >> removing patch number two can solve the problem found be Paul, but it is not the best.
> >> because I can't declare that rcu is deadlock-immunity
> >> (it will be deadlock if rcu read site overlaps with rtmutex's lock->wait_lock
> >> if I only remove patch2)
> >> I must do more things, but I think it is still better than changing rtmutex's lock->wait_lock.
> > 
> > NP, I will remove your current patches and wait for an updated set.
> 
> Hi, Paul
> 
> Could you agree that moving the rt_mutex_unlock() to rcu_preempt_note_context_switch()?

My guess is that changing rcu_preempt_note_context_switch()'s call to
rcu_read_unlock_special(t, true) would accomplish this in a nicer way.
Except that I would first need to understand why rcu_check_callbacks()'s
call to rcu_read_unlock_special() resulted in rt_mutex_unlock() being
called.

Oh!

In rcu_read_unlock_special, shouldn't the:

	if (unlikely(unlock && irqs_disabled_flags(flags))) {

Instead be:

	if (unlikely(!unlock || irqs_disabled_flags(flags))) {

Here I am guessing that the "unlock" parameter means "It is OK for
rcu_read_unlock_special() to invoke rt_mutex_unlock()", so it would be
passed in as false from rcu_check_callbacks() and true everywhere else.
If it means something else, please let me know what that might be.

Though at this point, it is not clear to me how it helps to call
rcu_read_unlock_special() from rcu_check_callbacks().  After all,
rcu_check_callbacks() has interrupts disabled always, and so it is never
safe for anything that it calls to invoke rt_mutex_unlock().

In any case, the opinion that really matters is not mine, but rather
that of the hundreds of millions of computer systems that might soon be
executing this code.  As RCU maintainer, I just try my best to predict
what their opinions will be.  ;-)

							Thanx, Paul

> thanks,
> Lai
> 
> > 
> > 							Thanx, Paul
> > 
> > 
> 


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 0/8] rcu: Ensure rcu read site is deadlock-immunity
  2013-08-08  4:18               ` Paul E. McKenney
@ 2013-08-08  5:27                 ` Lai Jiangshan
  2013-08-08  7:05                   ` Paul E. McKenney
  0 siblings, 1 reply; 49+ messages in thread
From: Lai Jiangshan @ 2013-08-08  5:27 UTC (permalink / raw)
  To: paulmck; +Cc: Steven Rostedt, Peter Zijlstra, linux-kernel, C.Emde

On 08/08/2013 12:18 PM, Paul E. McKenney wrote:
> On Thu, Aug 08, 2013 at 11:10:47AM +0800, Lai Jiangshan wrote:
>> On 08/08/2013 10:33 AM, Paul E. McKenney wrote:
>>> On Thu, Aug 08, 2013 at 10:33:15AM +0800, Lai Jiangshan wrote:
>>>> On 08/08/2013 10:12 AM, Steven Rostedt wrote:
>>>>> On Thu, 2013-08-08 at 09:47 +0800, Lai Jiangshan wrote:
>>>>>
>>>>>>> [  393.641012]        CPU0
>>>>>>> [  393.641012]        ----
>>>>>>> [  393.641012]   lock(&lock->wait_lock);
>>>>>>> [  393.641012]   <Interrupt>
>>>>>>> [  393.641012]     lock(&lock->wait_lock);
>>>>>>
>>>>>> Patch2 causes it!
>>>>>> When I found all lock which can (chained) nested in rcu_read_unlock_special(),
>>>>>> I didn't notice rtmutex's lock->wait_lock is not nested in irq-disabled.
>>>>>>
>>>>>> Two ways to fix it:
>>>>>> 1) change rtmutex's lock->wait_lock, make it alwasys irq-disabled.
>>>>>> 2) revert my patch2
>>>>>
>>>>> Your patch 2 states:
>>>>>
>>>>> "After patch 10f39bb1, "special & RCU_READ_UNLOCK_BLOCKED" can't be true
>>>>> in irq nor softirq.(due to RCU_READ_UNLOCK_BLOCKED can only be set
>>>>> when preemption)"
>>>>
>>>> Patch5 adds "special & RCU_READ_UNLOCK_BLOCKED" back in irq nor softirq.
>>>> This new thing is handle in patch5 if I did not do wrong things in patch5.
>>>> (I don't notice rtmutex's lock->wait_lock is not irqs-disabled in patch5)
>>>>
>>>>>
>>>>> But then below we have:
>>>>>
>>>>>
>>>>>>
>>>>>>> [  393.641012] 
>>>>>>> [  393.641012]  *** DEADLOCK ***
>>>>>>> [  393.641012] 
>>>>>>> [  393.641012] no locks held by rcu_torture_rea/697.
>>>>>>> [  393.641012] 
>>>>>>> [  393.641012] stack backtrace:
>>>>>>> [  393.641012] CPU: 3 PID: 697 Comm: rcu_torture_rea Not tainted 3.11.0-rc1+ #1
>>>>>>> [  393.641012] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
>>>>>>> [  393.641012]  ffffffff8586fea0 ffff88001fcc3a78 ffffffff8187b4cb ffffffff8104a261
>>>>>>> [  393.641012]  ffff88001e1a20c0 ffff88001fcc3ad8 ffffffff818773e4 0000000000000000
>>>>>>> [  393.641012]  ffff880000000000 ffff880000000001 ffffffff81010a0a 0000000000000001
>>>>>>> [  393.641012] Call Trace:
>>>>>>> [  393.641012]  <IRQ>  [<ffffffff8187b4cb>] dump_stack+0x4f/0x84
>>>>>>> [  393.641012]  [<ffffffff8104a261>] ? console_unlock+0x291/0x410
>>>>>>> [  393.641012]  [<ffffffff818773e4>] print_usage_bug+0x1f5/0x206
>>>>>>> [  393.641012]  [<ffffffff81010a0a>] ? save_stack_trace+0x2a/0x50
>>>>>>> [  393.641012]  [<ffffffff810ae603>] mark_lock+0x283/0x2e0
>>>>>>> [  393.641012]  [<ffffffff810ada10>] ? print_irq_inversion_bug.part.40+0x1f0/0x1f0
>>>>>>> [  393.641012]  [<ffffffff810aef66>] __lock_acquire+0x906/0x1d40
>>>>>>> [  393.641012]  [<ffffffff810ae94b>] ? __lock_acquire+0x2eb/0x1d40
>>>>>>> [  393.641012]  [<ffffffff810ae94b>] ? __lock_acquire+0x2eb/0x1d40
>>>>>>> [  393.641012]  [<ffffffff810b0a65>] lock_acquire+0x95/0x210
>>>>>>> [  393.641012]  [<ffffffff818860f3>] ? rt_mutex_unlock+0x53/0x100
>>>>>>> [  393.641012]  [<ffffffff81886d26>] _raw_spin_lock+0x36/0x50
>>>>>>> [  393.641012]  [<ffffffff818860f3>] ? rt_mutex_unlock+0x53/0x100
>>>>>>> [  393.641012]  [<ffffffff818860f3>] rt_mutex_unlock+0x53/0x100
> 
> The really strange thing here is that I thought that your passing false
> in as the new second parameter to rcu_read_unlock_special() was supposed
> to prevent rt_mutex_unlock() from being called.
> 
> But then why is the call from rcu_preempt_note_context_switch() also
> passing false?  I would have expected that one to pass true.  Probably
> I don't understand your intent with the "unlock" argument.
> 
>>>>>>> [  393.641012]  [<ffffffff810ee3ca>] rcu_read_unlock_special+0x17a/0x2a0
>>>>>>> [  393.641012]  [<ffffffff810ee803>] rcu_check_callbacks+0x313/0x950
>>>>>>> [  393.641012]  [<ffffffff8107a6bd>] ? hrtimer_run_queues+0x1d/0x180
>>>>>>> [  393.641012]  [<ffffffff810abb9d>] ? trace_hardirqs_off+0xd/0x10
>>>>>>> [  393.641012]  [<ffffffff8105bae3>] update_process_times+0x43/0x80
>>>>>>> [  393.641012]  [<ffffffff810a9801>] tick_sched_handle.isra.10+0x31/0x40
>>>>>>> [  393.641012]  [<ffffffff810a98f7>] tick_sched_timer+0x47/0x70
>>>>>>> [  393.641012]  [<ffffffff8107941c>] __run_hrtimer+0x7c/0x490
>>>>>>> [  393.641012]  [<ffffffff810a260d>] ? ktime_get_update_offsets+0x4d/0xe0
>>>>>>> [  393.641012]  [<ffffffff810a98b0>] ? tick_nohz_handler+0xa0/0xa0
>>>>>>> [  393.641012]  [<ffffffff8107a017>] hrtimer_interrupt+0x107/0x260
>>>>>
>>>>> The hrtimer_interrupt is calling a rt_mutex_unlock? How did that happen?
>>>>> Did it first call a rt_mutex_lock?
>>>>>
>>>>> If patch two was the culprit, I'm thinking the idea behind patch two is
>>>>> wrong. The only option is to remove patch number two!
>>>>
>>>> removing patch number two can solve the problem found be Paul, but it is not the best.
>>>> because I can't declare that rcu is deadlock-immunity
>>>> (it will be deadlock if rcu read site overlaps with rtmutex's lock->wait_lock
>>>> if I only remove patch2)
>>>> I must do more things, but I think it is still better than changing rtmutex's lock->wait_lock.
>>>
>>> NP, I will remove your current patches and wait for an updated set.
>>
>> Hi, Paul
>>
>> Could you agree that moving the rt_mutex_unlock() to rcu_preempt_note_context_switch()?
> 
> My guess is that changing rcu_preempt_note_context_switch()'s call to
> rcu_read_unlock_special(t, true) would accomplish this in a nicer way.
> Except that I would first need to understand why rcu_check_callbacks()'s
> call to rcu_read_unlock_special() resulted in rt_mutex_unlock() being
> called.
> 
> Oh!
> 
> In rcu_read_unlock_special, shouldn't the:
> 
> 	if (unlikely(unlock && irqs_disabled_flags(flags))) {

Sorry.
@unlock means it is called from rcu_read_unlock() path.

if rcu_read_unlock() is called from irqs_disabled context,
it may be called from suspect lock(scheduler locks, ...) context,
so it can't require rnp->lock or invoke wakeup() in rcu_read_unlock_special().


> 
> Instead be:
> 
> 	if (unlikely(!unlock || irqs_disabled_flags(flags))) {
> 
> Here I am guessing that the "unlock" parameter means "It is OK for
> rcu_read_unlock_special() to invoke rt_mutex_unlock()", so it would be
> passed in as false from rcu_check_callbacks() and true everywhere else.
> If it means something else, please let me know what that might be.
> 
> Though at this point, it is not clear to me how it helps to call
> rcu_read_unlock_special() from rcu_check_callbacks().  After all,
> rcu_check_callbacks() has interrupts disabled always, and so it is never
> safe for anything that it calls to invoke rt_mutex_unlock().
> 
> In any case, the opinion that really matters is not mine, but rather
> that of the hundreds of millions of computer systems that might soon be
> executing this code.  As RCU maintainer, I just try my best to predict
> what their opinions will be.  ;-)
> 
> 							Thanx, Paul
> 
>> thanks,
>> Lai
>>
>>>
>>> 							Thanx, Paul
>>>
>>>
>>
> 
> 


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 0/8] rcu: Ensure rcu read site is deadlock-immunity
  2013-08-08  5:27                 ` Lai Jiangshan
@ 2013-08-08  7:05                   ` Paul E. McKenney
  0 siblings, 0 replies; 49+ messages in thread
From: Paul E. McKenney @ 2013-08-08  7:05 UTC (permalink / raw)
  To: Lai Jiangshan; +Cc: Steven Rostedt, Peter Zijlstra, linux-kernel, C.Emde

On Thu, Aug 08, 2013 at 01:27:55PM +0800, Lai Jiangshan wrote:
> On 08/08/2013 12:18 PM, Paul E. McKenney wrote:
> > On Thu, Aug 08, 2013 at 11:10:47AM +0800, Lai Jiangshan wrote:
> >> On 08/08/2013 10:33 AM, Paul E. McKenney wrote:
> >>> On Thu, Aug 08, 2013 at 10:33:15AM +0800, Lai Jiangshan wrote:
> >>>> On 08/08/2013 10:12 AM, Steven Rostedt wrote:
> >>>>> On Thu, 2013-08-08 at 09:47 +0800, Lai Jiangshan wrote:
> >>>>>
> >>>>>>> [  393.641012]        CPU0
> >>>>>>> [  393.641012]        ----
> >>>>>>> [  393.641012]   lock(&lock->wait_lock);
> >>>>>>> [  393.641012]   <Interrupt>
> >>>>>>> [  393.641012]     lock(&lock->wait_lock);
> >>>>>>
> >>>>>> Patch2 causes it!
> >>>>>> When I found all lock which can (chained) nested in rcu_read_unlock_special(),
> >>>>>> I didn't notice rtmutex's lock->wait_lock is not nested in irq-disabled.
> >>>>>>
> >>>>>> Two ways to fix it:
> >>>>>> 1) change rtmutex's lock->wait_lock, make it alwasys irq-disabled.
> >>>>>> 2) revert my patch2
> >>>>>
> >>>>> Your patch 2 states:
> >>>>>
> >>>>> "After patch 10f39bb1, "special & RCU_READ_UNLOCK_BLOCKED" can't be true
> >>>>> in irq nor softirq.(due to RCU_READ_UNLOCK_BLOCKED can only be set
> >>>>> when preemption)"
> >>>>
> >>>> Patch5 adds "special & RCU_READ_UNLOCK_BLOCKED" back in irq nor softirq.
> >>>> This new thing is handle in patch5 if I did not do wrong things in patch5.
> >>>> (I don't notice rtmutex's lock->wait_lock is not irqs-disabled in patch5)
> >>>>
> >>>>>
> >>>>> But then below we have:
> >>>>>
> >>>>>
> >>>>>>
> >>>>>>> [  393.641012] 
> >>>>>>> [  393.641012]  *** DEADLOCK ***
> >>>>>>> [  393.641012] 
> >>>>>>> [  393.641012] no locks held by rcu_torture_rea/697.
> >>>>>>> [  393.641012] 
> >>>>>>> [  393.641012] stack backtrace:
> >>>>>>> [  393.641012] CPU: 3 PID: 697 Comm: rcu_torture_rea Not tainted 3.11.0-rc1+ #1
> >>>>>>> [  393.641012] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2007
> >>>>>>> [  393.641012]  ffffffff8586fea0 ffff88001fcc3a78 ffffffff8187b4cb ffffffff8104a261
> >>>>>>> [  393.641012]  ffff88001e1a20c0 ffff88001fcc3ad8 ffffffff818773e4 0000000000000000
> >>>>>>> [  393.641012]  ffff880000000000 ffff880000000001 ffffffff81010a0a 0000000000000001
> >>>>>>> [  393.641012] Call Trace:
> >>>>>>> [  393.641012]  <IRQ>  [<ffffffff8187b4cb>] dump_stack+0x4f/0x84
> >>>>>>> [  393.641012]  [<ffffffff8104a261>] ? console_unlock+0x291/0x410
> >>>>>>> [  393.641012]  [<ffffffff818773e4>] print_usage_bug+0x1f5/0x206
> >>>>>>> [  393.641012]  [<ffffffff81010a0a>] ? save_stack_trace+0x2a/0x50
> >>>>>>> [  393.641012]  [<ffffffff810ae603>] mark_lock+0x283/0x2e0
> >>>>>>> [  393.641012]  [<ffffffff810ada10>] ? print_irq_inversion_bug.part.40+0x1f0/0x1f0
> >>>>>>> [  393.641012]  [<ffffffff810aef66>] __lock_acquire+0x906/0x1d40
> >>>>>>> [  393.641012]  [<ffffffff810ae94b>] ? __lock_acquire+0x2eb/0x1d40
> >>>>>>> [  393.641012]  [<ffffffff810ae94b>] ? __lock_acquire+0x2eb/0x1d40
> >>>>>>> [  393.641012]  [<ffffffff810b0a65>] lock_acquire+0x95/0x210
> >>>>>>> [  393.641012]  [<ffffffff818860f3>] ? rt_mutex_unlock+0x53/0x100
> >>>>>>> [  393.641012]  [<ffffffff81886d26>] _raw_spin_lock+0x36/0x50
> >>>>>>> [  393.641012]  [<ffffffff818860f3>] ? rt_mutex_unlock+0x53/0x100
> >>>>>>> [  393.641012]  [<ffffffff818860f3>] rt_mutex_unlock+0x53/0x100
> > 
> > The really strange thing here is that I thought that your passing false
> > in as the new second parameter to rcu_read_unlock_special() was supposed
> > to prevent rt_mutex_unlock() from being called.
> > 
> > But then why is the call from rcu_preempt_note_context_switch() also
> > passing false?  I would have expected that one to pass true.  Probably
> > I don't understand your intent with the "unlock" argument.
> > 
> >>>>>>> [  393.641012]  [<ffffffff810ee3ca>] rcu_read_unlock_special+0x17a/0x2a0
> >>>>>>> [  393.641012]  [<ffffffff810ee803>] rcu_check_callbacks+0x313/0x950
> >>>>>>> [  393.641012]  [<ffffffff8107a6bd>] ? hrtimer_run_queues+0x1d/0x180
> >>>>>>> [  393.641012]  [<ffffffff810abb9d>] ? trace_hardirqs_off+0xd/0x10
> >>>>>>> [  393.641012]  [<ffffffff8105bae3>] update_process_times+0x43/0x80
> >>>>>>> [  393.641012]  [<ffffffff810a9801>] tick_sched_handle.isra.10+0x31/0x40
> >>>>>>> [  393.641012]  [<ffffffff810a98f7>] tick_sched_timer+0x47/0x70
> >>>>>>> [  393.641012]  [<ffffffff8107941c>] __run_hrtimer+0x7c/0x490
> >>>>>>> [  393.641012]  [<ffffffff810a260d>] ? ktime_get_update_offsets+0x4d/0xe0
> >>>>>>> [  393.641012]  [<ffffffff810a98b0>] ? tick_nohz_handler+0xa0/0xa0
> >>>>>>> [  393.641012]  [<ffffffff8107a017>] hrtimer_interrupt+0x107/0x260
> >>>>>
> >>>>> The hrtimer_interrupt is calling a rt_mutex_unlock? How did that happen?
> >>>>> Did it first call a rt_mutex_lock?
> >>>>>
> >>>>> If patch two was the culprit, I'm thinking the idea behind patch two is
> >>>>> wrong. The only option is to remove patch number two!
> >>>>
> >>>> removing patch number two can solve the problem found be Paul, but it is not the best.
> >>>> because I can't declare that rcu is deadlock-immunity
> >>>> (it will be deadlock if rcu read site overlaps with rtmutex's lock->wait_lock
> >>>> if I only remove patch2)
> >>>> I must do more things, but I think it is still better than changing rtmutex's lock->wait_lock.
> >>>
> >>> NP, I will remove your current patches and wait for an updated set.
> >>
> >> Hi, Paul
> >>
> >> Could you agree that moving the rt_mutex_unlock() to rcu_preempt_note_context_switch()?
> > 
> > My guess is that changing rcu_preempt_note_context_switch()'s call to
> > rcu_read_unlock_special(t, true) would accomplish this in a nicer way.
> > Except that I would first need to understand why rcu_check_callbacks()'s
> > call to rcu_read_unlock_special() resulted in rt_mutex_unlock() being
> > called.
> > 
> > Oh!
> > 
> > In rcu_read_unlock_special, shouldn't the:
> > 
> > 	if (unlikely(unlock && irqs_disabled_flags(flags))) {
> 
> Sorry.
> @unlock means it is called from rcu_read_unlock() path.
> 
> if rcu_read_unlock() is called from irqs_disabled context,
> it may be called from suspect lock(scheduler locks, ...) context,
> so it can't require rnp->lock or invoke wakeup() in rcu_read_unlock_special().

Hmmm...  And the case where it rcu_read_unlock_special() is
called from rcu_preempt_note_context_switch()?

							Thanx, Paul

> > Instead be:
> > 
> > 	if (unlikely(!unlock || irqs_disabled_flags(flags))) {
> > 
> > Here I am guessing that the "unlock" parameter means "It is OK for
> > rcu_read_unlock_special() to invoke rt_mutex_unlock()", so it would be
> > passed in as false from rcu_check_callbacks() and true everywhere else.
> > If it means something else, please let me know what that might be.
> > 
> > Though at this point, it is not clear to me how it helps to call
> > rcu_read_unlock_special() from rcu_check_callbacks().  After all,
> > rcu_check_callbacks() has interrupts disabled always, and so it is never
> > safe for anything that it calls to invoke rt_mutex_unlock().
> > 
> > In any case, the opinion that really matters is not mine, but rather
> > that of the hundreds of millions of computer systems that might soon be
> > executing this code.  As RCU maintainer, I just try my best to predict
> > what their opinions will be.  ;-)
> > 
> > 							Thanx, Paul
> > 
> >> thanks,
> >> Lai
> >>
> >>>
> >>> 							Thanx, Paul
> >>>
> >>>
> >>
> > 
> > 
> 


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 5/8] rcu: eliminate deadlock for rcu read site
  2013-08-07 10:25 ` [PATCH 5/8] rcu: eliminate deadlock for rcu read site Lai Jiangshan
@ 2013-08-08 20:40   ` Paul E. McKenney
  2013-08-09  9:31     ` Lai Jiangshan
  2013-08-10  3:43     ` Lai Jiangshan
  0 siblings, 2 replies; 49+ messages in thread
From: Paul E. McKenney @ 2013-08-08 20:40 UTC (permalink / raw)
  To: Lai Jiangshan
  Cc: Steven Rostedt, Peter Zijlstra, linux-kernel, Dipankar Sarma

On Wed, Aug 07, 2013 at 06:25:01PM +0800, Lai Jiangshan wrote:
> Background)
> 
> Although all articles declare that rcu read site is deadlock-immunity.
> It is not true for rcu-preempt, it will be deadlock if rcu read site
> overlaps with scheduler lock.
> 
> ec433f0c, 10f39bb1 and 016a8d5b just partially solve it. But rcu read site
> is still not deadlock-immunity. And the problem described in 016a8d5b
> is still existed(rcu_read_unlock_special() calls wake_up).
> 
> Aim)
> 
> We want to fix the problem forever, we want to keep rcu read site
> is deadlock-immunity as books say.
> 
> How)
> 
> The problem is solved by "if rcu_read_unlock_special() is called inside
> any lock which can be (chained) nested in rcu_read_unlock_special(),
> we defer rcu_read_unlock_special()".
> This kind locks include rnp->lock, scheduler locks, perf ctx->lock, locks
> in printk()/WARN_ON() and all locks nested in these locks or chained nested
> in these locks.
> 
> The problem is reduced to "how to distinguish all these locks(context)",
> We don't distinguish all these locks, we know that all these locks
> should be nested in local_irqs_disable().
> 
> we just consider if rcu_read_unlock_special() is called in irqs-disabled
> context, it may be called in these suspect locks, we should defer
> rcu_read_unlock_special().
> 
> The algorithm enlarges the probability of deferring, but the probability
> is still very very low.
> 
> Deferring does add a small overhead, but it offers us:
> 	1) really deadlock-immunity for rcu read site
> 	2) remove the overhead of the irq-work(250 times per second in avg.)

One problem here -- it may take quite some time for a set_need_resched()
to take effect.  This is especially a problem for RCU priority boosting,
but can also needlessly delay preemptible-RCU grace periods because
local_irq_restore() and friends don't check the TIF_NEED_RESCHED bit.

OK, alternatives...

o	Keep the current rule saying that if the scheduler is going
	to exit an RCU read-side critical section while holding
	one of its spinlocks, preemption has to have been disabled
	throughout the full duration of that critical section.
	Well, we can certainly do this, but it would be nice to get
	rid of this rule.

o	Use per-CPU variables, possibly injecting delay.  This has ugly
	disadvantages as noted above.

o	irq_work_queue() can wait a jiffy (or on some architectures,
	quite a bit longer) before actually doing anything.

o	raise_softirq() is more immediate and is an easy change, but
	adds a softirq vector -- which people are really trying to
	get rid of.  Also, wakeup_softirqd() calls things that acquire
	the scheduler locks, which is exactly what we were trying to
	avoid doing.

o	invoke_rcu_core() can invoke raise_softirq() as above.

o	IPI to self.  From what I can see, not all architectures
	support this.  Easy to fake if you have at least two CPUs,
	but not so good from an OS jitter viewpoint...

o	Add a check to local_irq_disable() and friends.  I would guess
	that this suggestion would not make architecture maintainers
	happy.

Other thoughts?

							Thanx, Paul

> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
> ---
>  include/linux/rcupdate.h |    2 +-
>  kernel/rcupdate.c        |    2 +-
>  kernel/rcutree_plugin.h  |   47 +++++++++++++++++++++++++++++++++++++++++----
>  3 files changed, 44 insertions(+), 7 deletions(-)
> 
> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> index 4b14bdc..00b4220 100644
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -180,7 +180,7 @@ extern void synchronize_sched(void);
> 
>  extern void __rcu_read_lock(void);
>  extern void __rcu_read_unlock(void);
> -extern void rcu_read_unlock_special(struct task_struct *t);
> +extern void rcu_read_unlock_special(struct task_struct *t, bool unlock);
>  void synchronize_rcu(void);
> 
>  /*
> diff --git a/kernel/rcupdate.c b/kernel/rcupdate.c
> index cce6ba8..33b89a3 100644
> --- a/kernel/rcupdate.c
> +++ b/kernel/rcupdate.c
> @@ -90,7 +90,7 @@ void __rcu_read_unlock(void)
>  #endif /* #ifdef CONFIG_PROVE_RCU_DELAY */
>  		barrier();  /* assign before ->rcu_read_unlock_special load */
>  		if (unlikely(ACCESS_ONCE(t->rcu_read_unlock_special)))
> -			rcu_read_unlock_special(t);
> +			rcu_read_unlock_special(t, true);
>  		barrier();  /* ->rcu_read_unlock_special load before assign */
>  		t->rcu_read_lock_nesting = 0;
>  	}
> diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
> index fc8b36f..997b424 100644
> --- a/kernel/rcutree_plugin.h
> +++ b/kernel/rcutree_plugin.h
> @@ -242,15 +242,16 @@ static void rcu_preempt_note_context_switch(int cpu)
>  				       ? rnp->gpnum
>  				       : rnp->gpnum + 1);
>  		raw_spin_unlock_irqrestore(&rnp->lock, flags);
> -	} else if (t->rcu_read_lock_nesting < 0 &&
> -		   !WARN_ON_ONCE(t->rcu_read_lock_nesting != INT_MIN) &&
> -		   t->rcu_read_unlock_special) {
> +	} else if (t->rcu_read_lock_nesting == 0 ||
> +		   (t->rcu_read_lock_nesting < 0 &&
> +		   !WARN_ON_ONCE(t->rcu_read_lock_nesting != INT_MIN))) {
> 
>  		/*
>  		 * Complete exit from RCU read-side critical section on
>  		 * behalf of preempted instance of __rcu_read_unlock().
>  		 */
> -		rcu_read_unlock_special(t);
> +		if (t->rcu_read_unlock_special)
> +			rcu_read_unlock_special(t, false);
>  	}
> 
>  	/*
> @@ -333,7 +334,7 @@ static struct list_head *rcu_next_node_entry(struct task_struct *t,
>   * notify RCU core processing or task having blocked during the RCU
>   * read-side critical section.
>   */
> -void rcu_read_unlock_special(struct task_struct *t)
> +void rcu_read_unlock_special(struct task_struct *t, bool unlock)
>  {
>  	int empty;
>  	int empty_exp;
> @@ -364,6 +365,42 @@ void rcu_read_unlock_special(struct task_struct *t)
> 
>  	/* Clean up if blocked during RCU read-side critical section. */
>  	if (special & RCU_READ_UNLOCK_BLOCKED) {
> +		/*
> +		 * If rcu read lock overlaps with scheduler lock,
> +		 * rcu_read_unlock_special() may lead to deadlock:
> +		 *
> +		 * rcu_read_lock();
> +		 * preempt_schedule[_irq]() (when preemption)
> +		 * scheduler lock; (or some other locks can be (chained) nested
> +		 *                  in rcu_read_unlock_special()/rnp->lock)
> +		 * access and check rcu data
> +		 * rcu_read_unlock();
> +		 *   rcu_read_unlock_special();
> +		 *     wake_up();                 DEAD LOCK
> +		 *
> +		 * To avoid all these kinds of deadlock, we should quit
> +		 * rcu_read_unlock_special() here and defer it to
> +		 * rcu_preempt_note_context_switch() or next outmost
> +		 * rcu_read_unlock() if we consider this case may happen.
> +		 *
> +		 * Although we can't know whether current _special()
> +		 * is nested in scheduler lock or not. But we know that
> +		 * irqs are always disabled in this case. so we just quit
> +		 * and defer it to rcu_preempt_note_context_switch()
> +		 * when irqs are disabled.
> +		 *
> +		 * It means we always defer _special() when it is
> +		 * nested in irqs disabled context, but
> +		 *	(special & RCU_READ_UNLOCK_BLOCKED) &&
> +		 *	irqs_disabled_flags(flags)
> +		 * is still unlikely to be true.
> +		 */
> +		if (unlikely(unlock && irqs_disabled_flags(flags))) {
> +			set_need_resched();
> +			local_irq_restore(flags);
> +			return;
> +		}
> +
>  		t->rcu_read_unlock_special &= ~RCU_READ_UNLOCK_BLOCKED;
> 
>  		/*
> -- 
> 1.7.4.4
> 


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 5/8] rcu: eliminate deadlock for rcu read site
  2013-08-08 20:40   ` Paul E. McKenney
@ 2013-08-09  9:31     ` Lai Jiangshan
  2013-08-09 17:58       ` Paul E. McKenney
  2013-08-12 13:55       ` Peter Zijlstra
  2013-08-10  3:43     ` Lai Jiangshan
  1 sibling, 2 replies; 49+ messages in thread
From: Lai Jiangshan @ 2013-08-09  9:31 UTC (permalink / raw)
  To: paulmck; +Cc: Steven Rostedt, Peter Zijlstra, linux-kernel, Dipankar Sarma

On 08/09/2013 04:40 AM, Paul E. McKenney wrote:
> On Wed, Aug 07, 2013 at 06:25:01PM +0800, Lai Jiangshan wrote:
>> Background)
>>
>> Although all articles declare that rcu read site is deadlock-immunity.
>> It is not true for rcu-preempt, it will be deadlock if rcu read site
>> overlaps with scheduler lock.
>>
>> ec433f0c, 10f39bb1 and 016a8d5b just partially solve it. But rcu read site
>> is still not deadlock-immunity. And the problem described in 016a8d5b
>> is still existed(rcu_read_unlock_special() calls wake_up).
>>
>> Aim)
>>
>> We want to fix the problem forever, we want to keep rcu read site
>> is deadlock-immunity as books say.
>>
>> How)
>>
>> The problem is solved by "if rcu_read_unlock_special() is called inside
>> any lock which can be (chained) nested in rcu_read_unlock_special(),
>> we defer rcu_read_unlock_special()".
>> This kind locks include rnp->lock, scheduler locks, perf ctx->lock, locks
>> in printk()/WARN_ON() and all locks nested in these locks or chained nested
>> in these locks.
>>
>> The problem is reduced to "how to distinguish all these locks(context)",
>> We don't distinguish all these locks, we know that all these locks
>> should be nested in local_irqs_disable().
>>
>> we just consider if rcu_read_unlock_special() is called in irqs-disabled
>> context, it may be called in these suspect locks, we should defer
>> rcu_read_unlock_special().
>>
>> The algorithm enlarges the probability of deferring, but the probability
>> is still very very low.
>>
>> Deferring does add a small overhead, but it offers us:
>> 	1) really deadlock-immunity for rcu read site
>> 	2) remove the overhead of the irq-work(250 times per second in avg.)
> 
> One problem here -- it may take quite some time for a set_need_resched()
> to take effect.  This is especially a problem for RCU priority boosting,
> but can also needlessly delay preemptible-RCU grace periods because
> local_irq_restore() and friends don't check the TIF_NEED_RESCHED bit.


The final effect of deboosting(rt_mutex_unlock()) is also accomplished
via set_need_resched()/set_tsk_need_resched().
set_need_resched() is enough for RCU priority boosting issue here.

Since rcu_read_unlock_special() is deferred, it does take quite some time for
QS report to take effect.


> 
> OK, alternatives...
> 
> o	Keep the current rule saying that if the scheduler is going
> 	to exit an RCU read-side critical section while holding
> 	one of its spinlocks, preemption has to have been disabled

Since rtmutex'lock->wait_lock is not irqs-disabled nor bh-disabled.

This kind of spinlocks include scheduler locks, rtmutex'lock->wait_lock,
all locks can be acquired in irq/SOFTIRQ.

So this rule is not only applied for scheduler locks, it should also
be applied for almost all spinlocks in the kernel.

I was hard to accept that rcu read site is not deadlock-immunity.

Thanks,
Lai

> 	throughout the full duration of that critical section.
> 	Well, we can certainly do this, but it would be nice to get
> 	rid of this rule.
> 
> o	Use per-CPU variables, possibly injecting delay.  This has ugly
> 	disadvantages as noted above.
> 
> o	irq_work_queue() can wait a jiffy (or on some architectures,
> 	quite a bit longer) before actually doing anything.
> 
> o	raise_softirq() is more immediate and is an easy change, but
> 	adds a softirq vector -- which people are really trying to
> 	get rid of.  Also, wakeup_softirqd() calls things that acquire
> 	the scheduler locks, which is exactly what we were trying to
> 	avoid doing.
> 
> o	invoke_rcu_core() can invoke raise_softirq() as above.
> 
> o	IPI to self.  From what I can see, not all architectures
> 	support this.  Easy to fake if you have at least two CPUs,
> 	but not so good from an OS jitter viewpoint...
> 
> o	Add a check to local_irq_disable() and friends.  I would guess
> 	that this suggestion would not make architecture maintainers
> 	happy.
> 
> Other thoughts?
> 
> 							Thanx, Paul
> 
>> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
>> ---
>>  include/linux/rcupdate.h |    2 +-
>>  kernel/rcupdate.c        |    2 +-
>>  kernel/rcutree_plugin.h  |   47 +++++++++++++++++++++++++++++++++++++++++----
>>  3 files changed, 44 insertions(+), 7 deletions(-)
>>
>> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
>> index 4b14bdc..00b4220 100644
>> --- a/include/linux/rcupdate.h
>> +++ b/include/linux/rcupdate.h
>> @@ -180,7 +180,7 @@ extern void synchronize_sched(void);
>>
>>  extern void __rcu_read_lock(void);
>>  extern void __rcu_read_unlock(void);
>> -extern void rcu_read_unlock_special(struct task_struct *t);
>> +extern void rcu_read_unlock_special(struct task_struct *t, bool unlock);
>>  void synchronize_rcu(void);
>>
>>  /*
>> diff --git a/kernel/rcupdate.c b/kernel/rcupdate.c
>> index cce6ba8..33b89a3 100644
>> --- a/kernel/rcupdate.c
>> +++ b/kernel/rcupdate.c
>> @@ -90,7 +90,7 @@ void __rcu_read_unlock(void)
>>  #endif /* #ifdef CONFIG_PROVE_RCU_DELAY */
>>  		barrier();  /* assign before ->rcu_read_unlock_special load */
>>  		if (unlikely(ACCESS_ONCE(t->rcu_read_unlock_special)))
>> -			rcu_read_unlock_special(t);
>> +			rcu_read_unlock_special(t, true);
>>  		barrier();  /* ->rcu_read_unlock_special load before assign */
>>  		t->rcu_read_lock_nesting = 0;
>>  	}
>> diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
>> index fc8b36f..997b424 100644
>> --- a/kernel/rcutree_plugin.h
>> +++ b/kernel/rcutree_plugin.h
>> @@ -242,15 +242,16 @@ static void rcu_preempt_note_context_switch(int cpu)
>>  				       ? rnp->gpnum
>>  				       : rnp->gpnum + 1);
>>  		raw_spin_unlock_irqrestore(&rnp->lock, flags);
>> -	} else if (t->rcu_read_lock_nesting < 0 &&
>> -		   !WARN_ON_ONCE(t->rcu_read_lock_nesting != INT_MIN) &&
>> -		   t->rcu_read_unlock_special) {
>> +	} else if (t->rcu_read_lock_nesting == 0 ||
>> +		   (t->rcu_read_lock_nesting < 0 &&
>> +		   !WARN_ON_ONCE(t->rcu_read_lock_nesting != INT_MIN))) {
>>
>>  		/*
>>  		 * Complete exit from RCU read-side critical section on
>>  		 * behalf of preempted instance of __rcu_read_unlock().
>>  		 */
>> -		rcu_read_unlock_special(t);
>> +		if (t->rcu_read_unlock_special)
>> +			rcu_read_unlock_special(t, false);
>>  	}
>>
>>  	/*
>> @@ -333,7 +334,7 @@ static struct list_head *rcu_next_node_entry(struct task_struct *t,
>>   * notify RCU core processing or task having blocked during the RCU
>>   * read-side critical section.
>>   */
>> -void rcu_read_unlock_special(struct task_struct *t)
>> +void rcu_read_unlock_special(struct task_struct *t, bool unlock)
>>  {
>>  	int empty;
>>  	int empty_exp;
>> @@ -364,6 +365,42 @@ void rcu_read_unlock_special(struct task_struct *t)
>>
>>  	/* Clean up if blocked during RCU read-side critical section. */
>>  	if (special & RCU_READ_UNLOCK_BLOCKED) {
>> +		/*
>> +		 * If rcu read lock overlaps with scheduler lock,
>> +		 * rcu_read_unlock_special() may lead to deadlock:
>> +		 *
>> +		 * rcu_read_lock();
>> +		 * preempt_schedule[_irq]() (when preemption)
>> +		 * scheduler lock; (or some other locks can be (chained) nested
>> +		 *                  in rcu_read_unlock_special()/rnp->lock)
>> +		 * access and check rcu data
>> +		 * rcu_read_unlock();
>> +		 *   rcu_read_unlock_special();
>> +		 *     wake_up();                 DEAD LOCK
>> +		 *
>> +		 * To avoid all these kinds of deadlock, we should quit
>> +		 * rcu_read_unlock_special() here and defer it to
>> +		 * rcu_preempt_note_context_switch() or next outmost
>> +		 * rcu_read_unlock() if we consider this case may happen.
>> +		 *
>> +		 * Although we can't know whether current _special()
>> +		 * is nested in scheduler lock or not. But we know that
>> +		 * irqs are always disabled in this case. so we just quit
>> +		 * and defer it to rcu_preempt_note_context_switch()
>> +		 * when irqs are disabled.
>> +		 *
>> +		 * It means we always defer _special() when it is
>> +		 * nested in irqs disabled context, but
>> +		 *	(special & RCU_READ_UNLOCK_BLOCKED) &&
>> +		 *	irqs_disabled_flags(flags)
>> +		 * is still unlikely to be true.
>> +		 */
>> +		if (unlikely(unlock && irqs_disabled_flags(flags))) {
>> +			set_need_resched();
>> +			local_irq_restore(flags);
>> +			return;
>> +		}
>> +
>>  		t->rcu_read_unlock_special &= ~RCU_READ_UNLOCK_BLOCKED;
>>
>>  		/*
>> -- 
>> 1.7.4.4
>>
> 
> 


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 5/8] rcu: eliminate deadlock for rcu read site
  2013-08-09  9:31     ` Lai Jiangshan
@ 2013-08-09 17:58       ` Paul E. McKenney
  2013-08-12 13:55       ` Peter Zijlstra
  1 sibling, 0 replies; 49+ messages in thread
From: Paul E. McKenney @ 2013-08-09 17:58 UTC (permalink / raw)
  To: Lai Jiangshan
  Cc: Steven Rostedt, Peter Zijlstra, linux-kernel, Dipankar Sarma

On Fri, Aug 09, 2013 at 05:31:27PM +0800, Lai Jiangshan wrote:
> On 08/09/2013 04:40 AM, Paul E. McKenney wrote:
> > On Wed, Aug 07, 2013 at 06:25:01PM +0800, Lai Jiangshan wrote:
> >> Background)
> >>
> >> Although all articles declare that rcu read site is deadlock-immunity.
> >> It is not true for rcu-preempt, it will be deadlock if rcu read site
> >> overlaps with scheduler lock.
> >>
> >> ec433f0c, 10f39bb1 and 016a8d5b just partially solve it. But rcu read site
> >> is still not deadlock-immunity. And the problem described in 016a8d5b
> >> is still existed(rcu_read_unlock_special() calls wake_up).
> >>
> >> Aim)
> >>
> >> We want to fix the problem forever, we want to keep rcu read site
> >> is deadlock-immunity as books say.
> >>
> >> How)
> >>
> >> The problem is solved by "if rcu_read_unlock_special() is called inside
> >> any lock which can be (chained) nested in rcu_read_unlock_special(),
> >> we defer rcu_read_unlock_special()".
> >> This kind locks include rnp->lock, scheduler locks, perf ctx->lock, locks
> >> in printk()/WARN_ON() and all locks nested in these locks or chained nested
> >> in these locks.
> >>
> >> The problem is reduced to "how to distinguish all these locks(context)",
> >> We don't distinguish all these locks, we know that all these locks
> >> should be nested in local_irqs_disable().
> >>
> >> we just consider if rcu_read_unlock_special() is called in irqs-disabled
> >> context, it may be called in these suspect locks, we should defer
> >> rcu_read_unlock_special().
> >>
> >> The algorithm enlarges the probability of deferring, but the probability
> >> is still very very low.
> >>
> >> Deferring does add a small overhead, but it offers us:
> >> 	1) really deadlock-immunity for rcu read site
> >> 	2) remove the overhead of the irq-work(250 times per second in avg.)
> > 
> > One problem here -- it may take quite some time for a set_need_resched()
> > to take effect.  This is especially a problem for RCU priority boosting,
> > but can also needlessly delay preemptible-RCU grace periods because
> > local_irq_restore() and friends don't check the TIF_NEED_RESCHED bit.
> 
> The final effect of deboosting(rt_mutex_unlock()) is also accomplished
> via set_need_resched()/set_tsk_need_resched().
> set_need_resched() is enough for RCU priority boosting issue here.

Eventually, yes.  But all that set_need_resched() does is set the
TIF_NEED_RESCHED.  This is checked by the outermost preempt_enable(),
return from interrupt, return to userspace, and things like
cond_resched().  So it might well be quite some time until the boosted
reader actually gets around to deboosting itself.

> Since rcu_read_unlock_special() is deferred, it does take quite some time for
> QS report to take effect.

Agreed.

> > OK, alternatives...
> > 
> > o	Keep the current rule saying that if the scheduler is going
> > 	to exit an RCU read-side critical section while holding
> > 	one of its spinlocks, preemption has to have been disabled
> 
> Since rtmutex'lock->wait_lock is not irqs-disabled nor bh-disabled.

Yep, because this rule prevents the call to rt_mutex_unlock() from
happening whenever one of the scheduler's irq-disable locks is held.

> This kind of spinlocks include scheduler locks, rtmutex'lock->wait_lock,
> all locks can be acquired in irq/SOFTIRQ.
> 
> So this rule is not only applied for scheduler locks, it should also
> be applied for almost all spinlocks in the kernel.

No, only those locks acquired by the scheduler in the wakeup path.
Or am I missing something here?

> I was hard to accept that rcu read site is not deadlock-immunity.

So did I, see http://lwn.net/Articles/453002/.  RCU was a victim of its
own success.  ;-)

And it would be really cool to restore full deadlock immunity to
rcu_read_unlock(), no two ways about it!  Hmmm...  Any way that a
self-IPI could be made safe for all architectures?

							Thanx, Paul

> Thanks,
> Lai
> 
> > 	throughout the full duration of that critical section.
> > 	Well, we can certainly do this, but it would be nice to get
> > 	rid of this rule.
> > 
> > o	Use per-CPU variables, possibly injecting delay.  This has ugly
> > 	disadvantages as noted above.
> > 
> > o	irq_work_queue() can wait a jiffy (or on some architectures,
> > 	quite a bit longer) before actually doing anything.
> > 
> > o	raise_softirq() is more immediate and is an easy change, but
> > 	adds a softirq vector -- which people are really trying to
> > 	get rid of.  Also, wakeup_softirqd() calls things that acquire
> > 	the scheduler locks, which is exactly what we were trying to
> > 	avoid doing.
> > 
> > o	invoke_rcu_core() can invoke raise_softirq() as above.
> > 
> > o	IPI to self.  From what I can see, not all architectures
> > 	support this.  Easy to fake if you have at least two CPUs,
> > 	but not so good from an OS jitter viewpoint...
> > 
> > o	Add a check to local_irq_disable() and friends.  I would guess
> > 	that this suggestion would not make architecture maintainers
> > 	happy.
> > 
> > Other thoughts?
> > 
> > 							Thanx, Paul
> > 
> >> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
> >> ---
> >>  include/linux/rcupdate.h |    2 +-
> >>  kernel/rcupdate.c        |    2 +-
> >>  kernel/rcutree_plugin.h  |   47 +++++++++++++++++++++++++++++++++++++++++----
> >>  3 files changed, 44 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> >> index 4b14bdc..00b4220 100644
> >> --- a/include/linux/rcupdate.h
> >> +++ b/include/linux/rcupdate.h
> >> @@ -180,7 +180,7 @@ extern void synchronize_sched(void);
> >>
> >>  extern void __rcu_read_lock(void);
> >>  extern void __rcu_read_unlock(void);
> >> -extern void rcu_read_unlock_special(struct task_struct *t);
> >> +extern void rcu_read_unlock_special(struct task_struct *t, bool unlock);
> >>  void synchronize_rcu(void);
> >>
> >>  /*
> >> diff --git a/kernel/rcupdate.c b/kernel/rcupdate.c
> >> index cce6ba8..33b89a3 100644
> >> --- a/kernel/rcupdate.c
> >> +++ b/kernel/rcupdate.c
> >> @@ -90,7 +90,7 @@ void __rcu_read_unlock(void)
> >>  #endif /* #ifdef CONFIG_PROVE_RCU_DELAY */
> >>  		barrier();  /* assign before ->rcu_read_unlock_special load */
> >>  		if (unlikely(ACCESS_ONCE(t->rcu_read_unlock_special)))
> >> -			rcu_read_unlock_special(t);
> >> +			rcu_read_unlock_special(t, true);
> >>  		barrier();  /* ->rcu_read_unlock_special load before assign */
> >>  		t->rcu_read_lock_nesting = 0;
> >>  	}
> >> diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
> >> index fc8b36f..997b424 100644
> >> --- a/kernel/rcutree_plugin.h
> >> +++ b/kernel/rcutree_plugin.h
> >> @@ -242,15 +242,16 @@ static void rcu_preempt_note_context_switch(int cpu)
> >>  				       ? rnp->gpnum
> >>  				       : rnp->gpnum + 1);
> >>  		raw_spin_unlock_irqrestore(&rnp->lock, flags);
> >> -	} else if (t->rcu_read_lock_nesting < 0 &&
> >> -		   !WARN_ON_ONCE(t->rcu_read_lock_nesting != INT_MIN) &&
> >> -		   t->rcu_read_unlock_special) {
> >> +	} else if (t->rcu_read_lock_nesting == 0 ||
> >> +		   (t->rcu_read_lock_nesting < 0 &&
> >> +		   !WARN_ON_ONCE(t->rcu_read_lock_nesting != INT_MIN))) {
> >>
> >>  		/*
> >>  		 * Complete exit from RCU read-side critical section on
> >>  		 * behalf of preempted instance of __rcu_read_unlock().
> >>  		 */
> >> -		rcu_read_unlock_special(t);
> >> +		if (t->rcu_read_unlock_special)
> >> +			rcu_read_unlock_special(t, false);
> >>  	}
> >>
> >>  	/*
> >> @@ -333,7 +334,7 @@ static struct list_head *rcu_next_node_entry(struct task_struct *t,
> >>   * notify RCU core processing or task having blocked during the RCU
> >>   * read-side critical section.
> >>   */
> >> -void rcu_read_unlock_special(struct task_struct *t)
> >> +void rcu_read_unlock_special(struct task_struct *t, bool unlock)
> >>  {
> >>  	int empty;
> >>  	int empty_exp;
> >> @@ -364,6 +365,42 @@ void rcu_read_unlock_special(struct task_struct *t)
> >>
> >>  	/* Clean up if blocked during RCU read-side critical section. */
> >>  	if (special & RCU_READ_UNLOCK_BLOCKED) {
> >> +		/*
> >> +		 * If rcu read lock overlaps with scheduler lock,
> >> +		 * rcu_read_unlock_special() may lead to deadlock:
> >> +		 *
> >> +		 * rcu_read_lock();
> >> +		 * preempt_schedule[_irq]() (when preemption)
> >> +		 * scheduler lock; (or some other locks can be (chained) nested
> >> +		 *                  in rcu_read_unlock_special()/rnp->lock)
> >> +		 * access and check rcu data
> >> +		 * rcu_read_unlock();
> >> +		 *   rcu_read_unlock_special();
> >> +		 *     wake_up();                 DEAD LOCK
> >> +		 *
> >> +		 * To avoid all these kinds of deadlock, we should quit
> >> +		 * rcu_read_unlock_special() here and defer it to
> >> +		 * rcu_preempt_note_context_switch() or next outmost
> >> +		 * rcu_read_unlock() if we consider this case may happen.
> >> +		 *
> >> +		 * Although we can't know whether current _special()
> >> +		 * is nested in scheduler lock or not. But we know that
> >> +		 * irqs are always disabled in this case. so we just quit
> >> +		 * and defer it to rcu_preempt_note_context_switch()
> >> +		 * when irqs are disabled.
> >> +		 *
> >> +		 * It means we always defer _special() when it is
> >> +		 * nested in irqs disabled context, but
> >> +		 *	(special & RCU_READ_UNLOCK_BLOCKED) &&
> >> +		 *	irqs_disabled_flags(flags)
> >> +		 * is still unlikely to be true.
> >> +		 */
> >> +		if (unlikely(unlock && irqs_disabled_flags(flags))) {
> >> +			set_need_resched();
> >> +			local_irq_restore(flags);
> >> +			return;
> >> +		}
> >> +
> >>  		t->rcu_read_unlock_special &= ~RCU_READ_UNLOCK_BLOCKED;
> >>
> >>  		/*
> >> -- 
> >> 1.7.4.4
> >>
> > 
> > 
> 


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 5/8] rcu: eliminate deadlock for rcu read site
  2013-08-08 20:40   ` Paul E. McKenney
  2013-08-09  9:31     ` Lai Jiangshan
@ 2013-08-10  3:43     ` Lai Jiangshan
  2013-08-10 15:07       ` Paul E. McKenney
  2013-08-12 13:53       ` Peter Zijlstra
  1 sibling, 2 replies; 49+ messages in thread
From: Lai Jiangshan @ 2013-08-10  3:43 UTC (permalink / raw)
  To: Steven Rostedt; +Cc: paulmck, Peter Zijlstra, linux-kernel, Dipankar Sarma

Hi, Steven

I was considering rtmutex's lock->wait_lock is a scheduler lock,
But it is not, and it is just a spinlock of process context.
I hope you change it to a spinlock of irq context.

1) it causes rcu read site more deadlockable, example:
x is a spinlock of softirq context.

CPU1					cpu2(rcu boost)
rcu_read_lock()				rt_mutext_lock()
<preemption and reschedule back>	raw_spin_lock(lock->wait_lock)
spin_lock_bh(x)				<interrupt and doing softirq after irq>
rcu_read_unlock()                         do_softirq()
  rcu_read_unlock_special()
    rt_mutext_unlock()
      raw_spin_lock(lock->wait_lock)	    spin_lock_bh(x)  DEADLOCK

This example can happen on any one of these code:
	without my patchset
	with my patchset
	with my patchset but reverted patch2

2) why it causes more deadlockable: it extends the range of suspect locks.
#DEFINE suspect locks: any lock can be (chained) nested in rcu_read_unlock_special().

So the suspect locks are: rnp->lock, scheduler locks, rtmutex's lock->wait_lock,
locks in prink()/WARN_ON() and the locks which can be chained/indirectly nested
in the above locks.

If the rtmutex's lock->wait_lock is a spinlock of irq context, all suspect locks are
some spinlocks of irq context.

If the rtmutex's lock->wait_lock is a spinlock of process context, suspect locks
will be extended to, all spinlocks of irq context, all spinlocks of softirq context,
and (all spinlocks of process context but nested in rtmutex's lock->wait_lock).

We can see from the definition, if rcu_read_unlock_special() is called from
any suspect lock, it may be deadlock like the example. the rtmutex's lock->wait_lock
extends the range of suspect locks, it causes more deadlockable.

3) How my algorithm works, why smaller range of suspect locks help us.
Since rcu_read_unlock_special() can't be called from suspect locks context,
we should defer rcu_read_unlock_special() when in these contexts.
It is hard to find out current context is suspect locks context or not,
but we can determine it based on irq/softirq/process context.

if all suspect locks are some spinlocks of irq context:
	if (irqs_disabled) /* we may be in suspect locks context */
		defer rcu_read_unlock_special().

if all suspect locks are some spinlocks of irq/softirq/process context:
	if (irqs_disabled || in_atomic()) /* we may be in suspect locks context */
		defer rcu_read_unlock_special().
In this case, the deferring becomes large more, I can't accept it.
So I have to narrow the range of suspect locks. Two choices:
A) don't call rt_mutex_unlock() from rcu_read_unlock(), only call it
   from rcu_preempt_not_context_switch(). we need to rework these
   two functions and it will add complexity to RCU, and it also still
   adds some probability of deferring.
B) change rtmutex's lock->wait_lock to irqs-disabled.

4) In the view of rtmutex, I think it will be better if ->wait_lock is irqs-disabled.
   A) like trylock of mutex/rw_sem, we may call rt_mutex_trylock() in irq in future.
   B) the critical section of ->wait_lock is short,
      making it irqs-disabled don't hurts responsibility/latency.
   C) almost all time of the critical section of ->wait_lock is irqs-disabled
      (due to task->pi_lock), I think converting whole time of the critical section
      of ->wait_lock to irqs-disabled is OK.

So I hope you change rtmutex's lock->wait_lock.

Any feedback from anyone is welcome.

Thanks,
Lai

On 08/09/2013 04:40 AM, Paul E. McKenney wrote:
> On Wed, Aug 07, 2013 at 06:25:01PM +0800, Lai Jiangshan wrote:
>> Background)
>>
>> Although all articles declare that rcu read site is deadlock-immunity.
>> It is not true for rcu-preempt, it will be deadlock if rcu read site
>> overlaps with scheduler lock.
>>
>> ec433f0c, 10f39bb1 and 016a8d5b just partially solve it. But rcu read site
>> is still not deadlock-immunity. And the problem described in 016a8d5b
>> is still existed(rcu_read_unlock_special() calls wake_up).
>>
>> Aim)
>>
>> We want to fix the problem forever, we want to keep rcu read site
>> is deadlock-immunity as books say.
>>
>> How)
>>
>> The problem is solved by "if rcu_read_unlock_special() is called inside
>> any lock which can be (chained) nested in rcu_read_unlock_special(),
>> we defer rcu_read_unlock_special()".
>> This kind locks include rnp->lock, scheduler locks, perf ctx->lock, locks
>> in printk()/WARN_ON() and all locks nested in these locks or chained nested
>> in these locks.
>>
>> The problem is reduced to "how to distinguish all these locks(context)",
>> We don't distinguish all these locks, we know that all these locks
>> should be nested in local_irqs_disable().
>>
>> we just consider if rcu_read_unlock_special() is called in irqs-disabled
>> context, it may be called in these suspect locks, we should defer
>> rcu_read_unlock_special().
>>
>> The algorithm enlarges the probability of deferring, but the probability
>> is still very very low.
>>
>> Deferring does add a small overhead, but it offers us:
>> 	1) really deadlock-immunity for rcu read site
>> 	2) remove the overhead of the irq-work(250 times per second in avg.)
> 
> One problem here -- it may take quite some time for a set_need_resched()
> to take effect.  This is especially a problem for RCU priority boosting,
> but can also needlessly delay preemptible-RCU grace periods because
> local_irq_restore() and friends don't check the TIF_NEED_RESCHED bit.
> 
> OK, alternatives...
> 
> o	Keep the current rule saying that if the scheduler is going
> 	to exit an RCU read-side critical section while holding
> 	one of its spinlocks, preemption has to have been disabled
> 	throughout the full duration of that critical section.
> 	Well, we can certainly do this, but it would be nice to get
> 	rid of this rule.
> 
> o	Use per-CPU variables, possibly injecting delay.  This has ugly
> 	disadvantages as noted above.
> 
> o	irq_work_queue() can wait a jiffy (or on some architectures,
> 	quite a bit longer) before actually doing anything.
> 
> o	raise_softirq() is more immediate and is an easy change, but
> 	adds a softirq vector -- which people are really trying to
> 	get rid of.  Also, wakeup_softirqd() calls things that acquire
> 	the scheduler locks, which is exactly what we were trying to
> 	avoid doing.
> 
> o	invoke_rcu_core() can invoke raise_softirq() as above.
> 
> o	IPI to self.  From what I can see, not all architectures
> 	support this.  Easy to fake if you have at least two CPUs,
> 	but not so good from an OS jitter viewpoint...
> 
> o	Add a check to local_irq_disable() and friends.  I would guess
> 	that this suggestion would not make architecture maintainers
> 	happy.
> 
> Other thoughts?
> 
> 							Thanx, Paul
> 
>> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
>> ---
>>  include/linux/rcupdate.h |    2 +-
>>  kernel/rcupdate.c        |    2 +-
>>  kernel/rcutree_plugin.h  |   47 +++++++++++++++++++++++++++++++++++++++++----
>>  3 files changed, 44 insertions(+), 7 deletions(-)
>>
>> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
>> index 4b14bdc..00b4220 100644
>> --- a/include/linux/rcupdate.h
>> +++ b/include/linux/rcupdate.h
>> @@ -180,7 +180,7 @@ extern void synchronize_sched(void);
>>
>>  extern void __rcu_read_lock(void);
>>  extern void __rcu_read_unlock(void);
>> -extern void rcu_read_unlock_special(struct task_struct *t);
>> +extern void rcu_read_unlock_special(struct task_struct *t, bool unlock);
>>  void synchronize_rcu(void);
>>
>>  /*
>> diff --git a/kernel/rcupdate.c b/kernel/rcupdate.c
>> index cce6ba8..33b89a3 100644
>> --- a/kernel/rcupdate.c
>> +++ b/kernel/rcupdate.c
>> @@ -90,7 +90,7 @@ void __rcu_read_unlock(void)
>>  #endif /* #ifdef CONFIG_PROVE_RCU_DELAY */
>>  		barrier();  /* assign before ->rcu_read_unlock_special load */
>>  		if (unlikely(ACCESS_ONCE(t->rcu_read_unlock_special)))
>> -			rcu_read_unlock_special(t);
>> +			rcu_read_unlock_special(t, true);
>>  		barrier();  /* ->rcu_read_unlock_special load before assign */
>>  		t->rcu_read_lock_nesting = 0;
>>  	}
>> diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
>> index fc8b36f..997b424 100644
>> --- a/kernel/rcutree_plugin.h
>> +++ b/kernel/rcutree_plugin.h
>> @@ -242,15 +242,16 @@ static void rcu_preempt_note_context_switch(int cpu)
>>  				       ? rnp->gpnum
>>  				       : rnp->gpnum + 1);
>>  		raw_spin_unlock_irqrestore(&rnp->lock, flags);
>> -	} else if (t->rcu_read_lock_nesting < 0 &&
>> -		   !WARN_ON_ONCE(t->rcu_read_lock_nesting != INT_MIN) &&
>> -		   t->rcu_read_unlock_special) {
>> +	} else if (t->rcu_read_lock_nesting == 0 ||
>> +		   (t->rcu_read_lock_nesting < 0 &&
>> +		   !WARN_ON_ONCE(t->rcu_read_lock_nesting != INT_MIN))) {
>>
>>  		/*
>>  		 * Complete exit from RCU read-side critical section on
>>  		 * behalf of preempted instance of __rcu_read_unlock().
>>  		 */
>> -		rcu_read_unlock_special(t);
>> +		if (t->rcu_read_unlock_special)
>> +			rcu_read_unlock_special(t, false);
>>  	}
>>
>>  	/*
>> @@ -333,7 +334,7 @@ static struct list_head *rcu_next_node_entry(struct task_struct *t,
>>   * notify RCU core processing or task having blocked during the RCU
>>   * read-side critical section.
>>   */
>> -void rcu_read_unlock_special(struct task_struct *t)
>> +void rcu_read_unlock_special(struct task_struct *t, bool unlock)
>>  {
>>  	int empty;
>>  	int empty_exp;
>> @@ -364,6 +365,42 @@ void rcu_read_unlock_special(struct task_struct *t)
>>
>>  	/* Clean up if blocked during RCU read-side critical section. */
>>  	if (special & RCU_READ_UNLOCK_BLOCKED) {
>> +		/*
>> +		 * If rcu read lock overlaps with scheduler lock,
>> +		 * rcu_read_unlock_special() may lead to deadlock:
>> +		 *
>> +		 * rcu_read_lock();
>> +		 * preempt_schedule[_irq]() (when preemption)
>> +		 * scheduler lock; (or some other locks can be (chained) nested
>> +		 *                  in rcu_read_unlock_special()/rnp->lock)
>> +		 * access and check rcu data
>> +		 * rcu_read_unlock();
>> +		 *   rcu_read_unlock_special();
>> +		 *     wake_up();                 DEAD LOCK
>> +		 *
>> +		 * To avoid all these kinds of deadlock, we should quit
>> +		 * rcu_read_unlock_special() here and defer it to
>> +		 * rcu_preempt_note_context_switch() or next outmost
>> +		 * rcu_read_unlock() if we consider this case may happen.
>> +		 *
>> +		 * Although we can't know whether current _special()
>> +		 * is nested in scheduler lock or not. But we know that
>> +		 * irqs are always disabled in this case. so we just quit
>> +		 * and defer it to rcu_preempt_note_context_switch()
>> +		 * when irqs are disabled.
>> +		 *
>> +		 * It means we always defer _special() when it is
>> +		 * nested in irqs disabled context, but
>> +		 *	(special & RCU_READ_UNLOCK_BLOCKED) &&
>> +		 *	irqs_disabled_flags(flags)
>> +		 * is still unlikely to be true.
>> +		 */
>> +		if (unlikely(unlock && irqs_disabled_flags(flags))) {
>> +			set_need_resched();
>> +			local_irq_restore(flags);
>> +			return;
>> +		}
>> +
>>  		t->rcu_read_unlock_special &= ~RCU_READ_UNLOCK_BLOCKED;
>>
>>  		/*
>> -- 
>> 1.7.4.4
>>
> 
> 


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 5/8] rcu: eliminate deadlock for rcu read site
  2013-08-10  3:43     ` Lai Jiangshan
@ 2013-08-10 15:07       ` Paul E. McKenney
  2013-08-10 15:08         ` Paul E. McKenney
  2013-08-21  3:17         ` Paul E. McKenney
  2013-08-12 13:53       ` Peter Zijlstra
  1 sibling, 2 replies; 49+ messages in thread
From: Paul E. McKenney @ 2013-08-10 15:07 UTC (permalink / raw)
  To: Lai Jiangshan
  Cc: Steven Rostedt, Peter Zijlstra, linux-kernel, Dipankar Sarma

On Sat, Aug 10, 2013 at 11:43:59AM +0800, Lai Jiangshan wrote:
> Hi, Steven
> 
> I was considering rtmutex's lock->wait_lock is a scheduler lock,
> But it is not, and it is just a spinlock of process context.
> I hope you change it to a spinlock of irq context.
> 
> 1) it causes rcu read site more deadlockable, example:
> x is a spinlock of softirq context.
> 
> CPU1					cpu2(rcu boost)
> rcu_read_lock()				rt_mutext_lock()
> <preemption and reschedule back>	raw_spin_lock(lock->wait_lock)
> spin_lock_bh(x)				<interrupt and doing softirq after irq>
> rcu_read_unlock()                         do_softirq()
>   rcu_read_unlock_special()
>     rt_mutext_unlock()
>       raw_spin_lock(lock->wait_lock)	    spin_lock_bh(x)  DEADLOCK
> 
> This example can happen on any one of these code:
> 	without my patchset
> 	with my patchset
> 	with my patchset but reverted patch2
> 
> 2) why it causes more deadlockable: it extends the range of suspect locks.
> #DEFINE suspect locks: any lock can be (chained) nested in rcu_read_unlock_special().
> 
> So the suspect locks are: rnp->lock, scheduler locks, rtmutex's lock->wait_lock,
> locks in prink()/WARN_ON() and the locks which can be chained/indirectly nested
> in the above locks.
> 
> If the rtmutex's lock->wait_lock is a spinlock of irq context, all suspect locks are
> some spinlocks of irq context.
> 
> If the rtmutex's lock->wait_lock is a spinlock of process context, suspect locks
> will be extended to, all spinlocks of irq context, all spinlocks of softirq context,
> and (all spinlocks of process context but nested in rtmutex's lock->wait_lock).
> 
> We can see from the definition, if rcu_read_unlock_special() is called from
> any suspect lock, it may be deadlock like the example. the rtmutex's lock->wait_lock
> extends the range of suspect locks, it causes more deadlockable.
> 
> 3) How my algorithm works, why smaller range of suspect locks help us.
> Since rcu_read_unlock_special() can't be called from suspect locks context,
> we should defer rcu_read_unlock_special() when in these contexts.
> It is hard to find out current context is suspect locks context or not,
> but we can determine it based on irq/softirq/process context.
> 
> if all suspect locks are some spinlocks of irq context:
> 	if (irqs_disabled) /* we may be in suspect locks context */
> 		defer rcu_read_unlock_special().
> 
> if all suspect locks are some spinlocks of irq/softirq/process context:
> 	if (irqs_disabled || in_atomic()) /* we may be in suspect locks context */
> 		defer rcu_read_unlock_special().
> In this case, the deferring becomes large more, I can't accept it.
> So I have to narrow the range of suspect locks. Two choices:
> A) don't call rt_mutex_unlock() from rcu_read_unlock(), only call it
>    from rcu_preempt_not_context_switch(). we need to rework these
>    two functions and it will add complexity to RCU, and it also still
>    adds some probability of deferring.

One advantage of bh-disable locks is that enabling bh checks
TIF_NEED_RESCHED, so that there is no deferring beyond that
needed by bh disable.  The same of course applies to preempt_disable().

So one approach is to defer when rcu_read_unlock_special() is entered
with either preemption or bh disabled.  Your current set_need_resched()
trick would work fine in this case.  Unfortunately, re-enabling interrupts
does -not- check TIF_NEED_RESCHED, which is why we have latency problems
in that case.  (Hence my earlier question about making self-IPI safe
on all arches, which would result in an interrupt as soon as interrupts
were re-enabled.)

Another possibility is to defer only when preemption or bh are disabled
on entry ro rcu_read_unlock_special(), but to retain the current
(admittedly ugly) nesting rules for the scheduler locks.

> B) change rtmutex's lock->wait_lock to irqs-disabled.

I have to defer to Steven on this one.

							Thanx, Paul

> 4) In the view of rtmutex, I think it will be better if ->wait_lock is irqs-disabled.
>    A) like trylock of mutex/rw_sem, we may call rt_mutex_trylock() in irq in future.
>    B) the critical section of ->wait_lock is short,
>       making it irqs-disabled don't hurts responsibility/latency.
>    C) almost all time of the critical section of ->wait_lock is irqs-disabled
>       (due to task->pi_lock), I think converting whole time of the critical section
>       of ->wait_lock to irqs-disabled is OK.
> 
> So I hope you change rtmutex's lock->wait_lock.
> 
> Any feedback from anyone is welcome.
> 
> Thanks,
> Lai
> 
> On 08/09/2013 04:40 AM, Paul E. McKenney wrote:
> > On Wed, Aug 07, 2013 at 06:25:01PM +0800, Lai Jiangshan wrote:
> >> Background)
> >>
> >> Although all articles declare that rcu read site is deadlock-immunity.
> >> It is not true for rcu-preempt, it will be deadlock if rcu read site
> >> overlaps with scheduler lock.
> >>
> >> ec433f0c, 10f39bb1 and 016a8d5b just partially solve it. But rcu read site
> >> is still not deadlock-immunity. And the problem described in 016a8d5b
> >> is still existed(rcu_read_unlock_special() calls wake_up).
> >>
> >> Aim)
> >>
> >> We want to fix the problem forever, we want to keep rcu read site
> >> is deadlock-immunity as books say.
> >>
> >> How)
> >>
> >> The problem is solved by "if rcu_read_unlock_special() is called inside
> >> any lock which can be (chained) nested in rcu_read_unlock_special(),
> >> we defer rcu_read_unlock_special()".
> >> This kind locks include rnp->lock, scheduler locks, perf ctx->lock, locks
> >> in printk()/WARN_ON() and all locks nested in these locks or chained nested
> >> in these locks.
> >>
> >> The problem is reduced to "how to distinguish all these locks(context)",
> >> We don't distinguish all these locks, we know that all these locks
> >> should be nested in local_irqs_disable().
> >>
> >> we just consider if rcu_read_unlock_special() is called in irqs-disabled
> >> context, it may be called in these suspect locks, we should defer
> >> rcu_read_unlock_special().
> >>
> >> The algorithm enlarges the probability of deferring, but the probability
> >> is still very very low.
> >>
> >> Deferring does add a small overhead, but it offers us:
> >> 	1) really deadlock-immunity for rcu read site
> >> 	2) remove the overhead of the irq-work(250 times per second in avg.)
> > 
> > One problem here -- it may take quite some time for a set_need_resched()
> > to take effect.  This is especially a problem for RCU priority boosting,
> > but can also needlessly delay preemptible-RCU grace periods because
> > local_irq_restore() and friends don't check the TIF_NEED_RESCHED bit.
> > 
> > OK, alternatives...
> > 
> > o	Keep the current rule saying that if the scheduler is going
> > 	to exit an RCU read-side critical section while holding
> > 	one of its spinlocks, preemption has to have been disabled
> > 	throughout the full duration of that critical section.
> > 	Well, we can certainly do this, but it would be nice to get
> > 	rid of this rule.
> > 
> > o	Use per-CPU variables, possibly injecting delay.  This has ugly
> > 	disadvantages as noted above.
> > 
> > o	irq_work_queue() can wait a jiffy (or on some architectures,
> > 	quite a bit longer) before actually doing anything.
> > 
> > o	raise_softirq() is more immediate and is an easy change, but
> > 	adds a softirq vector -- which people are really trying to
> > 	get rid of.  Also, wakeup_softirqd() calls things that acquire
> > 	the scheduler locks, which is exactly what we were trying to
> > 	avoid doing.
> > 
> > o	invoke_rcu_core() can invoke raise_softirq() as above.
> > 
> > o	IPI to self.  From what I can see, not all architectures
> > 	support this.  Easy to fake if you have at least two CPUs,
> > 	but not so good from an OS jitter viewpoint...
> > 
> > o	Add a check to local_irq_disable() and friends.  I would guess
> > 	that this suggestion would not make architecture maintainers
> > 	happy.
> > 
> > Other thoughts?
> > 
> > 							Thanx, Paul
> > 
> >> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
> >> ---
> >>  include/linux/rcupdate.h |    2 +-
> >>  kernel/rcupdate.c        |    2 +-
> >>  kernel/rcutree_plugin.h  |   47 +++++++++++++++++++++++++++++++++++++++++----
> >>  3 files changed, 44 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> >> index 4b14bdc..00b4220 100644
> >> --- a/include/linux/rcupdate.h
> >> +++ b/include/linux/rcupdate.h
> >> @@ -180,7 +180,7 @@ extern void synchronize_sched(void);
> >>
> >>  extern void __rcu_read_lock(void);
> >>  extern void __rcu_read_unlock(void);
> >> -extern void rcu_read_unlock_special(struct task_struct *t);
> >> +extern void rcu_read_unlock_special(struct task_struct *t, bool unlock);
> >>  void synchronize_rcu(void);
> >>
> >>  /*
> >> diff --git a/kernel/rcupdate.c b/kernel/rcupdate.c
> >> index cce6ba8..33b89a3 100644
> >> --- a/kernel/rcupdate.c
> >> +++ b/kernel/rcupdate.c
> >> @@ -90,7 +90,7 @@ void __rcu_read_unlock(void)
> >>  #endif /* #ifdef CONFIG_PROVE_RCU_DELAY */
> >>  		barrier();  /* assign before ->rcu_read_unlock_special load */
> >>  		if (unlikely(ACCESS_ONCE(t->rcu_read_unlock_special)))
> >> -			rcu_read_unlock_special(t);
> >> +			rcu_read_unlock_special(t, true);
> >>  		barrier();  /* ->rcu_read_unlock_special load before assign */
> >>  		t->rcu_read_lock_nesting = 0;
> >>  	}
> >> diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
> >> index fc8b36f..997b424 100644
> >> --- a/kernel/rcutree_plugin.h
> >> +++ b/kernel/rcutree_plugin.h
> >> @@ -242,15 +242,16 @@ static void rcu_preempt_note_context_switch(int cpu)
> >>  				       ? rnp->gpnum
> >>  				       : rnp->gpnum + 1);
> >>  		raw_spin_unlock_irqrestore(&rnp->lock, flags);
> >> -	} else if (t->rcu_read_lock_nesting < 0 &&
> >> -		   !WARN_ON_ONCE(t->rcu_read_lock_nesting != INT_MIN) &&
> >> -		   t->rcu_read_unlock_special) {
> >> +	} else if (t->rcu_read_lock_nesting == 0 ||
> >> +		   (t->rcu_read_lock_nesting < 0 &&
> >> +		   !WARN_ON_ONCE(t->rcu_read_lock_nesting != INT_MIN))) {
> >>
> >>  		/*
> >>  		 * Complete exit from RCU read-side critical section on
> >>  		 * behalf of preempted instance of __rcu_read_unlock().
> >>  		 */
> >> -		rcu_read_unlock_special(t);
> >> +		if (t->rcu_read_unlock_special)
> >> +			rcu_read_unlock_special(t, false);
> >>  	}
> >>
> >>  	/*
> >> @@ -333,7 +334,7 @@ static struct list_head *rcu_next_node_entry(struct task_struct *t,
> >>   * notify RCU core processing or task having blocked during the RCU
> >>   * read-side critical section.
> >>   */
> >> -void rcu_read_unlock_special(struct task_struct *t)
> >> +void rcu_read_unlock_special(struct task_struct *t, bool unlock)
> >>  {
> >>  	int empty;
> >>  	int empty_exp;
> >> @@ -364,6 +365,42 @@ void rcu_read_unlock_special(struct task_struct *t)
> >>
> >>  	/* Clean up if blocked during RCU read-side critical section. */
> >>  	if (special & RCU_READ_UNLOCK_BLOCKED) {
> >> +		/*
> >> +		 * If rcu read lock overlaps with scheduler lock,
> >> +		 * rcu_read_unlock_special() may lead to deadlock:
> >> +		 *
> >> +		 * rcu_read_lock();
> >> +		 * preempt_schedule[_irq]() (when preemption)
> >> +		 * scheduler lock; (or some other locks can be (chained) nested
> >> +		 *                  in rcu_read_unlock_special()/rnp->lock)
> >> +		 * access and check rcu data
> >> +		 * rcu_read_unlock();
> >> +		 *   rcu_read_unlock_special();
> >> +		 *     wake_up();                 DEAD LOCK
> >> +		 *
> >> +		 * To avoid all these kinds of deadlock, we should quit
> >> +		 * rcu_read_unlock_special() here and defer it to
> >> +		 * rcu_preempt_note_context_switch() or next outmost
> >> +		 * rcu_read_unlock() if we consider this case may happen.
> >> +		 *
> >> +		 * Although we can't know whether current _special()
> >> +		 * is nested in scheduler lock or not. But we know that
> >> +		 * irqs are always disabled in this case. so we just quit
> >> +		 * and defer it to rcu_preempt_note_context_switch()
> >> +		 * when irqs are disabled.
> >> +		 *
> >> +		 * It means we always defer _special() when it is
> >> +		 * nested in irqs disabled context, but
> >> +		 *	(special & RCU_READ_UNLOCK_BLOCKED) &&
> >> +		 *	irqs_disabled_flags(flags)
> >> +		 * is still unlikely to be true.
> >> +		 */
> >> +		if (unlikely(unlock && irqs_disabled_flags(flags))) {
> >> +			set_need_resched();
> >> +			local_irq_restore(flags);
> >> +			return;
> >> +		}
> >> +
> >>  		t->rcu_read_unlock_special &= ~RCU_READ_UNLOCK_BLOCKED;
> >>
> >>  		/*
> >> -- 
> >> 1.7.4.4
> >>
> > 
> > 
> 


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 5/8] rcu: eliminate deadlock for rcu read site
  2013-08-10 15:07       ` Paul E. McKenney
@ 2013-08-10 15:08         ` Paul E. McKenney
  2013-08-21  3:17         ` Paul E. McKenney
  1 sibling, 0 replies; 49+ messages in thread
From: Paul E. McKenney @ 2013-08-10 15:08 UTC (permalink / raw)
  To: Lai Jiangshan
  Cc: Steven Rostedt, Peter Zijlstra, linux-kernel, Dipankar Sarma

On Sat, Aug 10, 2013 at 08:07:15AM -0700, Paul E. McKenney wrote:
> On Sat, Aug 10, 2013 at 11:43:59AM +0800, Lai Jiangshan wrote:
> > Hi, Steven
> > 
> > I was considering rtmutex's lock->wait_lock is a scheduler lock,
> > But it is not, and it is just a spinlock of process context.
> > I hope you change it to a spinlock of irq context.
> > 
> > 1) it causes rcu read site more deadlockable, example:
> > x is a spinlock of softirq context.
> > 
> > CPU1					cpu2(rcu boost)
> > rcu_read_lock()				rt_mutext_lock()
> > <preemption and reschedule back>	raw_spin_lock(lock->wait_lock)
> > spin_lock_bh(x)				<interrupt and doing softirq after irq>
> > rcu_read_unlock()                         do_softirq()
> >   rcu_read_unlock_special()
> >     rt_mutext_unlock()
> >       raw_spin_lock(lock->wait_lock)	    spin_lock_bh(x)  DEADLOCK
> > 
> > This example can happen on any one of these code:
> > 	without my patchset
> > 	with my patchset
> > 	with my patchset but reverted patch2
> > 
> > 2) why it causes more deadlockable: it extends the range of suspect locks.
> > #DEFINE suspect locks: any lock can be (chained) nested in rcu_read_unlock_special().
> > 
> > So the suspect locks are: rnp->lock, scheduler locks, rtmutex's lock->wait_lock,
> > locks in prink()/WARN_ON() and the locks which can be chained/indirectly nested
> > in the above locks.
> > 
> > If the rtmutex's lock->wait_lock is a spinlock of irq context, all suspect locks are
> > some spinlocks of irq context.
> > 
> > If the rtmutex's lock->wait_lock is a spinlock of process context, suspect locks
> > will be extended to, all spinlocks of irq context, all spinlocks of softirq context,
> > and (all spinlocks of process context but nested in rtmutex's lock->wait_lock).
> > 
> > We can see from the definition, if rcu_read_unlock_special() is called from
> > any suspect lock, it may be deadlock like the example. the rtmutex's lock->wait_lock
> > extends the range of suspect locks, it causes more deadlockable.
> > 
> > 3) How my algorithm works, why smaller range of suspect locks help us.
> > Since rcu_read_unlock_special() can't be called from suspect locks context,
> > we should defer rcu_read_unlock_special() when in these contexts.
> > It is hard to find out current context is suspect locks context or not,
> > but we can determine it based on irq/softirq/process context.
> > 
> > if all suspect locks are some spinlocks of irq context:
> > 	if (irqs_disabled) /* we may be in suspect locks context */
> > 		defer rcu_read_unlock_special().
> > 
> > if all suspect locks are some spinlocks of irq/softirq/process context:
> > 	if (irqs_disabled || in_atomic()) /* we may be in suspect locks context */
> > 		defer rcu_read_unlock_special().
> > In this case, the deferring becomes large more, I can't accept it.
> > So I have to narrow the range of suspect locks. Two choices:
> > A) don't call rt_mutex_unlock() from rcu_read_unlock(), only call it
> >    from rcu_preempt_not_context_switch(). we need to rework these
> >    two functions and it will add complexity to RCU, and it also still
> >    adds some probability of deferring.
> 
> One advantage of bh-disable locks is that enabling bh checks
> TIF_NEED_RESCHED, so that there is no deferring beyond that
> needed by bh disable.  The same of course applies to preempt_disable().
> 
> So one approach is to defer when rcu_read_unlock_special() is entered
> with either preemption or bh disabled.  Your current set_need_resched()
> trick would work fine in this case.  Unfortunately, re-enabling interrupts
> does -not- check TIF_NEED_RESCHED, which is why we have latency problems
> in that case.  (Hence my earlier question about making self-IPI safe
> on all arches, which would result in an interrupt as soon as interrupts
> were re-enabled.)
> 
> Another possibility is to defer only when preemption or bh are disabled
> on entry ro rcu_read_unlock_special(), but to retain the current
> (admittedly ugly) nesting rules for the scheduler locks.
> 
> > B) change rtmutex's lock->wait_lock to irqs-disabled.
> 
> I have to defer to Steven on this one.

C) Remove support for RCU priority boosting.

I am reluctant to do this, but...

							Thanx, Paul

> > 4) In the view of rtmutex, I think it will be better if ->wait_lock is irqs-disabled.
> >    A) like trylock of mutex/rw_sem, we may call rt_mutex_trylock() in irq in future.
> >    B) the critical section of ->wait_lock is short,
> >       making it irqs-disabled don't hurts responsibility/latency.
> >    C) almost all time of the critical section of ->wait_lock is irqs-disabled
> >       (due to task->pi_lock), I think converting whole time of the critical section
> >       of ->wait_lock to irqs-disabled is OK.
> > 
> > So I hope you change rtmutex's lock->wait_lock.
> > 
> > Any feedback from anyone is welcome.
> > 
> > Thanks,
> > Lai
> > 
> > On 08/09/2013 04:40 AM, Paul E. McKenney wrote:
> > > On Wed, Aug 07, 2013 at 06:25:01PM +0800, Lai Jiangshan wrote:
> > >> Background)
> > >>
> > >> Although all articles declare that rcu read site is deadlock-immunity.
> > >> It is not true for rcu-preempt, it will be deadlock if rcu read site
> > >> overlaps with scheduler lock.
> > >>
> > >> ec433f0c, 10f39bb1 and 016a8d5b just partially solve it. But rcu read site
> > >> is still not deadlock-immunity. And the problem described in 016a8d5b
> > >> is still existed(rcu_read_unlock_special() calls wake_up).
> > >>
> > >> Aim)
> > >>
> > >> We want to fix the problem forever, we want to keep rcu read site
> > >> is deadlock-immunity as books say.
> > >>
> > >> How)
> > >>
> > >> The problem is solved by "if rcu_read_unlock_special() is called inside
> > >> any lock which can be (chained) nested in rcu_read_unlock_special(),
> > >> we defer rcu_read_unlock_special()".
> > >> This kind locks include rnp->lock, scheduler locks, perf ctx->lock, locks
> > >> in printk()/WARN_ON() and all locks nested in these locks or chained nested
> > >> in these locks.
> > >>
> > >> The problem is reduced to "how to distinguish all these locks(context)",
> > >> We don't distinguish all these locks, we know that all these locks
> > >> should be nested in local_irqs_disable().
> > >>
> > >> we just consider if rcu_read_unlock_special() is called in irqs-disabled
> > >> context, it may be called in these suspect locks, we should defer
> > >> rcu_read_unlock_special().
> > >>
> > >> The algorithm enlarges the probability of deferring, but the probability
> > >> is still very very low.
> > >>
> > >> Deferring does add a small overhead, but it offers us:
> > >> 	1) really deadlock-immunity for rcu read site
> > >> 	2) remove the overhead of the irq-work(250 times per second in avg.)
> > > 
> > > One problem here -- it may take quite some time for a set_need_resched()
> > > to take effect.  This is especially a problem for RCU priority boosting,
> > > but can also needlessly delay preemptible-RCU grace periods because
> > > local_irq_restore() and friends don't check the TIF_NEED_RESCHED bit.
> > > 
> > > OK, alternatives...
> > > 
> > > o	Keep the current rule saying that if the scheduler is going
> > > 	to exit an RCU read-side critical section while holding
> > > 	one of its spinlocks, preemption has to have been disabled
> > > 	throughout the full duration of that critical section.
> > > 	Well, we can certainly do this, but it would be nice to get
> > > 	rid of this rule.
> > > 
> > > o	Use per-CPU variables, possibly injecting delay.  This has ugly
> > > 	disadvantages as noted above.
> > > 
> > > o	irq_work_queue() can wait a jiffy (or on some architectures,
> > > 	quite a bit longer) before actually doing anything.
> > > 
> > > o	raise_softirq() is more immediate and is an easy change, but
> > > 	adds a softirq vector -- which people are really trying to
> > > 	get rid of.  Also, wakeup_softirqd() calls things that acquire
> > > 	the scheduler locks, which is exactly what we were trying to
> > > 	avoid doing.
> > > 
> > > o	invoke_rcu_core() can invoke raise_softirq() as above.
> > > 
> > > o	IPI to self.  From what I can see, not all architectures
> > > 	support this.  Easy to fake if you have at least two CPUs,
> > > 	but not so good from an OS jitter viewpoint...
> > > 
> > > o	Add a check to local_irq_disable() and friends.  I would guess
> > > 	that this suggestion would not make architecture maintainers
> > > 	happy.
> > > 
> > > Other thoughts?
> > > 
> > > 							Thanx, Paul
> > > 
> > >> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
> > >> ---
> > >>  include/linux/rcupdate.h |    2 +-
> > >>  kernel/rcupdate.c        |    2 +-
> > >>  kernel/rcutree_plugin.h  |   47 +++++++++++++++++++++++++++++++++++++++++----
> > >>  3 files changed, 44 insertions(+), 7 deletions(-)
> > >>
> > >> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> > >> index 4b14bdc..00b4220 100644
> > >> --- a/include/linux/rcupdate.h
> > >> +++ b/include/linux/rcupdate.h
> > >> @@ -180,7 +180,7 @@ extern void synchronize_sched(void);
> > >>
> > >>  extern void __rcu_read_lock(void);
> > >>  extern void __rcu_read_unlock(void);
> > >> -extern void rcu_read_unlock_special(struct task_struct *t);
> > >> +extern void rcu_read_unlock_special(struct task_struct *t, bool unlock);
> > >>  void synchronize_rcu(void);
> > >>
> > >>  /*
> > >> diff --git a/kernel/rcupdate.c b/kernel/rcupdate.c
> > >> index cce6ba8..33b89a3 100644
> > >> --- a/kernel/rcupdate.c
> > >> +++ b/kernel/rcupdate.c
> > >> @@ -90,7 +90,7 @@ void __rcu_read_unlock(void)
> > >>  #endif /* #ifdef CONFIG_PROVE_RCU_DELAY */
> > >>  		barrier();  /* assign before ->rcu_read_unlock_special load */
> > >>  		if (unlikely(ACCESS_ONCE(t->rcu_read_unlock_special)))
> > >> -			rcu_read_unlock_special(t);
> > >> +			rcu_read_unlock_special(t, true);
> > >>  		barrier();  /* ->rcu_read_unlock_special load before assign */
> > >>  		t->rcu_read_lock_nesting = 0;
> > >>  	}
> > >> diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
> > >> index fc8b36f..997b424 100644
> > >> --- a/kernel/rcutree_plugin.h
> > >> +++ b/kernel/rcutree_plugin.h
> > >> @@ -242,15 +242,16 @@ static void rcu_preempt_note_context_switch(int cpu)
> > >>  				       ? rnp->gpnum
> > >>  				       : rnp->gpnum + 1);
> > >>  		raw_spin_unlock_irqrestore(&rnp->lock, flags);
> > >> -	} else if (t->rcu_read_lock_nesting < 0 &&
> > >> -		   !WARN_ON_ONCE(t->rcu_read_lock_nesting != INT_MIN) &&
> > >> -		   t->rcu_read_unlock_special) {
> > >> +	} else if (t->rcu_read_lock_nesting == 0 ||
> > >> +		   (t->rcu_read_lock_nesting < 0 &&
> > >> +		   !WARN_ON_ONCE(t->rcu_read_lock_nesting != INT_MIN))) {
> > >>
> > >>  		/*
> > >>  		 * Complete exit from RCU read-side critical section on
> > >>  		 * behalf of preempted instance of __rcu_read_unlock().
> > >>  		 */
> > >> -		rcu_read_unlock_special(t);
> > >> +		if (t->rcu_read_unlock_special)
> > >> +			rcu_read_unlock_special(t, false);
> > >>  	}
> > >>
> > >>  	/*
> > >> @@ -333,7 +334,7 @@ static struct list_head *rcu_next_node_entry(struct task_struct *t,
> > >>   * notify RCU core processing or task having blocked during the RCU
> > >>   * read-side critical section.
> > >>   */
> > >> -void rcu_read_unlock_special(struct task_struct *t)
> > >> +void rcu_read_unlock_special(struct task_struct *t, bool unlock)
> > >>  {
> > >>  	int empty;
> > >>  	int empty_exp;
> > >> @@ -364,6 +365,42 @@ void rcu_read_unlock_special(struct task_struct *t)
> > >>
> > >>  	/* Clean up if blocked during RCU read-side critical section. */
> > >>  	if (special & RCU_READ_UNLOCK_BLOCKED) {
> > >> +		/*
> > >> +		 * If rcu read lock overlaps with scheduler lock,
> > >> +		 * rcu_read_unlock_special() may lead to deadlock:
> > >> +		 *
> > >> +		 * rcu_read_lock();
> > >> +		 * preempt_schedule[_irq]() (when preemption)
> > >> +		 * scheduler lock; (or some other locks can be (chained) nested
> > >> +		 *                  in rcu_read_unlock_special()/rnp->lock)
> > >> +		 * access and check rcu data
> > >> +		 * rcu_read_unlock();
> > >> +		 *   rcu_read_unlock_special();
> > >> +		 *     wake_up();                 DEAD LOCK
> > >> +		 *
> > >> +		 * To avoid all these kinds of deadlock, we should quit
> > >> +		 * rcu_read_unlock_special() here and defer it to
> > >> +		 * rcu_preempt_note_context_switch() or next outmost
> > >> +		 * rcu_read_unlock() if we consider this case may happen.
> > >> +		 *
> > >> +		 * Although we can't know whether current _special()
> > >> +		 * is nested in scheduler lock or not. But we know that
> > >> +		 * irqs are always disabled in this case. so we just quit
> > >> +		 * and defer it to rcu_preempt_note_context_switch()
> > >> +		 * when irqs are disabled.
> > >> +		 *
> > >> +		 * It means we always defer _special() when it is
> > >> +		 * nested in irqs disabled context, but
> > >> +		 *	(special & RCU_READ_UNLOCK_BLOCKED) &&
> > >> +		 *	irqs_disabled_flags(flags)
> > >> +		 * is still unlikely to be true.
> > >> +		 */
> > >> +		if (unlikely(unlock && irqs_disabled_flags(flags))) {
> > >> +			set_need_resched();
> > >> +			local_irq_restore(flags);
> > >> +			return;
> > >> +		}
> > >> +
> > >>  		t->rcu_read_unlock_special &= ~RCU_READ_UNLOCK_BLOCKED;
> > >>
> > >>  		/*
> > >> -- 
> > >> 1.7.4.4
> > >>
> > > 
> > > 
> > 


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 5/8] rcu: eliminate deadlock for rcu read site
  2013-08-10  3:43     ` Lai Jiangshan
  2013-08-10 15:07       ` Paul E. McKenney
@ 2013-08-12 13:53       ` Peter Zijlstra
  2013-08-12 14:10         ` Steven Rostedt
  1 sibling, 1 reply; 49+ messages in thread
From: Peter Zijlstra @ 2013-08-12 13:53 UTC (permalink / raw)
  To: Lai Jiangshan; +Cc: Steven Rostedt, paulmck, linux-kernel, Dipankar Sarma

On Sat, Aug 10, 2013 at 11:43:59AM +0800, Lai Jiangshan wrote:
> Hi, Steven
> 
> I was considering rtmutex's lock->wait_lock is a scheduler lock,
> But it is not, and it is just a spinlock of process context.
> I hope you change it to a spinlock of irq context.

rwmutex::wait_lock is irq-safe; it had better be because its taken under
task_struct::pi_lock. 

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 5/8] rcu: eliminate deadlock for rcu read site
  2013-08-09  9:31     ` Lai Jiangshan
  2013-08-09 17:58       ` Paul E. McKenney
@ 2013-08-12 13:55       ` Peter Zijlstra
  2013-08-12 15:16         ` Paul E. McKenney
  1 sibling, 1 reply; 49+ messages in thread
From: Peter Zijlstra @ 2013-08-12 13:55 UTC (permalink / raw)
  To: Lai Jiangshan; +Cc: paulmck, Steven Rostedt, linux-kernel, Dipankar Sarma

On Fri, Aug 09, 2013 at 05:31:27PM +0800, Lai Jiangshan wrote:
> On 08/09/2013 04:40 AM, Paul E. McKenney wrote:
> > One problem here -- it may take quite some time for a set_need_resched()
> > to take effect.  This is especially a problem for RCU priority boosting,
> > but can also needlessly delay preemptible-RCU grace periods because
> > local_irq_restore() and friends don't check the TIF_NEED_RESCHED bit.
> 
> 
> The final effect of deboosting(rt_mutex_unlock()) is also accomplished
> via set_need_resched()/set_tsk_need_resched().
> set_need_resched() is enough for RCU priority boosting issue here.

But there's a huge difference between the boosting and deboosting side
of things. rcu_read_unlock_special() starts the boost, the deboosting
only matters if/when you reschedule. 

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 5/8] rcu: eliminate deadlock for rcu read site
  2013-08-12 13:53       ` Peter Zijlstra
@ 2013-08-12 14:10         ` Steven Rostedt
  2013-08-12 14:14           ` Peter Zijlstra
       [not found]           ` <CACvQF51-oAGkdxwku+orKSQ=SZd1A4saXzkrgcRGi+KnZUZYxQ@mail.gmail.com>
  0 siblings, 2 replies; 49+ messages in thread
From: Steven Rostedt @ 2013-08-12 14:10 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Lai Jiangshan, paulmck, linux-kernel, Dipankar Sarma, Thomas Gleixner

On Mon, 12 Aug 2013 15:53:10 +0200
Peter Zijlstra <peterz@infradead.org> wrote:

> On Sat, Aug 10, 2013 at 11:43:59AM +0800, Lai Jiangshan wrote:
> > Hi, Steven
> > 
> > I was considering rtmutex's lock->wait_lock is a scheduler lock,
> > But it is not, and it is just a spinlock of process context.
> > I hope you change it to a spinlock of irq context.
> 
> rwmutex::wait_lock is irq-safe; it had better be because its taken under
> task_struct::pi_lock. 

It is? I thought it was the other way around. That is, pi_lock is taken
under wait_lock.

task_blocks_on_rt_mutex() is called with wait_lock held. The first
thing it does is to grab the pi_lock.

The wait_lock is the mutex internal lock. Currently, no interrupt
context should take that lock, or should there be an interrupt lock
held when it is taken. The lock should be taken in the same contexts
that a mutex can be taken in.

By making it a irq-safe lock, we need to disable interrupts every time
it is taken, which means the entire pi-chain walk in
rt_mutex_adjust_prio_chain() will pretty much be with interrupts
disabled. I really would like to avoid making wait_lock irq-safe if we
can avoid it. I'm sure it will have a large impact to the -rt kernel if
we convert it.


-- Steve

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 5/8] rcu: eliminate deadlock for rcu read site
  2013-08-12 14:10         ` Steven Rostedt
@ 2013-08-12 14:14           ` Peter Zijlstra
       [not found]           ` <CACvQF51-oAGkdxwku+orKSQ=SZd1A4saXzkrgcRGi+KnZUZYxQ@mail.gmail.com>
  1 sibling, 0 replies; 49+ messages in thread
From: Peter Zijlstra @ 2013-08-12 14:14 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Lai Jiangshan, paulmck, linux-kernel, Dipankar Sarma, Thomas Gleixner

On Mon, Aug 12, 2013 at 10:10:08AM -0400, Steven Rostedt wrote:
> On Mon, 12 Aug 2013 15:53:10 +0200
> Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Sat, Aug 10, 2013 at 11:43:59AM +0800, Lai Jiangshan wrote:
> > > Hi, Steven
> > > 
> > > I was considering rtmutex's lock->wait_lock is a scheduler lock,
> > > But it is not, and it is just a spinlock of process context.
> > > I hope you change it to a spinlock of irq context.
> > 
> > rwmutex::wait_lock is irq-safe; it had better be because its taken under
> > task_struct::pi_lock. 
> 
> It is? I thought it was the other way around. That is, pi_lock is taken
> under wait_lock.

Urgh, right you are. 

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 5/8] rcu: eliminate deadlock for rcu read site
  2013-08-12 13:55       ` Peter Zijlstra
@ 2013-08-12 15:16         ` Paul E. McKenney
  2013-08-12 16:21           ` Peter Zijlstra
  0 siblings, 1 reply; 49+ messages in thread
From: Paul E. McKenney @ 2013-08-12 15:16 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Lai Jiangshan, Steven Rostedt, linux-kernel, Dipankar Sarma

On Mon, Aug 12, 2013 at 03:55:44PM +0200, Peter Zijlstra wrote:
> On Fri, Aug 09, 2013 at 05:31:27PM +0800, Lai Jiangshan wrote:
> > On 08/09/2013 04:40 AM, Paul E. McKenney wrote:
> > > One problem here -- it may take quite some time for a set_need_resched()
> > > to take effect.  This is especially a problem for RCU priority boosting,
> > > but can also needlessly delay preemptible-RCU grace periods because
> > > local_irq_restore() and friends don't check the TIF_NEED_RESCHED bit.
> > 
> > 
> > The final effect of deboosting(rt_mutex_unlock()) is also accomplished
> > via set_need_resched()/set_tsk_need_resched().
> > set_need_resched() is enough for RCU priority boosting issue here.
> 
> But there's a huge difference between the boosting and deboosting side
> of things. rcu_read_unlock_special() starts the boost, the deboosting
> only matters if/when you reschedule. 

Or if there is a pre-existing runnable task whose priority is such that
deboosting makes it the highest-priority task.

							Thanx, Paul


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 5/8] rcu: eliminate deadlock for rcu read site
  2013-08-12 15:16         ` Paul E. McKenney
@ 2013-08-12 16:21           ` Peter Zijlstra
  2013-08-12 16:44             ` Paul E. McKenney
  0 siblings, 1 reply; 49+ messages in thread
From: Peter Zijlstra @ 2013-08-12 16:21 UTC (permalink / raw)
  To: Paul E. McKenney
  Cc: Lai Jiangshan, Steven Rostedt, linux-kernel, Dipankar Sarma

On Mon, Aug 12, 2013 at 08:16:18AM -0700, Paul E. McKenney wrote:
> On Mon, Aug 12, 2013 at 03:55:44PM +0200, Peter Zijlstra wrote:
> > On Fri, Aug 09, 2013 at 05:31:27PM +0800, Lai Jiangshan wrote:
> > > On 08/09/2013 04:40 AM, Paul E. McKenney wrote:
> > > > One problem here -- it may take quite some time for a set_need_resched()
> > > > to take effect.  This is especially a problem for RCU priority boosting,
> > > > but can also needlessly delay preemptible-RCU grace periods because
> > > > local_irq_restore() and friends don't check the TIF_NEED_RESCHED bit.
> > > 
> > > 
> > > The final effect of deboosting(rt_mutex_unlock()) is also accomplished
> > > via set_need_resched()/set_tsk_need_resched().
> > > set_need_resched() is enough for RCU priority boosting issue here.
> > 
> > But there's a huge difference between the boosting and deboosting side
> > of things. rcu_read_unlock_special() starts the boost, the deboosting
> > only matters if/when you reschedule. 
> 
> Or if there is a pre-existing runnable task whose priority is such that
> deboosting makes it the highest-priority task.

Right, I got horribly lost in rt_mutex, but I suspect we deal with that
case the right way. -rt people would've noticed us screwing that up ;-)

But there too, we're fully limited to how fast we can get a
reschedule(). Deboosting sooner than we can reschedule to run the other
task is effectively pointless. The converse is obviously not true; we
must not be able to reschedule sooner than we can deboost ;-)

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 5/8] rcu: eliminate deadlock for rcu read site
  2013-08-12 16:21           ` Peter Zijlstra
@ 2013-08-12 16:44             ` Paul E. McKenney
  0 siblings, 0 replies; 49+ messages in thread
From: Paul E. McKenney @ 2013-08-12 16:44 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Lai Jiangshan, Steven Rostedt, linux-kernel, Dipankar Sarma

On Mon, Aug 12, 2013 at 06:21:26PM +0200, Peter Zijlstra wrote:
> On Mon, Aug 12, 2013 at 08:16:18AM -0700, Paul E. McKenney wrote:
> > On Mon, Aug 12, 2013 at 03:55:44PM +0200, Peter Zijlstra wrote:
> > > On Fri, Aug 09, 2013 at 05:31:27PM +0800, Lai Jiangshan wrote:
> > > > On 08/09/2013 04:40 AM, Paul E. McKenney wrote:
> > > > > One problem here -- it may take quite some time for a set_need_resched()
> > > > > to take effect.  This is especially a problem for RCU priority boosting,
> > > > > but can also needlessly delay preemptible-RCU grace periods because
> > > > > local_irq_restore() and friends don't check the TIF_NEED_RESCHED bit.
> > > > 
> > > > 
> > > > The final effect of deboosting(rt_mutex_unlock()) is also accomplished
> > > > via set_need_resched()/set_tsk_need_resched().
> > > > set_need_resched() is enough for RCU priority boosting issue here.
> > > 
> > > But there's a huge difference between the boosting and deboosting side
> > > of things. rcu_read_unlock_special() starts the boost, the deboosting
> > > only matters if/when you reschedule. 
> > 
> > Or if there is a pre-existing runnable task whose priority is such that
> > deboosting makes it the highest-priority task.
> 
> Right, I got horribly lost in rt_mutex, but I suspect we deal with that
> case the right way. -rt people would've noticed us screwing that up ;-)
> 
> But there too, we're fully limited to how fast we can get a
> reschedule(). Deboosting sooner than we can reschedule to run the other
> task is effectively pointless. The converse is obviously not true; we
> must not be able to reschedule sooner than we can deboost ;-)

In addition, the proposed change was to defer the deboost based on
a set_need_resched(), which would provide additional opportunity for
delay -- the running task would retain its high priority until the
scheduler acted on the set_need_resched().

							Thanx, Paul


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 5/8] rcu: eliminate deadlock for rcu read site
  2013-08-10 15:07       ` Paul E. McKenney
  2013-08-10 15:08         ` Paul E. McKenney
@ 2013-08-21  3:17         ` Paul E. McKenney
  2013-08-21  3:25           ` Lai Jiangshan
  1 sibling, 1 reply; 49+ messages in thread
From: Paul E. McKenney @ 2013-08-21  3:17 UTC (permalink / raw)
  To: Lai Jiangshan
  Cc: Steven Rostedt, Peter Zijlstra, linux-kernel, Dipankar Sarma

On Sat, Aug 10, 2013 at 08:07:15AM -0700, Paul E. McKenney wrote:
> On Sat, Aug 10, 2013 at 11:43:59AM +0800, Lai Jiangshan wrote:

[ . . . ]

> > So I have to narrow the range of suspect locks. Two choices:
> > A) don't call rt_mutex_unlock() from rcu_read_unlock(), only call it
> >    from rcu_preempt_not_context_switch(). we need to rework these
> >    two functions and it will add complexity to RCU, and it also still
> >    adds some probability of deferring.
> 
> One advantage of bh-disable locks is that enabling bh checks
> TIF_NEED_RESCHED, so that there is no deferring beyond that
> needed by bh disable.  The same of course applies to preempt_disable().
> 
> So one approach is to defer when rcu_read_unlock_special() is entered
> with either preemption or bh disabled.  Your current set_need_resched()
> trick would work fine in this case.  Unfortunately, re-enabling interrupts
> does -not- check TIF_NEED_RESCHED, which is why we have latency problems
> in that case.  (Hence my earlier question about making self-IPI safe
> on all arches, which would result in an interrupt as soon as interrupts
> were re-enabled.)
> 
> Another possibility is to defer only when preemption or bh are disabled
> on entry ro rcu_read_unlock_special(), but to retain the current
> (admittedly ugly) nesting rules for the scheduler locks.

Would you be willing to do a patch that deferred rt_mutex_unlock() in
the preempt/bh cases?  This of course does not solve the irq-disable
case, but it should at least narrow the problem to the scheduler locks.

Not a big hurry, given the testing required, this is 3.13 or 3.14 material,
I think.

If you are busy, no problem, I can do it, just figured you have priority
if you want it.

							Thanx, Paul

> > B) change rtmutex's lock->wait_lock to irqs-disabled.
> 
> I have to defer to Steven on this one.
> 
> 							Thanx, Paul
> 
> > 4) In the view of rtmutex, I think it will be better if ->wait_lock is irqs-disabled.
> >    A) like trylock of mutex/rw_sem, we may call rt_mutex_trylock() in irq in future.
> >    B) the critical section of ->wait_lock is short,
> >       making it irqs-disabled don't hurts responsibility/latency.
> >    C) almost all time of the critical section of ->wait_lock is irqs-disabled
> >       (due to task->pi_lock), I think converting whole time of the critical section
> >       of ->wait_lock to irqs-disabled is OK.
> > 
> > So I hope you change rtmutex's lock->wait_lock.
> > 
> > Any feedback from anyone is welcome.
> > 
> > Thanks,
> > Lai
> > 
> > On 08/09/2013 04:40 AM, Paul E. McKenney wrote:
> > > On Wed, Aug 07, 2013 at 06:25:01PM +0800, Lai Jiangshan wrote:
> > >> Background)
> > >>
> > >> Although all articles declare that rcu read site is deadlock-immunity.
> > >> It is not true for rcu-preempt, it will be deadlock if rcu read site
> > >> overlaps with scheduler lock.
> > >>
> > >> ec433f0c, 10f39bb1 and 016a8d5b just partially solve it. But rcu read site
> > >> is still not deadlock-immunity. And the problem described in 016a8d5b
> > >> is still existed(rcu_read_unlock_special() calls wake_up).
> > >>
> > >> Aim)
> > >>
> > >> We want to fix the problem forever, we want to keep rcu read site
> > >> is deadlock-immunity as books say.
> > >>
> > >> How)
> > >>
> > >> The problem is solved by "if rcu_read_unlock_special() is called inside
> > >> any lock which can be (chained) nested in rcu_read_unlock_special(),
> > >> we defer rcu_read_unlock_special()".
> > >> This kind locks include rnp->lock, scheduler locks, perf ctx->lock, locks
> > >> in printk()/WARN_ON() and all locks nested in these locks or chained nested
> > >> in these locks.
> > >>
> > >> The problem is reduced to "how to distinguish all these locks(context)",
> > >> We don't distinguish all these locks, we know that all these locks
> > >> should be nested in local_irqs_disable().
> > >>
> > >> we just consider if rcu_read_unlock_special() is called in irqs-disabled
> > >> context, it may be called in these suspect locks, we should defer
> > >> rcu_read_unlock_special().
> > >>
> > >> The algorithm enlarges the probability of deferring, but the probability
> > >> is still very very low.
> > >>
> > >> Deferring does add a small overhead, but it offers us:
> > >> 	1) really deadlock-immunity for rcu read site
> > >> 	2) remove the overhead of the irq-work(250 times per second in avg.)
> > > 
> > > One problem here -- it may take quite some time for a set_need_resched()
> > > to take effect.  This is especially a problem for RCU priority boosting,
> > > but can also needlessly delay preemptible-RCU grace periods because
> > > local_irq_restore() and friends don't check the TIF_NEED_RESCHED bit.
> > > 
> > > OK, alternatives...
> > > 
> > > o	Keep the current rule saying that if the scheduler is going
> > > 	to exit an RCU read-side critical section while holding
> > > 	one of its spinlocks, preemption has to have been disabled
> > > 	throughout the full duration of that critical section.
> > > 	Well, we can certainly do this, but it would be nice to get
> > > 	rid of this rule.
> > > 
> > > o	Use per-CPU variables, possibly injecting delay.  This has ugly
> > > 	disadvantages as noted above.
> > > 
> > > o	irq_work_queue() can wait a jiffy (or on some architectures,
> > > 	quite a bit longer) before actually doing anything.
> > > 
> > > o	raise_softirq() is more immediate and is an easy change, but
> > > 	adds a softirq vector -- which people are really trying to
> > > 	get rid of.  Also, wakeup_softirqd() calls things that acquire
> > > 	the scheduler locks, which is exactly what we were trying to
> > > 	avoid doing.
> > > 
> > > o	invoke_rcu_core() can invoke raise_softirq() as above.
> > > 
> > > o	IPI to self.  From what I can see, not all architectures
> > > 	support this.  Easy to fake if you have at least two CPUs,
> > > 	but not so good from an OS jitter viewpoint...
> > > 
> > > o	Add a check to local_irq_disable() and friends.  I would guess
> > > 	that this suggestion would not make architecture maintainers
> > > 	happy.
> > > 
> > > Other thoughts?
> > > 
> > > 							Thanx, Paul
> > > 
> > >> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
> > >> ---
> > >>  include/linux/rcupdate.h |    2 +-
> > >>  kernel/rcupdate.c        |    2 +-
> > >>  kernel/rcutree_plugin.h  |   47 +++++++++++++++++++++++++++++++++++++++++----
> > >>  3 files changed, 44 insertions(+), 7 deletions(-)
> > >>
> > >> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> > >> index 4b14bdc..00b4220 100644
> > >> --- a/include/linux/rcupdate.h
> > >> +++ b/include/linux/rcupdate.h
> > >> @@ -180,7 +180,7 @@ extern void synchronize_sched(void);
> > >>
> > >>  extern void __rcu_read_lock(void);
> > >>  extern void __rcu_read_unlock(void);
> > >> -extern void rcu_read_unlock_special(struct task_struct *t);
> > >> +extern void rcu_read_unlock_special(struct task_struct *t, bool unlock);
> > >>  void synchronize_rcu(void);
> > >>
> > >>  /*
> > >> diff --git a/kernel/rcupdate.c b/kernel/rcupdate.c
> > >> index cce6ba8..33b89a3 100644
> > >> --- a/kernel/rcupdate.c
> > >> +++ b/kernel/rcupdate.c
> > >> @@ -90,7 +90,7 @@ void __rcu_read_unlock(void)
> > >>  #endif /* #ifdef CONFIG_PROVE_RCU_DELAY */
> > >>  		barrier();  /* assign before ->rcu_read_unlock_special load */
> > >>  		if (unlikely(ACCESS_ONCE(t->rcu_read_unlock_special)))
> > >> -			rcu_read_unlock_special(t);
> > >> +			rcu_read_unlock_special(t, true);
> > >>  		barrier();  /* ->rcu_read_unlock_special load before assign */
> > >>  		t->rcu_read_lock_nesting = 0;
> > >>  	}
> > >> diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
> > >> index fc8b36f..997b424 100644
> > >> --- a/kernel/rcutree_plugin.h
> > >> +++ b/kernel/rcutree_plugin.h
> > >> @@ -242,15 +242,16 @@ static void rcu_preempt_note_context_switch(int cpu)
> > >>  				       ? rnp->gpnum
> > >>  				       : rnp->gpnum + 1);
> > >>  		raw_spin_unlock_irqrestore(&rnp->lock, flags);
> > >> -	} else if (t->rcu_read_lock_nesting < 0 &&
> > >> -		   !WARN_ON_ONCE(t->rcu_read_lock_nesting != INT_MIN) &&
> > >> -		   t->rcu_read_unlock_special) {
> > >> +	} else if (t->rcu_read_lock_nesting == 0 ||
> > >> +		   (t->rcu_read_lock_nesting < 0 &&
> > >> +		   !WARN_ON_ONCE(t->rcu_read_lock_nesting != INT_MIN))) {
> > >>
> > >>  		/*
> > >>  		 * Complete exit from RCU read-side critical section on
> > >>  		 * behalf of preempted instance of __rcu_read_unlock().
> > >>  		 */
> > >> -		rcu_read_unlock_special(t);
> > >> +		if (t->rcu_read_unlock_special)
> > >> +			rcu_read_unlock_special(t, false);
> > >>  	}
> > >>
> > >>  	/*
> > >> @@ -333,7 +334,7 @@ static struct list_head *rcu_next_node_entry(struct task_struct *t,
> > >>   * notify RCU core processing or task having blocked during the RCU
> > >>   * read-side critical section.
> > >>   */
> > >> -void rcu_read_unlock_special(struct task_struct *t)
> > >> +void rcu_read_unlock_special(struct task_struct *t, bool unlock)
> > >>  {
> > >>  	int empty;
> > >>  	int empty_exp;
> > >> @@ -364,6 +365,42 @@ void rcu_read_unlock_special(struct task_struct *t)
> > >>
> > >>  	/* Clean up if blocked during RCU read-side critical section. */
> > >>  	if (special & RCU_READ_UNLOCK_BLOCKED) {
> > >> +		/*
> > >> +		 * If rcu read lock overlaps with scheduler lock,
> > >> +		 * rcu_read_unlock_special() may lead to deadlock:
> > >> +		 *
> > >> +		 * rcu_read_lock();
> > >> +		 * preempt_schedule[_irq]() (when preemption)
> > >> +		 * scheduler lock; (or some other locks can be (chained) nested
> > >> +		 *                  in rcu_read_unlock_special()/rnp->lock)
> > >> +		 * access and check rcu data
> > >> +		 * rcu_read_unlock();
> > >> +		 *   rcu_read_unlock_special();
> > >> +		 *     wake_up();                 DEAD LOCK
> > >> +		 *
> > >> +		 * To avoid all these kinds of deadlock, we should quit
> > >> +		 * rcu_read_unlock_special() here and defer it to
> > >> +		 * rcu_preempt_note_context_switch() or next outmost
> > >> +		 * rcu_read_unlock() if we consider this case may happen.
> > >> +		 *
> > >> +		 * Although we can't know whether current _special()
> > >> +		 * is nested in scheduler lock or not. But we know that
> > >> +		 * irqs are always disabled in this case. so we just quit
> > >> +		 * and defer it to rcu_preempt_note_context_switch()
> > >> +		 * when irqs are disabled.
> > >> +		 *
> > >> +		 * It means we always defer _special() when it is
> > >> +		 * nested in irqs disabled context, but
> > >> +		 *	(special & RCU_READ_UNLOCK_BLOCKED) &&
> > >> +		 *	irqs_disabled_flags(flags)
> > >> +		 * is still unlikely to be true.
> > >> +		 */
> > >> +		if (unlikely(unlock && irqs_disabled_flags(flags))) {
> > >> +			set_need_resched();
> > >> +			local_irq_restore(flags);
> > >> +			return;
> > >> +		}
> > >> +
> > >>  		t->rcu_read_unlock_special &= ~RCU_READ_UNLOCK_BLOCKED;
> > >>
> > >>  		/*
> > >> -- 
> > >> 1.7.4.4
> > >>
> > > 
> > > 
> > 


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 5/8] rcu: eliminate deadlock for rcu read site
  2013-08-21  3:17         ` Paul E. McKenney
@ 2013-08-21  3:25           ` Lai Jiangshan
  2013-08-21 13:42             ` Paul E. McKenney
  0 siblings, 1 reply; 49+ messages in thread
From: Lai Jiangshan @ 2013-08-21  3:25 UTC (permalink / raw)
  To: paulmck; +Cc: Steven Rostedt, Peter Zijlstra, linux-kernel, Dipankar Sarma

On 08/21/2013 11:17 AM, Paul E. McKenney wrote:
> On Sat, Aug 10, 2013 at 08:07:15AM -0700, Paul E. McKenney wrote:
>> On Sat, Aug 10, 2013 at 11:43:59AM +0800, Lai Jiangshan wrote:
> 
> [ . . . ]
> 
>>> So I have to narrow the range of suspect locks. Two choices:
>>> A) don't call rt_mutex_unlock() from rcu_read_unlock(), only call it
>>>    from rcu_preempt_not_context_switch(). we need to rework these
>>>    two functions and it will add complexity to RCU, and it also still
>>>    adds some probability of deferring.
>>
>> One advantage of bh-disable locks is that enabling bh checks
>> TIF_NEED_RESCHED, so that there is no deferring beyond that
>> needed by bh disable.  The same of course applies to preempt_disable().
>>
>> So one approach is to defer when rcu_read_unlock_special() is entered
>> with either preemption or bh disabled.  Your current set_need_resched()
>> trick would work fine in this case.  Unfortunately, re-enabling interrupts
>> does -not- check TIF_NEED_RESCHED, which is why we have latency problems
>> in that case.  (Hence my earlier question about making self-IPI safe
>> on all arches, which would result in an interrupt as soon as interrupts
>> were re-enabled.)
>>
>> Another possibility is to defer only when preemption or bh are disabled
>> on entry ro rcu_read_unlock_special(), but to retain the current
>> (admittedly ugly) nesting rules for the scheduler locks.
> 
> Would you be willing to do a patch that deferred rt_mutex_unlock() in
> the preempt/bh cases?  This of course does not solve the irq-disable
> case, but it should at least narrow the problem to the scheduler locks.
> 
> Not a big hurry, given the testing required, this is 3.13 or 3.14 material,
> I think.
> 
> If you are busy, no problem, I can do it, just figured you have priority
> if you want it.
> 
> 	


I'm writing a special rt_mutex_unlock() for rcu deboost only.
I hope Steven accept it.

Thanks,
Lai

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 5/8] rcu: eliminate deadlock for rcu read site
  2013-08-21  3:25           ` Lai Jiangshan
@ 2013-08-21 13:42             ` Paul E. McKenney
  0 siblings, 0 replies; 49+ messages in thread
From: Paul E. McKenney @ 2013-08-21 13:42 UTC (permalink / raw)
  To: Lai Jiangshan
  Cc: Steven Rostedt, Peter Zijlstra, linux-kernel, Dipankar Sarma

On Wed, Aug 21, 2013 at 11:25:55AM +0800, Lai Jiangshan wrote:
> On 08/21/2013 11:17 AM, Paul E. McKenney wrote:
> > On Sat, Aug 10, 2013 at 08:07:15AM -0700, Paul E. McKenney wrote:
> >> On Sat, Aug 10, 2013 at 11:43:59AM +0800, Lai Jiangshan wrote:
> > 
> > [ . . . ]
> > 
> >>> So I have to narrow the range of suspect locks. Two choices:
> >>> A) don't call rt_mutex_unlock() from rcu_read_unlock(), only call it
> >>>    from rcu_preempt_not_context_switch(). we need to rework these
> >>>    two functions and it will add complexity to RCU, and it also still
> >>>    adds some probability of deferring.
> >>
> >> One advantage of bh-disable locks is that enabling bh checks
> >> TIF_NEED_RESCHED, so that there is no deferring beyond that
> >> needed by bh disable.  The same of course applies to preempt_disable().
> >>
> >> So one approach is to defer when rcu_read_unlock_special() is entered
> >> with either preemption or bh disabled.  Your current set_need_resched()
> >> trick would work fine in this case.  Unfortunately, re-enabling interrupts
> >> does -not- check TIF_NEED_RESCHED, which is why we have latency problems
> >> in that case.  (Hence my earlier question about making self-IPI safe
> >> on all arches, which would result in an interrupt as soon as interrupts
> >> were re-enabled.)
> >>
> >> Another possibility is to defer only when preemption or bh are disabled
> >> on entry ro rcu_read_unlock_special(), but to retain the current
> >> (admittedly ugly) nesting rules for the scheduler locks.
> > 
> > Would you be willing to do a patch that deferred rt_mutex_unlock() in
> > the preempt/bh cases?  This of course does not solve the irq-disable
> > case, but it should at least narrow the problem to the scheduler locks.
> > 
> > Not a big hurry, given the testing required, this is 3.13 or 3.14 material,
> > I think.
> > 
> > If you are busy, no problem, I can do it, just figured you have priority
> > if you want it.
> 
> I'm writing a special rt_mutex_unlock() for rcu deboost only.
> I hope Steven accept it.

That would be very cool, though if I understand the requirements,
especially for -rt, very challenging.  Looking forward to seeing it!

							Thanx, Paul


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 5/8] rcu: eliminate deadlock for rcu read site
       [not found]           ` <CACvQF51-oAGkdxwku+orKSQ=SZd1A4saXzkrgcRGi+KnZUZYxQ@mail.gmail.com>
@ 2013-08-22 14:34             ` Steven Rostedt
  2013-08-22 14:41               ` Steven Rostedt
  2013-08-23  6:26               ` Lai Jiangshan
  0 siblings, 2 replies; 49+ messages in thread
From: Steven Rostedt @ 2013-08-22 14:34 UTC (permalink / raw)
  To: Lai Jiangshan
  Cc: Peter Zijlstra, Paul McKenney, LKML, Dipankar Sarma, Thomas Gleixner

On Thu, 22 Aug 2013 22:23:09 +0800
Lai Jiangshan <eag0628@gmail.com> wrote:


> > By making it a irq-safe lock, we need to disable interrupts every time
> > it is taken, which means the entire pi-chain walk in
> > rt_mutex_adjust_prio_chain() will pretty much be with interrupts
> > disabled.
> 
> 
> I didn't catch your meaning.
> rt_mutex_adjust_prio_chain() is called without wait_lock held.
> current C.S. of wait_lock are really short.
> 

There is quite a bit of overhead to enable and disable interrupts. If
we are doing this in a very fast path, it's going to slow down -rt even
more.

It would be really nice to avoid making wait_lock be irq safe.

-- Steve

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 5/8] rcu: eliminate deadlock for rcu read site
  2013-08-22 14:34             ` Steven Rostedt
@ 2013-08-22 14:41               ` Steven Rostedt
  2013-08-23  6:26               ` Lai Jiangshan
  1 sibling, 0 replies; 49+ messages in thread
From: Steven Rostedt @ 2013-08-22 14:41 UTC (permalink / raw)
  To: Lai Jiangshan
  Cc: Peter Zijlstra, Paul McKenney, LKML, Dipankar Sarma, Thomas Gleixner

On Thu, 22 Aug 2013 10:34:31 -0400
Steven Rostedt <rostedt@goodmis.org> wrote:

> On Thu, 22 Aug 2013 22:23:09 +0800
> Lai Jiangshan <eag0628@gmail.com> wrote:
> 
> 
> > > By making it a irq-safe lock, we need to disable interrupts every time
> > > it is taken, which means the entire pi-chain walk in
> > > rt_mutex_adjust_prio_chain() will pretty much be with interrupts
> > > disabled.
> > 
> > 
> > I didn't catch your meaning.
> > rt_mutex_adjust_prio_chain() is called without wait_lock held.
> > current C.S. of wait_lock are really short.
> > 
> 
> There is quite a bit of overhead to enable and disable interrupts. If
> we are doing this in a very fast path, it's going to slow down -rt even
> more.

Looking at the rt_mutex_adjust_prio_chain(), it's not that bad because
the pi_lock needs irqs disabled too, and we would just extend that
section.

But it still extends irqs off.

But in -rt, it is used in the rt_spin_lock_slowlock() where it can exit
out of the code without ever having to disable interrupts.

> 
> It would be really nice to avoid making wait_lock be irq safe.

I still would like to exhaust other options before just making
wait_lock irq safe.

-- Steve

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 5/8] rcu: eliminate deadlock for rcu read site
  2013-08-22 14:34             ` Steven Rostedt
  2013-08-22 14:41               ` Steven Rostedt
@ 2013-08-23  6:26               ` Lai Jiangshan
       [not found]                 ` <CACvQF51kcLrJsa=zBKhLkJfFBh109TW+Zrepm+tRxmEp0gALbQ@mail.gmail.com>
  2013-09-05 15:22                 ` Steven Rostedt
  1 sibling, 2 replies; 49+ messages in thread
From: Lai Jiangshan @ 2013-08-23  6:26 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Lai Jiangshan, Peter Zijlstra, Paul McKenney, LKML,
	Dipankar Sarma, Thomas Gleixner

[PATCH] rcu/rt_mutex: eliminate a kind of deadlock for rcu read site

Current rtmutex's lock->wait_lock doesn't disables softirq nor irq, it will
cause rcu read site deadlock when rcu overlaps with any softirq-context/irq-context lock.

@L is a spinlock of softirq or irq context.

CPU1					cpu2(rcu boost)
rcu_read_lock()				rt_mutext_lock()
<preemption and reschedule back>	  raw_spin_lock(lock->wait_lock)
spin_lock_XX(L)				  <interrupt and doing softirq or irq>
rcu_read_unlock()                         do_softirq()
  rcu_read_unlock_special()
    rt_mutext_unlock()
      raw_spin_lock(lock->wait_lock)	    spin_lock_XX(L)  **DEADLOCK**

This patch fixes this kind of deadlock by removing rt_mutext_unlock() from
rcu_read_unlock(), new rt_mutex_rcu_deboost_unlock() is called instead.
Thus rtmutex's lock->wait_lock will not be called from rcu_read_unlock().

This patch does not eliminate all kinds of rcu-read-site deadlock,
if @L is a scheduler lock, it will be deadlock, we should apply Paul's rule
in this case.(avoid overlapping or preempt_disable()).

rt_mutex_rcu_deboost_unlock() requires the @waiter is queued, so we
can't directly call rt_mutex_lock(&mtx) in the rcu_boost thread,
we split rt_mutex_lock(&mtx) into two steps just like pi-futex.
This result a internal state in rcu_boost thread and cause
rcu_boost thread a bit more complicated.

Thanks
Lai

diff --git a/include/linux/init_task.h b/include/linux/init_task.h
index 5cd0f09..8830874 100644
--- a/include/linux/init_task.h
+++ b/include/linux/init_task.h
@@ -102,7 +102,7 @@ extern struct group_info init_groups;
 
 #ifdef CONFIG_RCU_BOOST
 #define INIT_TASK_RCU_BOOST()						\
-	.rcu_boost_mutex = NULL,
+	.rcu_boost_waiter = NULL,
 #else
 #define INIT_TASK_RCU_BOOST()
 #endif
diff --git a/include/linux/sched.h b/include/linux/sched.h
index e9995eb..1eca99f 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1078,7 +1078,7 @@ struct task_struct {
 	struct rcu_node *rcu_blocked_node;
 #endif /* #ifdef CONFIG_TREE_PREEMPT_RCU */
 #ifdef CONFIG_RCU_BOOST
-	struct rt_mutex *rcu_boost_mutex;
+	struct rt_mutex_waiter *rcu_boost_waiter;
 #endif /* #ifdef CONFIG_RCU_BOOST */
 
 #if defined(CONFIG_SCHEDSTATS) || defined(CONFIG_TASK_DELAY_ACCT)
@@ -1723,7 +1723,7 @@ static inline void rcu_copy_process(struct task_struct *p)
 	p->rcu_blocked_node = NULL;
 #endif /* #ifdef CONFIG_TREE_PREEMPT_RCU */
 #ifdef CONFIG_RCU_BOOST
-	p->rcu_boost_mutex = NULL;
+	p->rcu_boost_waiter = NULL;
 #endif /* #ifdef CONFIG_RCU_BOOST */
 	INIT_LIST_HEAD(&p->rcu_node_entry);
 }
diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
index 769e12e..d207ddd 100644
--- a/kernel/rcutree_plugin.h
+++ b/kernel/rcutree_plugin.h
@@ -33,6 +33,7 @@
 #define RCU_KTHREAD_PRIO 1
 
 #ifdef CONFIG_RCU_BOOST
+#include "rtmutex_common.h"
 #define RCU_BOOST_PRIO CONFIG_RCU_BOOST_PRIO
 #else
 #define RCU_BOOST_PRIO RCU_KTHREAD_PRIO
@@ -340,7 +341,7 @@ void rcu_read_unlock_special(struct task_struct *t)
 	unsigned long flags;
 	struct list_head *np;
 #ifdef CONFIG_RCU_BOOST
-	struct rt_mutex *rbmp = NULL;
+	struct rt_mutex_waiter *waiter = NULL;
 #endif /* #ifdef CONFIG_RCU_BOOST */
 	struct rcu_node *rnp;
 	int special;
@@ -397,10 +398,10 @@ void rcu_read_unlock_special(struct task_struct *t)
 #ifdef CONFIG_RCU_BOOST
 		if (&t->rcu_node_entry == rnp->boost_tasks)
 			rnp->boost_tasks = np;
-		/* Snapshot/clear ->rcu_boost_mutex with rcu_node lock held. */
-		if (t->rcu_boost_mutex) {
-			rbmp = t->rcu_boost_mutex;
-			t->rcu_boost_mutex = NULL;
+		/* Snapshot/clear ->rcu_boost_waiter with rcu_node lock held. */
+		if (t->rcu_boost_waiter) {
+			waiter = t->rcu_boost_waiter;
+			t->rcu_boost_waiter = NULL;
 		}
 #endif /* #ifdef CONFIG_RCU_BOOST */
 
@@ -426,8 +427,8 @@ void rcu_read_unlock_special(struct task_struct *t)
 
 #ifdef CONFIG_RCU_BOOST
 		/* Unboost if we were boosted. */
-		if (rbmp)
-			rt_mutex_unlock(rbmp);
+		if (waiter)
+			rt_mutex_rcu_deboost_unlock(t, waiter);
 #endif /* #ifdef CONFIG_RCU_BOOST */
 
 		/*
@@ -1129,9 +1130,6 @@ void exit_rcu(void)
 #endif /* #else #ifdef CONFIG_TREE_PREEMPT_RCU */
 
 #ifdef CONFIG_RCU_BOOST
-
-#include "rtmutex_common.h"
-
 #ifdef CONFIG_RCU_TRACE
 
 static void rcu_initiate_boost_trace(struct rcu_node *rnp)
@@ -1181,14 +1179,15 @@ static int rcu_boost(struct rcu_node *rnp)
 {
 	unsigned long flags;
 	struct rt_mutex mtx;
+	struct rt_mutex_waiter rcu_boost_waiter;
 	struct task_struct *t;
 	struct list_head *tb;
+	int ret;
 
 	if (rnp->exp_tasks == NULL && rnp->boost_tasks == NULL)
 		return 0;  /* Nothing left to boost. */
 
 	raw_spin_lock_irqsave(&rnp->lock, flags);
-
 	/*
 	 * Recheck under the lock: all tasks in need of boosting
 	 * might exit their RCU read-side critical sections on their own.
@@ -1215,7 +1214,7 @@ static int rcu_boost(struct rcu_node *rnp)
 
 	/*
 	 * We boost task t by manufacturing an rt_mutex that appears to
-	 * be held by task t.  We leave a pointer to that rt_mutex where
+	 * be held by task t.  We leave a pointer to that rt_mutex_waiter where
 	 * task t can find it, and task t will release the mutex when it
 	 * exits its outermost RCU read-side critical section.  Then
 	 * simply acquiring this artificial rt_mutex will boost task
@@ -1230,11 +1229,30 @@ static int rcu_boost(struct rcu_node *rnp)
 	 * section.
 	 */
 	t = container_of(tb, struct task_struct, rcu_node_entry);
+	get_task_struct(t);
 	rt_mutex_init_proxy_locked(&mtx, t);
-	t->rcu_boost_mutex = &mtx;
 	raw_spin_unlock_irqrestore(&rnp->lock, flags);
-	rt_mutex_lock(&mtx);  /* Side effect: boosts task t's priority. */
-	rt_mutex_unlock(&mtx);  /* Keep lockdep happy. */
+
+	debug_rt_mutex_init_waiter(&rcu_boost_waiter);
+	/* Side effect: boosts task t's priority. */
+	ret = rt_mutex_start_proxy_lock(&mtx, &rcu_boost_waiter, current, 0);
+	if (WARN_ON_ONCE(ret)) {
+		put_task_struct(t);
+		return 0; /* temporary stop boosting */
+	}
+
+	raw_spin_lock_irqsave(&rnp->lock, flags);
+	if (&t->rcu_node_entry == rnp->exp_tasks ||
+	    &t->rcu_node_entry == rnp->boost_tasks) {
+		t->rcu_boost_waiter = &rcu_boost_waiter;
+		raw_spin_unlock_irqrestore(&rnp->lock, flags);
+	} else {
+		raw_spin_unlock_irqrestore(&rnp->lock, flags);
+		rt_mutex_rcu_deboost_unlock(t, &rcu_boost_waiter);
+	}
+
+	put_task_struct(t);
+	rt_mutex_finish_proxy_lock(&mtx, NULL, &rcu_boost_waiter, 0);
 
 	return ACCESS_ONCE(rnp->exp_tasks) != NULL ||
 	       ACCESS_ONCE(rnp->boost_tasks) != NULL;
diff --git a/kernel/rtmutex.c b/kernel/rtmutex.c
index 0dd6aec..2f3caee 100644
--- a/kernel/rtmutex.c
+++ b/kernel/rtmutex.c
@@ -734,6 +734,43 @@ rt_mutex_slowunlock(struct rt_mutex *lock)
 	rt_mutex_adjust_prio(current);
 }
 
+#ifdef CONFIG_RCU_BOOST
+/*
+ * rt_mutex_rcu_deboost_unlock() - unlock in irq/bh/process context
+ *
+ * please revert the patch which introduces this function when
+ * rt_mutex's ->wait_lock is irq-off.
+ */
+void rt_mutex_rcu_deboost_unlock(struct task_struct *owner,
+				 struct rt_mutex_waiter *waiter)
+{
+	unsigned long flags;
+	struct rt_mutex *lock = waiter->lock;
+
+	/*
+	 * The correction of the following code is based on
+	 * 1) current lock is owned by @owner
+	 * 2) only one task(@waiter->task) is waiting on the @lock
+	 * 3) the @waiter has been queued and keeps been queued
+	 */
+	if (WARN_ON_ONCE(rt_mutex_owner(lock) != owner))
+		return; /* 1) */
+	if (WARN_ON_ONCE(rt_mutex_top_waiter(lock) != waiter))
+		return; /* 2) & 3) */
+	if (WARN_ON_ONCE(plist_node_empty(&waiter->pi_list_entry)))
+		return; /* 2) & 3) */
+
+	raw_spin_lock_irqsave(&owner->pi_lock, flags);
+	plist_del(&waiter->pi_list_entry, &owner->pi_waiters);
+	lock->owner = NULL;
+	raw_spin_unlock_irqrestore(&owner->pi_lock, flags);
+
+	wake_up_process(waiter->task);
+	/* Undo pi boosting if necessary: */
+	rt_mutex_adjust_prio(owner);
+}
+#endif /* #ifdef CONFIG_RCU_BOOST */
+
 /*
  * debug aware fast / slowpath lock,trylock,unlock
  *
diff --git a/kernel/rtmutex_common.h b/kernel/rtmutex_common.h
index 53a66c8..3cdbe82 100644
--- a/kernel/rtmutex_common.h
+++ b/kernel/rtmutex_common.h
@@ -117,6 +117,11 @@ extern int rt_mutex_finish_proxy_lock(struct rt_mutex *lock,
 				      struct rt_mutex_waiter *waiter,
 				      int detect_deadlock);
 
+#ifdef CONFIG_RCU_BOOST
+void rt_mutex_rcu_deboost_unlock(struct task_struct *owner,
+				 struct rt_mutex_waiter *waiter);
+#endif /* #ifdef CONFIG_RCU_BOOST */
+
 #ifdef CONFIG_DEBUG_RT_MUTEXES
 # include "rtmutex-debug.h"
 #else

^ permalink raw reply related	[flat|nested] 49+ messages in thread

* Re: [PATCH 5/8] rcu: eliminate deadlock for rcu read site
       [not found]                 ` <CACvQF51kcLrJsa=zBKhLkJfFBh109TW+Zrepm+tRxmEp0gALbQ@mail.gmail.com>
@ 2013-08-25 17:43                   ` Paul E. McKenney
  2013-08-26  2:39                     ` Lai Jiangshan
  0 siblings, 1 reply; 49+ messages in thread
From: Paul E. McKenney @ 2013-08-25 17:43 UTC (permalink / raw)
  To: Lai Jiangshan
  Cc: Steven Rostedt, Peter Zijlstra, LKML, Dipankar Sarma, Thomas Gleixner

On Sun, Aug 25, 2013 at 11:19:37PM +0800, Lai Jiangshan wrote:
> Hi, Steven
> 
> Any comments about this patch?

For whatever it is worth, it ran without incident for two hours worth
of rcutorture on my P5 test (boosting but no CPU hotplug).

Lai, do you have a specific test for this patch?  Your deadlock
scenario looks plausible, but is apparently not occurring in the
mainline kernel.

							Thanx, Paul

> Thanks,
> Lai
> 
> 
> On Fri, Aug 23, 2013 at 2:26 PM, Lai Jiangshan <laijs@cn.fujitsu.com> wrote:
> 
> > [PATCH] rcu/rt_mutex: eliminate a kind of deadlock for rcu read site
> >
> > Current rtmutex's lock->wait_lock doesn't disables softirq nor irq, it will
> > cause rcu read site deadlock when rcu overlaps with any
> > softirq-context/irq-context lock.
> >
> > @L is a spinlock of softirq or irq context.
> >
> > CPU1                                    cpu2(rcu boost)
> > rcu_read_lock()                         rt_mutext_lock()
> > <preemption and reschedule back>          raw_spin_lock(lock->wait_lock)
> > spin_lock_XX(L)                           <interrupt and doing softirq or
> > irq>
> > rcu_read_unlock()                         do_softirq()
> >   rcu_read_unlock_special()
> >     rt_mutext_unlock()
> >       raw_spin_lock(lock->wait_lock)        spin_lock_XX(L)  **DEADLOCK**
> >
> > This patch fixes this kind of deadlock by removing rt_mutext_unlock() from
> > rcu_read_unlock(), new rt_mutex_rcu_deboost_unlock() is called instead.
> > Thus rtmutex's lock->wait_lock will not be called from rcu_read_unlock().
> >
> > This patch does not eliminate all kinds of rcu-read-site deadlock,
> > if @L is a scheduler lock, it will be deadlock, we should apply Paul's rule
> > in this case.(avoid overlapping or preempt_disable()).
> >
> > rt_mutex_rcu_deboost_unlock() requires the @waiter is queued, so we
> > can't directly call rt_mutex_lock(&mtx) in the rcu_boost thread,
> > we split rt_mutex_lock(&mtx) into two steps just like pi-futex.
> > This result a internal state in rcu_boost thread and cause
> > rcu_boost thread a bit more complicated.
> >
> > Thanks
> > Lai
> >
> > diff --git a/include/linux/init_task.h b/include/linux/init_task.h
> > index 5cd0f09..8830874 100644
> > --- a/include/linux/init_task.h
> > +++ b/include/linux/init_task.h
> > @@ -102,7 +102,7 @@ extern struct group_info init_groups;
> >
> >  #ifdef CONFIG_RCU_BOOST
> >  #define INIT_TASK_RCU_BOOST()                                          \
> > -       .rcu_boost_mutex = NULL,
> > +       .rcu_boost_waiter = NULL,
> >  #else
> >  #define INIT_TASK_RCU_BOOST()
> >  #endif
> > diff --git a/include/linux/sched.h b/include/linux/sched.h
> > index e9995eb..1eca99f 100644
> > --- a/include/linux/sched.h
> > +++ b/include/linux/sched.h
> > @@ -1078,7 +1078,7 @@ struct task_struct {
> >         struct rcu_node *rcu_blocked_node;
> >  #endif /* #ifdef CONFIG_TREE_PREEMPT_RCU */
> >  #ifdef CONFIG_RCU_BOOST
> > -       struct rt_mutex *rcu_boost_mutex;
> > +       struct rt_mutex_waiter *rcu_boost_waiter;
> >  #endif /* #ifdef CONFIG_RCU_BOOST */
> >
> >  #if defined(CONFIG_SCHEDSTATS) || defined(CONFIG_TASK_DELAY_ACCT)
> > @@ -1723,7 +1723,7 @@ static inline void rcu_copy_process(struct
> > task_struct *p)
> >         p->rcu_blocked_node = NULL;
> >  #endif /* #ifdef CONFIG_TREE_PREEMPT_RCU */
> >  #ifdef CONFIG_RCU_BOOST
> > -       p->rcu_boost_mutex = NULL;
> > +       p->rcu_boost_waiter = NULL;
> >  #endif /* #ifdef CONFIG_RCU_BOOST */
> >         INIT_LIST_HEAD(&p->rcu_node_entry);
> >  }
> > diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
> > index 769e12e..d207ddd 100644
> > --- a/kernel/rcutree_plugin.h
> > +++ b/kernel/rcutree_plugin.h
> > @@ -33,6 +33,7 @@
> >  #define RCU_KTHREAD_PRIO 1
> >
> >  #ifdef CONFIG_RCU_BOOST
> > +#include "rtmutex_common.h"
> >  #define RCU_BOOST_PRIO CONFIG_RCU_BOOST_PRIO
> >  #else
> >  #define RCU_BOOST_PRIO RCU_KTHREAD_PRIO
> > @@ -340,7 +341,7 @@ void rcu_read_unlock_special(struct task_struct *t)
> >         unsigned long flags;
> >         struct list_head *np;
> >  #ifdef CONFIG_RCU_BOOST
> > -       struct rt_mutex *rbmp = NULL;
> > +       struct rt_mutex_waiter *waiter = NULL;
> >  #endif /* #ifdef CONFIG_RCU_BOOST */
> >         struct rcu_node *rnp;
> >         int special;
> > @@ -397,10 +398,10 @@ void rcu_read_unlock_special(struct task_struct *t)
> >  #ifdef CONFIG_RCU_BOOST
> >                 if (&t->rcu_node_entry == rnp->boost_tasks)
> >                         rnp->boost_tasks = np;
> > -               /* Snapshot/clear ->rcu_boost_mutex with rcu_node lock
> > held. */
> > -               if (t->rcu_boost_mutex) {
> > -                       rbmp = t->rcu_boost_mutex;
> > -                       t->rcu_boost_mutex = NULL;
> > +               /* Snapshot/clear ->rcu_boost_waiter with rcu_node lock
> > held. */
> > +               if (t->rcu_boost_waiter) {
> > +                       waiter = t->rcu_boost_waiter;
> > +                       t->rcu_boost_waiter = NULL;
> >                 }
> >  #endif /* #ifdef CONFIG_RCU_BOOST */
> >
> > @@ -426,8 +427,8 @@ void rcu_read_unlock_special(struct task_struct *t)
> >
> >  #ifdef CONFIG_RCU_BOOST
> >                 /* Unboost if we were boosted. */
> > -               if (rbmp)
> > -                       rt_mutex_unlock(rbmp);
> > +               if (waiter)
> > +                       rt_mutex_rcu_deboost_unlock(t, waiter);
> >  #endif /* #ifdef CONFIG_RCU_BOOST */
> >
> >                 /*
> > @@ -1129,9 +1130,6 @@ void exit_rcu(void)
> >  #endif /* #else #ifdef CONFIG_TREE_PREEMPT_RCU */
> >
> >  #ifdef CONFIG_RCU_BOOST
> > -
> > -#include "rtmutex_common.h"
> > -
> >  #ifdef CONFIG_RCU_TRACE
> >
> >  static void rcu_initiate_boost_trace(struct rcu_node *rnp)
> > @@ -1181,14 +1179,15 @@ static int rcu_boost(struct rcu_node *rnp)
> >  {
> >         unsigned long flags;
> >         struct rt_mutex mtx;
> > +       struct rt_mutex_waiter rcu_boost_waiter;
> >         struct task_struct *t;
> >         struct list_head *tb;
> > +       int ret;
> >
> >         if (rnp->exp_tasks == NULL && rnp->boost_tasks == NULL)
> >                 return 0;  /* Nothing left to boost. */
> >
> >         raw_spin_lock_irqsave(&rnp->lock, flags);
> > -
> >         /*
> >          * Recheck under the lock: all tasks in need of boosting
> >          * might exit their RCU read-side critical sections on their own.
> > @@ -1215,7 +1214,7 @@ static int rcu_boost(struct rcu_node *rnp)
> >
> >         /*
> >          * We boost task t by manufacturing an rt_mutex that appears to
> > -        * be held by task t.  We leave a pointer to that rt_mutex where
> > +        * be held by task t.  We leave a pointer to that rt_mutex_waiter
> > where
> >          * task t can find it, and task t will release the mutex when it
> >          * exits its outermost RCU read-side critical section.  Then
> >          * simply acquiring this artificial rt_mutex will boost task
> > @@ -1230,11 +1229,30 @@ static int rcu_boost(struct rcu_node *rnp)
> >          * section.
> >          */
> >         t = container_of(tb, struct task_struct, rcu_node_entry);
> > +       get_task_struct(t);
> >         rt_mutex_init_proxy_locked(&mtx, t);
> > -       t->rcu_boost_mutex = &mtx;
> >         raw_spin_unlock_irqrestore(&rnp->lock, flags);
> > -       rt_mutex_lock(&mtx);  /* Side effect: boosts task t's priority. */
> > -       rt_mutex_unlock(&mtx);  /* Keep lockdep happy. */
> > +
> > +       debug_rt_mutex_init_waiter(&rcu_boost_waiter);
> > +       /* Side effect: boosts task t's priority. */
> > +       ret = rt_mutex_start_proxy_lock(&mtx, &rcu_boost_waiter, current,
> > 0);
> > +       if (WARN_ON_ONCE(ret)) {
> > +               put_task_struct(t);
> > +               return 0; /* temporary stop boosting */
> > +       }
> > +
> > +       raw_spin_lock_irqsave(&rnp->lock, flags);
> > +       if (&t->rcu_node_entry == rnp->exp_tasks ||
> > +           &t->rcu_node_entry == rnp->boost_tasks) {
> > +               t->rcu_boost_waiter = &rcu_boost_waiter;
> > +               raw_spin_unlock_irqrestore(&rnp->lock, flags);
> > +       } else {
> > +               raw_spin_unlock_irqrestore(&rnp->lock, flags);
> > +               rt_mutex_rcu_deboost_unlock(t, &rcu_boost_waiter);
> > +       }
> > +
> > +       put_task_struct(t);
> > +       rt_mutex_finish_proxy_lock(&mtx, NULL, &rcu_boost_waiter, 0);
> >
> >         return ACCESS_ONCE(rnp->exp_tasks) != NULL ||
> >                ACCESS_ONCE(rnp->boost_tasks) != NULL;
> > diff --git a/kernel/rtmutex.c b/kernel/rtmutex.c
> > index 0dd6aec..2f3caee 100644
> > --- a/kernel/rtmutex.c
> > +++ b/kernel/rtmutex.c
> > @@ -734,6 +734,43 @@ rt_mutex_slowunlock(struct rt_mutex *lock)
> >         rt_mutex_adjust_prio(current);
> >  }
> >
> > +#ifdef CONFIG_RCU_BOOST
> > +/*
> > + * rt_mutex_rcu_deboost_unlock() - unlock in irq/bh/process context
> > + *
> > + * please revert the patch which introduces this function when
> > + * rt_mutex's ->wait_lock is irq-off.
> > + */
> > +void rt_mutex_rcu_deboost_unlock(struct task_struct *owner,
> > +                                struct rt_mutex_waiter *waiter)
> > +{
> > +       unsigned long flags;
> > +       struct rt_mutex *lock = waiter->lock;
> > +
> > +       /*
> > +        * The correction of the following code is based on
> > +        * 1) current lock is owned by @owner
> > +        * 2) only one task(@waiter->task) is waiting on the @lock
> > +        * 3) the @waiter has been queued and keeps been queued
> > +        */
> > +       if (WARN_ON_ONCE(rt_mutex_owner(lock) != owner))
> > +               return; /* 1) */
> > +       if (WARN_ON_ONCE(rt_mutex_top_waiter(lock) != waiter))
> > +               return; /* 2) & 3) */
> > +       if (WARN_ON_ONCE(plist_node_empty(&waiter->pi_list_entry)))
> > +               return; /* 2) & 3) */
> > +
> > +       raw_spin_lock_irqsave(&owner->pi_lock, flags);
> > +       plist_del(&waiter->pi_list_entry, &owner->pi_waiters);
> > +       lock->owner = NULL;
> > +       raw_spin_unlock_irqrestore(&owner->pi_lock, flags);
> > +
> > +       wake_up_process(waiter->task);
> > +       /* Undo pi boosting if necessary: */
> > +       rt_mutex_adjust_prio(owner);
> > +}
> > +#endif /* #ifdef CONFIG_RCU_BOOST */
> > +
> >  /*
> >   * debug aware fast / slowpath lock,trylock,unlock
> >   *
> > diff --git a/kernel/rtmutex_common.h b/kernel/rtmutex_common.h
> > index 53a66c8..3cdbe82 100644
> > --- a/kernel/rtmutex_common.h
> > +++ b/kernel/rtmutex_common.h
> > @@ -117,6 +117,11 @@ extern int rt_mutex_finish_proxy_lock(struct rt_mutex
> > *lock,
> >                                       struct rt_mutex_waiter *waiter,
> >                                       int detect_deadlock);
> >
> > +#ifdef CONFIG_RCU_BOOST
> > +void rt_mutex_rcu_deboost_unlock(struct task_struct *owner,
> > +                                struct rt_mutex_waiter *waiter);
> > +#endif /* #ifdef CONFIG_RCU_BOOST */
> > +
> >  #ifdef CONFIG_DEBUG_RT_MUTEXES
> >  # include "rtmutex-debug.h"
> >  #else
> >


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 5/8] rcu: eliminate deadlock for rcu read site
  2013-08-25 17:43                   ` Paul E. McKenney
@ 2013-08-26  2:39                     ` Lai Jiangshan
  2013-08-30  2:05                       ` Paul E. McKenney
  0 siblings, 1 reply; 49+ messages in thread
From: Lai Jiangshan @ 2013-08-26  2:39 UTC (permalink / raw)
  To: paulmck
  Cc: Lai Jiangshan, Steven Rostedt, Peter Zijlstra, LKML,
	Dipankar Sarma, Thomas Gleixner

On 08/26/2013 01:43 AM, Paul E. McKenney wrote:
> On Sun, Aug 25, 2013 at 11:19:37PM +0800, Lai Jiangshan wrote:
>> Hi, Steven
>>
>> Any comments about this patch?
> 
> For whatever it is worth, it ran without incident for two hours worth
> of rcutorture on my P5 test (boosting but no CPU hotplug).
> 
> Lai, do you have a specific test for this patch?  

Also rcutorture.
(A special module is added to ensure all paths of my code are covered.)

> Your deadlock
> scenario looks plausible, but is apparently not occurring in the
> mainline kernel.

Yes, you can leave this possible bug until the real problem happens
or just disallow overlapping.
I can write some debug code for it which allow us find out
the problems earlier.

I guess this is an useful usage pattern of rcu:

again:
	rcu_read_lock();
	obj = read_dereference(ptr);
	spin_lock_XX(obj->lock);
	if (obj is invalid) {
		spin_unlock_XX(obj->lock);
		rcu_read_unlock();
		goto again;
	}
	rcu_read_unlock();
	# use obj
	spin_unlock_XX(obj->lock);

If we encourage this pattern, we should fix all the related problems.

Thanks,
Lai

> 
> 							Thanx, Paul
> 
>> Thanks,
>> Lai
>>
>>
>> On Fri, Aug 23, 2013 at 2:26 PM, Lai Jiangshan <laijs@cn.fujitsu.com> wrote:
>>
>>> [PATCH] rcu/rt_mutex: eliminate a kind of deadlock for rcu read site
>>>
>>> Current rtmutex's lock->wait_lock doesn't disables softirq nor irq, it will
>>> cause rcu read site deadlock when rcu overlaps with any
>>> softirq-context/irq-context lock.
>>>
>>> @L is a spinlock of softirq or irq context.
>>>
>>> CPU1                                    cpu2(rcu boost)
>>> rcu_read_lock()                         rt_mutext_lock()
>>> <preemption and reschedule back>          raw_spin_lock(lock->wait_lock)
>>> spin_lock_XX(L)                           <interrupt and doing softirq or
>>> irq>
>>> rcu_read_unlock()                         do_softirq()
>>>   rcu_read_unlock_special()
>>>     rt_mutext_unlock()
>>>       raw_spin_lock(lock->wait_lock)        spin_lock_XX(L)  **DEADLOCK**
>>>
>>> This patch fixes this kind of deadlock by removing rt_mutext_unlock() from
>>> rcu_read_unlock(), new rt_mutex_rcu_deboost_unlock() is called instead.
>>> Thus rtmutex's lock->wait_lock will not be called from rcu_read_unlock().
>>>
>>> This patch does not eliminate all kinds of rcu-read-site deadlock,
>>> if @L is a scheduler lock, it will be deadlock, we should apply Paul's rule
>>> in this case.(avoid overlapping or preempt_disable()).
>>>
>>> rt_mutex_rcu_deboost_unlock() requires the @waiter is queued, so we
>>> can't directly call rt_mutex_lock(&mtx) in the rcu_boost thread,
>>> we split rt_mutex_lock(&mtx) into two steps just like pi-futex.
>>> This result a internal state in rcu_boost thread and cause
>>> rcu_boost thread a bit more complicated.
>>>
>>> Thanks
>>> Lai
>>>
>>> diff --git a/include/linux/init_task.h b/include/linux/init_task.h
>>> index 5cd0f09..8830874 100644
>>> --- a/include/linux/init_task.h
>>> +++ b/include/linux/init_task.h
>>> @@ -102,7 +102,7 @@ extern struct group_info init_groups;
>>>
>>>  #ifdef CONFIG_RCU_BOOST
>>>  #define INIT_TASK_RCU_BOOST()                                          \
>>> -       .rcu_boost_mutex = NULL,
>>> +       .rcu_boost_waiter = NULL,
>>>  #else
>>>  #define INIT_TASK_RCU_BOOST()
>>>  #endif
>>> diff --git a/include/linux/sched.h b/include/linux/sched.h
>>> index e9995eb..1eca99f 100644
>>> --- a/include/linux/sched.h
>>> +++ b/include/linux/sched.h
>>> @@ -1078,7 +1078,7 @@ struct task_struct {
>>>         struct rcu_node *rcu_blocked_node;
>>>  #endif /* #ifdef CONFIG_TREE_PREEMPT_RCU */
>>>  #ifdef CONFIG_RCU_BOOST
>>> -       struct rt_mutex *rcu_boost_mutex;
>>> +       struct rt_mutex_waiter *rcu_boost_waiter;
>>>  #endif /* #ifdef CONFIG_RCU_BOOST */
>>>
>>>  #if defined(CONFIG_SCHEDSTATS) || defined(CONFIG_TASK_DELAY_ACCT)
>>> @@ -1723,7 +1723,7 @@ static inline void rcu_copy_process(struct
>>> task_struct *p)
>>>         p->rcu_blocked_node = NULL;
>>>  #endif /* #ifdef CONFIG_TREE_PREEMPT_RCU */
>>>  #ifdef CONFIG_RCU_BOOST
>>> -       p->rcu_boost_mutex = NULL;
>>> +       p->rcu_boost_waiter = NULL;
>>>  #endif /* #ifdef CONFIG_RCU_BOOST */
>>>         INIT_LIST_HEAD(&p->rcu_node_entry);
>>>  }
>>> diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
>>> index 769e12e..d207ddd 100644
>>> --- a/kernel/rcutree_plugin.h
>>> +++ b/kernel/rcutree_plugin.h
>>> @@ -33,6 +33,7 @@
>>>  #define RCU_KTHREAD_PRIO 1
>>>
>>>  #ifdef CONFIG_RCU_BOOST
>>> +#include "rtmutex_common.h"
>>>  #define RCU_BOOST_PRIO CONFIG_RCU_BOOST_PRIO
>>>  #else
>>>  #define RCU_BOOST_PRIO RCU_KTHREAD_PRIO
>>> @@ -340,7 +341,7 @@ void rcu_read_unlock_special(struct task_struct *t)
>>>         unsigned long flags;
>>>         struct list_head *np;
>>>  #ifdef CONFIG_RCU_BOOST
>>> -       struct rt_mutex *rbmp = NULL;
>>> +       struct rt_mutex_waiter *waiter = NULL;
>>>  #endif /* #ifdef CONFIG_RCU_BOOST */
>>>         struct rcu_node *rnp;
>>>         int special;
>>> @@ -397,10 +398,10 @@ void rcu_read_unlock_special(struct task_struct *t)
>>>  #ifdef CONFIG_RCU_BOOST
>>>                 if (&t->rcu_node_entry == rnp->boost_tasks)
>>>                         rnp->boost_tasks = np;
>>> -               /* Snapshot/clear ->rcu_boost_mutex with rcu_node lock
>>> held. */
>>> -               if (t->rcu_boost_mutex) {
>>> -                       rbmp = t->rcu_boost_mutex;
>>> -                       t->rcu_boost_mutex = NULL;
>>> +               /* Snapshot/clear ->rcu_boost_waiter with rcu_node lock
>>> held. */
>>> +               if (t->rcu_boost_waiter) {
>>> +                       waiter = t->rcu_boost_waiter;
>>> +                       t->rcu_boost_waiter = NULL;
>>>                 }
>>>  #endif /* #ifdef CONFIG_RCU_BOOST */
>>>
>>> @@ -426,8 +427,8 @@ void rcu_read_unlock_special(struct task_struct *t)
>>>
>>>  #ifdef CONFIG_RCU_BOOST
>>>                 /* Unboost if we were boosted. */
>>> -               if (rbmp)
>>> -                       rt_mutex_unlock(rbmp);
>>> +               if (waiter)
>>> +                       rt_mutex_rcu_deboost_unlock(t, waiter);
>>>  #endif /* #ifdef CONFIG_RCU_BOOST */
>>>
>>>                 /*
>>> @@ -1129,9 +1130,6 @@ void exit_rcu(void)
>>>  #endif /* #else #ifdef CONFIG_TREE_PREEMPT_RCU */
>>>
>>>  #ifdef CONFIG_RCU_BOOST
>>> -
>>> -#include "rtmutex_common.h"
>>> -
>>>  #ifdef CONFIG_RCU_TRACE
>>>
>>>  static void rcu_initiate_boost_trace(struct rcu_node *rnp)
>>> @@ -1181,14 +1179,15 @@ static int rcu_boost(struct rcu_node *rnp)
>>>  {
>>>         unsigned long flags;
>>>         struct rt_mutex mtx;
>>> +       struct rt_mutex_waiter rcu_boost_waiter;
>>>         struct task_struct *t;
>>>         struct list_head *tb;
>>> +       int ret;
>>>
>>>         if (rnp->exp_tasks == NULL && rnp->boost_tasks == NULL)
>>>                 return 0;  /* Nothing left to boost. */
>>>
>>>         raw_spin_lock_irqsave(&rnp->lock, flags);
>>> -
>>>         /*
>>>          * Recheck under the lock: all tasks in need of boosting
>>>          * might exit their RCU read-side critical sections on their own.
>>> @@ -1215,7 +1214,7 @@ static int rcu_boost(struct rcu_node *rnp)
>>>
>>>         /*
>>>          * We boost task t by manufacturing an rt_mutex that appears to
>>> -        * be held by task t.  We leave a pointer to that rt_mutex where
>>> +        * be held by task t.  We leave a pointer to that rt_mutex_waiter
>>> where
>>>          * task t can find it, and task t will release the mutex when it
>>>          * exits its outermost RCU read-side critical section.  Then
>>>          * simply acquiring this artificial rt_mutex will boost task
>>> @@ -1230,11 +1229,30 @@ static int rcu_boost(struct rcu_node *rnp)
>>>          * section.
>>>          */
>>>         t = container_of(tb, struct task_struct, rcu_node_entry);
>>> +       get_task_struct(t);
>>>         rt_mutex_init_proxy_locked(&mtx, t);
>>> -       t->rcu_boost_mutex = &mtx;
>>>         raw_spin_unlock_irqrestore(&rnp->lock, flags);
>>> -       rt_mutex_lock(&mtx);  /* Side effect: boosts task t's priority. */
>>> -       rt_mutex_unlock(&mtx);  /* Keep lockdep happy. */
>>> +
>>> +       debug_rt_mutex_init_waiter(&rcu_boost_waiter);
>>> +       /* Side effect: boosts task t's priority. */
>>> +       ret = rt_mutex_start_proxy_lock(&mtx, &rcu_boost_waiter, current,
>>> 0);
>>> +       if (WARN_ON_ONCE(ret)) {
>>> +               put_task_struct(t);
>>> +               return 0; /* temporary stop boosting */
>>> +       }
>>> +
>>> +       raw_spin_lock_irqsave(&rnp->lock, flags);
>>> +       if (&t->rcu_node_entry == rnp->exp_tasks ||
>>> +           &t->rcu_node_entry == rnp->boost_tasks) {
>>> +               t->rcu_boost_waiter = &rcu_boost_waiter;
>>> +               raw_spin_unlock_irqrestore(&rnp->lock, flags);
>>> +       } else {
>>> +               raw_spin_unlock_irqrestore(&rnp->lock, flags);
>>> +               rt_mutex_rcu_deboost_unlock(t, &rcu_boost_waiter);
>>> +       }
>>> +
>>> +       put_task_struct(t);
>>> +       rt_mutex_finish_proxy_lock(&mtx, NULL, &rcu_boost_waiter, 0);
>>>
>>>         return ACCESS_ONCE(rnp->exp_tasks) != NULL ||
>>>                ACCESS_ONCE(rnp->boost_tasks) != NULL;
>>> diff --git a/kernel/rtmutex.c b/kernel/rtmutex.c
>>> index 0dd6aec..2f3caee 100644
>>> --- a/kernel/rtmutex.c
>>> +++ b/kernel/rtmutex.c
>>> @@ -734,6 +734,43 @@ rt_mutex_slowunlock(struct rt_mutex *lock)
>>>         rt_mutex_adjust_prio(current);
>>>  }
>>>
>>> +#ifdef CONFIG_RCU_BOOST
>>> +/*
>>> + * rt_mutex_rcu_deboost_unlock() - unlock in irq/bh/process context
>>> + *
>>> + * please revert the patch which introduces this function when
>>> + * rt_mutex's ->wait_lock is irq-off.
>>> + */
>>> +void rt_mutex_rcu_deboost_unlock(struct task_struct *owner,
>>> +                                struct rt_mutex_waiter *waiter)
>>> +{
>>> +       unsigned long flags;
>>> +       struct rt_mutex *lock = waiter->lock;
>>> +
>>> +       /*
>>> +        * The correction of the following code is based on
>>> +        * 1) current lock is owned by @owner
>>> +        * 2) only one task(@waiter->task) is waiting on the @lock
>>> +        * 3) the @waiter has been queued and keeps been queued
>>> +        */
>>> +       if (WARN_ON_ONCE(rt_mutex_owner(lock) != owner))
>>> +               return; /* 1) */
>>> +       if (WARN_ON_ONCE(rt_mutex_top_waiter(lock) != waiter))
>>> +               return; /* 2) & 3) */
>>> +       if (WARN_ON_ONCE(plist_node_empty(&waiter->pi_list_entry)))
>>> +               return; /* 2) & 3) */
>>> +
>>> +       raw_spin_lock_irqsave(&owner->pi_lock, flags);
>>> +       plist_del(&waiter->pi_list_entry, &owner->pi_waiters);
>>> +       lock->owner = NULL;
>>> +       raw_spin_unlock_irqrestore(&owner->pi_lock, flags);
>>> +
>>> +       wake_up_process(waiter->task);
>>> +       /* Undo pi boosting if necessary: */
>>> +       rt_mutex_adjust_prio(owner);
>>> +}
>>> +#endif /* #ifdef CONFIG_RCU_BOOST */
>>> +
>>>  /*
>>>   * debug aware fast / slowpath lock,trylock,unlock
>>>   *
>>> diff --git a/kernel/rtmutex_common.h b/kernel/rtmutex_common.h
>>> index 53a66c8..3cdbe82 100644
>>> --- a/kernel/rtmutex_common.h
>>> +++ b/kernel/rtmutex_common.h
>>> @@ -117,6 +117,11 @@ extern int rt_mutex_finish_proxy_lock(struct rt_mutex
>>> *lock,
>>>                                       struct rt_mutex_waiter *waiter,
>>>                                       int detect_deadlock);
>>>
>>> +#ifdef CONFIG_RCU_BOOST
>>> +void rt_mutex_rcu_deboost_unlock(struct task_struct *owner,
>>> +                                struct rt_mutex_waiter *waiter);
>>> +#endif /* #ifdef CONFIG_RCU_BOOST */
>>> +
>>>  #ifdef CONFIG_DEBUG_RT_MUTEXES
>>>  # include "rtmutex-debug.h"
>>>  #else
>>>
> 
> --
> 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/
> 


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 5/8] rcu: eliminate deadlock for rcu read site
  2013-08-26  2:39                     ` Lai Jiangshan
@ 2013-08-30  2:05                       ` Paul E. McKenney
  0 siblings, 0 replies; 49+ messages in thread
From: Paul E. McKenney @ 2013-08-30  2:05 UTC (permalink / raw)
  To: Lai Jiangshan
  Cc: Lai Jiangshan, Steven Rostedt, Peter Zijlstra, LKML,
	Dipankar Sarma, Thomas Gleixner

On Mon, Aug 26, 2013 at 10:39:32AM +0800, Lai Jiangshan wrote:
> On 08/26/2013 01:43 AM, Paul E. McKenney wrote:
> > On Sun, Aug 25, 2013 at 11:19:37PM +0800, Lai Jiangshan wrote:
> >> Hi, Steven
> >>
> >> Any comments about this patch?
> > 
> > For whatever it is worth, it ran without incident for two hours worth
> > of rcutorture on my P5 test (boosting but no CPU hotplug).
> > 
> > Lai, do you have a specific test for this patch?  
> 
> Also rcutorture.
> (A special module is added to ensure all paths of my code are covered.)

OK, good!  Could you please send along your rcutorture changes as well?

Also, it would be good to have Steven Rostedt's Acked-by or Reviewed-by.

> > Your deadlock
> > scenario looks plausible, but is apparently not occurring in the
> > mainline kernel.
> 
> Yes, you can leave this possible bug until the real problem happens
> or just disallow overlapping.
> I can write some debug code for it which allow us find out
> the problems earlier.
> 
> I guess this is an useful usage pattern of rcu:
> 
> again:
> 	rcu_read_lock();
> 	obj = read_dereference(ptr);
> 	spin_lock_XX(obj->lock);
> 	if (obj is invalid) {
> 		spin_unlock_XX(obj->lock);
> 		rcu_read_unlock();
> 		goto again;
> 	}
> 	rcu_read_unlock();
> 	# use obj
> 	spin_unlock_XX(obj->lock);
> 
> If we encourage this pattern, we should fix all the related problems.

Given that I have had to ask people to move away from this pattern,
it would be good to allow it to work.  The transformation to currently
permitted usage is as follows, for whatever it is worth:

again:
	disable_XX();
	rcu_read_lock();
	obj = read_dereference(ptr);
	spin_lock(obj->lock);
	if (obj is invalid) {
		spin_unlock_XX(obj->lock);
		rcu_read_unlock();
		goto again;
	}
	rcu_read_unlock();
	# use obj
	spin_unlock_XX(obj->lock);

In mainline, this prevents preemption within the RCU read-side critical
section, avoiding the problem.

That said, if we allow your original pattern, that would be even better!

							Thanx, Paul

> Thanks,
> Lai
> 
> > 
> > 							Thanx, Paul
> > 
> >> Thanks,
> >> Lai
> >>
> >>
> >> On Fri, Aug 23, 2013 at 2:26 PM, Lai Jiangshan <laijs@cn.fujitsu.com> wrote:
> >>
> >>> [PATCH] rcu/rt_mutex: eliminate a kind of deadlock for rcu read site
> >>>
> >>> Current rtmutex's lock->wait_lock doesn't disables softirq nor irq, it will
> >>> cause rcu read site deadlock when rcu overlaps with any
> >>> softirq-context/irq-context lock.
> >>>
> >>> @L is a spinlock of softirq or irq context.
> >>>
> >>> CPU1                                    cpu2(rcu boost)
> >>> rcu_read_lock()                         rt_mutext_lock()
> >>> <preemption and reschedule back>          raw_spin_lock(lock->wait_lock)
> >>> spin_lock_XX(L)                           <interrupt and doing softirq or
> >>> irq>
> >>> rcu_read_unlock()                         do_softirq()
> >>>   rcu_read_unlock_special()
> >>>     rt_mutext_unlock()
> >>>       raw_spin_lock(lock->wait_lock)        spin_lock_XX(L)  **DEADLOCK**
> >>>
> >>> This patch fixes this kind of deadlock by removing rt_mutext_unlock() from
> >>> rcu_read_unlock(), new rt_mutex_rcu_deboost_unlock() is called instead.
> >>> Thus rtmutex's lock->wait_lock will not be called from rcu_read_unlock().
> >>>
> >>> This patch does not eliminate all kinds of rcu-read-site deadlock,
> >>> if @L is a scheduler lock, it will be deadlock, we should apply Paul's rule
> >>> in this case.(avoid overlapping or preempt_disable()).
> >>>
> >>> rt_mutex_rcu_deboost_unlock() requires the @waiter is queued, so we
> >>> can't directly call rt_mutex_lock(&mtx) in the rcu_boost thread,
> >>> we split rt_mutex_lock(&mtx) into two steps just like pi-futex.
> >>> This result a internal state in rcu_boost thread and cause
> >>> rcu_boost thread a bit more complicated.
> >>>
> >>> Thanks
> >>> Lai
> >>>
> >>> diff --git a/include/linux/init_task.h b/include/linux/init_task.h
> >>> index 5cd0f09..8830874 100644
> >>> --- a/include/linux/init_task.h
> >>> +++ b/include/linux/init_task.h
> >>> @@ -102,7 +102,7 @@ extern struct group_info init_groups;
> >>>
> >>>  #ifdef CONFIG_RCU_BOOST
> >>>  #define INIT_TASK_RCU_BOOST()                                          \
> >>> -       .rcu_boost_mutex = NULL,
> >>> +       .rcu_boost_waiter = NULL,
> >>>  #else
> >>>  #define INIT_TASK_RCU_BOOST()
> >>>  #endif
> >>> diff --git a/include/linux/sched.h b/include/linux/sched.h
> >>> index e9995eb..1eca99f 100644
> >>> --- a/include/linux/sched.h
> >>> +++ b/include/linux/sched.h
> >>> @@ -1078,7 +1078,7 @@ struct task_struct {
> >>>         struct rcu_node *rcu_blocked_node;
> >>>  #endif /* #ifdef CONFIG_TREE_PREEMPT_RCU */
> >>>  #ifdef CONFIG_RCU_BOOST
> >>> -       struct rt_mutex *rcu_boost_mutex;
> >>> +       struct rt_mutex_waiter *rcu_boost_waiter;
> >>>  #endif /* #ifdef CONFIG_RCU_BOOST */
> >>>
> >>>  #if defined(CONFIG_SCHEDSTATS) || defined(CONFIG_TASK_DELAY_ACCT)
> >>> @@ -1723,7 +1723,7 @@ static inline void rcu_copy_process(struct
> >>> task_struct *p)
> >>>         p->rcu_blocked_node = NULL;
> >>>  #endif /* #ifdef CONFIG_TREE_PREEMPT_RCU */
> >>>  #ifdef CONFIG_RCU_BOOST
> >>> -       p->rcu_boost_mutex = NULL;
> >>> +       p->rcu_boost_waiter = NULL;
> >>>  #endif /* #ifdef CONFIG_RCU_BOOST */
> >>>         INIT_LIST_HEAD(&p->rcu_node_entry);
> >>>  }
> >>> diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
> >>> index 769e12e..d207ddd 100644
> >>> --- a/kernel/rcutree_plugin.h
> >>> +++ b/kernel/rcutree_plugin.h
> >>> @@ -33,6 +33,7 @@
> >>>  #define RCU_KTHREAD_PRIO 1
> >>>
> >>>  #ifdef CONFIG_RCU_BOOST
> >>> +#include "rtmutex_common.h"
> >>>  #define RCU_BOOST_PRIO CONFIG_RCU_BOOST_PRIO
> >>>  #else
> >>>  #define RCU_BOOST_PRIO RCU_KTHREAD_PRIO
> >>> @@ -340,7 +341,7 @@ void rcu_read_unlock_special(struct task_struct *t)
> >>>         unsigned long flags;
> >>>         struct list_head *np;
> >>>  #ifdef CONFIG_RCU_BOOST
> >>> -       struct rt_mutex *rbmp = NULL;
> >>> +       struct rt_mutex_waiter *waiter = NULL;
> >>>  #endif /* #ifdef CONFIG_RCU_BOOST */
> >>>         struct rcu_node *rnp;
> >>>         int special;
> >>> @@ -397,10 +398,10 @@ void rcu_read_unlock_special(struct task_struct *t)
> >>>  #ifdef CONFIG_RCU_BOOST
> >>>                 if (&t->rcu_node_entry == rnp->boost_tasks)
> >>>                         rnp->boost_tasks = np;
> >>> -               /* Snapshot/clear ->rcu_boost_mutex with rcu_node lock
> >>> held. */
> >>> -               if (t->rcu_boost_mutex) {
> >>> -                       rbmp = t->rcu_boost_mutex;
> >>> -                       t->rcu_boost_mutex = NULL;
> >>> +               /* Snapshot/clear ->rcu_boost_waiter with rcu_node lock
> >>> held. */
> >>> +               if (t->rcu_boost_waiter) {
> >>> +                       waiter = t->rcu_boost_waiter;
> >>> +                       t->rcu_boost_waiter = NULL;
> >>>                 }
> >>>  #endif /* #ifdef CONFIG_RCU_BOOST */
> >>>
> >>> @@ -426,8 +427,8 @@ void rcu_read_unlock_special(struct task_struct *t)
> >>>
> >>>  #ifdef CONFIG_RCU_BOOST
> >>>                 /* Unboost if we were boosted. */
> >>> -               if (rbmp)
> >>> -                       rt_mutex_unlock(rbmp);
> >>> +               if (waiter)
> >>> +                       rt_mutex_rcu_deboost_unlock(t, waiter);
> >>>  #endif /* #ifdef CONFIG_RCU_BOOST */
> >>>
> >>>                 /*
> >>> @@ -1129,9 +1130,6 @@ void exit_rcu(void)
> >>>  #endif /* #else #ifdef CONFIG_TREE_PREEMPT_RCU */
> >>>
> >>>  #ifdef CONFIG_RCU_BOOST
> >>> -
> >>> -#include "rtmutex_common.h"
> >>> -
> >>>  #ifdef CONFIG_RCU_TRACE
> >>>
> >>>  static void rcu_initiate_boost_trace(struct rcu_node *rnp)
> >>> @@ -1181,14 +1179,15 @@ static int rcu_boost(struct rcu_node *rnp)
> >>>  {
> >>>         unsigned long flags;
> >>>         struct rt_mutex mtx;
> >>> +       struct rt_mutex_waiter rcu_boost_waiter;
> >>>         struct task_struct *t;
> >>>         struct list_head *tb;
> >>> +       int ret;
> >>>
> >>>         if (rnp->exp_tasks == NULL && rnp->boost_tasks == NULL)
> >>>                 return 0;  /* Nothing left to boost. */
> >>>
> >>>         raw_spin_lock_irqsave(&rnp->lock, flags);
> >>> -
> >>>         /*
> >>>          * Recheck under the lock: all tasks in need of boosting
> >>>          * might exit their RCU read-side critical sections on their own.
> >>> @@ -1215,7 +1214,7 @@ static int rcu_boost(struct rcu_node *rnp)
> >>>
> >>>         /*
> >>>          * We boost task t by manufacturing an rt_mutex that appears to
> >>> -        * be held by task t.  We leave a pointer to that rt_mutex where
> >>> +        * be held by task t.  We leave a pointer to that rt_mutex_waiter
> >>> where
> >>>          * task t can find it, and task t will release the mutex when it
> >>>          * exits its outermost RCU read-side critical section.  Then
> >>>          * simply acquiring this artificial rt_mutex will boost task
> >>> @@ -1230,11 +1229,30 @@ static int rcu_boost(struct rcu_node *rnp)
> >>>          * section.
> >>>          */
> >>>         t = container_of(tb, struct task_struct, rcu_node_entry);
> >>> +       get_task_struct(t);
> >>>         rt_mutex_init_proxy_locked(&mtx, t);
> >>> -       t->rcu_boost_mutex = &mtx;
> >>>         raw_spin_unlock_irqrestore(&rnp->lock, flags);
> >>> -       rt_mutex_lock(&mtx);  /* Side effect: boosts task t's priority. */
> >>> -       rt_mutex_unlock(&mtx);  /* Keep lockdep happy. */
> >>> +
> >>> +       debug_rt_mutex_init_waiter(&rcu_boost_waiter);
> >>> +       /* Side effect: boosts task t's priority. */
> >>> +       ret = rt_mutex_start_proxy_lock(&mtx, &rcu_boost_waiter, current,
> >>> 0);
> >>> +       if (WARN_ON_ONCE(ret)) {
> >>> +               put_task_struct(t);
> >>> +               return 0; /* temporary stop boosting */
> >>> +       }
> >>> +
> >>> +       raw_spin_lock_irqsave(&rnp->lock, flags);
> >>> +       if (&t->rcu_node_entry == rnp->exp_tasks ||
> >>> +           &t->rcu_node_entry == rnp->boost_tasks) {
> >>> +               t->rcu_boost_waiter = &rcu_boost_waiter;
> >>> +               raw_spin_unlock_irqrestore(&rnp->lock, flags);
> >>> +       } else {
> >>> +               raw_spin_unlock_irqrestore(&rnp->lock, flags);
> >>> +               rt_mutex_rcu_deboost_unlock(t, &rcu_boost_waiter);
> >>> +       }
> >>> +
> >>> +       put_task_struct(t);
> >>> +       rt_mutex_finish_proxy_lock(&mtx, NULL, &rcu_boost_waiter, 0);
> >>>
> >>>         return ACCESS_ONCE(rnp->exp_tasks) != NULL ||
> >>>                ACCESS_ONCE(rnp->boost_tasks) != NULL;
> >>> diff --git a/kernel/rtmutex.c b/kernel/rtmutex.c
> >>> index 0dd6aec..2f3caee 100644
> >>> --- a/kernel/rtmutex.c
> >>> +++ b/kernel/rtmutex.c
> >>> @@ -734,6 +734,43 @@ rt_mutex_slowunlock(struct rt_mutex *lock)
> >>>         rt_mutex_adjust_prio(current);
> >>>  }
> >>>
> >>> +#ifdef CONFIG_RCU_BOOST
> >>> +/*
> >>> + * rt_mutex_rcu_deboost_unlock() - unlock in irq/bh/process context
> >>> + *
> >>> + * please revert the patch which introduces this function when
> >>> + * rt_mutex's ->wait_lock is irq-off.
> >>> + */
> >>> +void rt_mutex_rcu_deboost_unlock(struct task_struct *owner,
> >>> +                                struct rt_mutex_waiter *waiter)
> >>> +{
> >>> +       unsigned long flags;
> >>> +       struct rt_mutex *lock = waiter->lock;
> >>> +
> >>> +       /*
> >>> +        * The correction of the following code is based on
> >>> +        * 1) current lock is owned by @owner
> >>> +        * 2) only one task(@waiter->task) is waiting on the @lock
> >>> +        * 3) the @waiter has been queued and keeps been queued
> >>> +        */
> >>> +       if (WARN_ON_ONCE(rt_mutex_owner(lock) != owner))
> >>> +               return; /* 1) */
> >>> +       if (WARN_ON_ONCE(rt_mutex_top_waiter(lock) != waiter))
> >>> +               return; /* 2) & 3) */
> >>> +       if (WARN_ON_ONCE(plist_node_empty(&waiter->pi_list_entry)))
> >>> +               return; /* 2) & 3) */
> >>> +
> >>> +       raw_spin_lock_irqsave(&owner->pi_lock, flags);
> >>> +       plist_del(&waiter->pi_list_entry, &owner->pi_waiters);
> >>> +       lock->owner = NULL;
> >>> +       raw_spin_unlock_irqrestore(&owner->pi_lock, flags);
> >>> +
> >>> +       wake_up_process(waiter->task);
> >>> +       /* Undo pi boosting if necessary: */
> >>> +       rt_mutex_adjust_prio(owner);
> >>> +}
> >>> +#endif /* #ifdef CONFIG_RCU_BOOST */
> >>> +
> >>>  /*
> >>>   * debug aware fast / slowpath lock,trylock,unlock
> >>>   *
> >>> diff --git a/kernel/rtmutex_common.h b/kernel/rtmutex_common.h
> >>> index 53a66c8..3cdbe82 100644
> >>> --- a/kernel/rtmutex_common.h
> >>> +++ b/kernel/rtmutex_common.h
> >>> @@ -117,6 +117,11 @@ extern int rt_mutex_finish_proxy_lock(struct rt_mutex
> >>> *lock,
> >>>                                       struct rt_mutex_waiter *waiter,
> >>>                                       int detect_deadlock);
> >>>
> >>> +#ifdef CONFIG_RCU_BOOST
> >>> +void rt_mutex_rcu_deboost_unlock(struct task_struct *owner,
> >>> +                                struct rt_mutex_waiter *waiter);
> >>> +#endif /* #ifdef CONFIG_RCU_BOOST */
> >>> +
> >>>  #ifdef CONFIG_DEBUG_RT_MUTEXES
> >>>  # include "rtmutex-debug.h"
> >>>  #else
> >>>
> > 
> > --
> > 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/
> > 
> 


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 5/8] rcu: eliminate deadlock for rcu read site
  2013-08-23  6:26               ` Lai Jiangshan
       [not found]                 ` <CACvQF51kcLrJsa=zBKhLkJfFBh109TW+Zrepm+tRxmEp0gALbQ@mail.gmail.com>
@ 2013-09-05 15:22                 ` Steven Rostedt
  1 sibling, 0 replies; 49+ messages in thread
From: Steven Rostedt @ 2013-09-05 15:22 UTC (permalink / raw)
  To: Lai Jiangshan
  Cc: Lai Jiangshan, Peter Zijlstra, Paul McKenney, LKML,
	Dipankar Sarma, Thomas Gleixner


Sorry for taking so long to review. So many other things to do :-/

On Fri, 23 Aug 2013 14:26:39 +0800
Lai Jiangshan <laijs@cn.fujitsu.com> wrote:

> [PATCH] rcu/rt_mutex: eliminate a kind of deadlock for rcu read site

"rcu read site"?

This is specific to boosting, thus boosting should be in the subject,
perhaps something like:

"Eliminate deadlock due to rcu boosting"

?

> 
> Current rtmutex's lock->wait_lock doesn't disables softirq nor irq, it will
> cause rcu read site deadlock when rcu overlaps with any softirq-context/irq-context lock.
> 
> @L is a spinlock of softirq or irq context.
> 
> CPU1					cpu2(rcu boost)
> rcu_read_lock()				rt_mutext_lock()
> <preemption and reschedule back>	  raw_spin_lock(lock->wait_lock)
> spin_lock_XX(L)				  <interrupt and doing softirq or irq>
> rcu_read_unlock()                         do_softirq()
>   rcu_read_unlock_special()
>     rt_mutext_unlock()
>       raw_spin_lock(lock->wait_lock)	    spin_lock_XX(L)  **DEADLOCK**
> 
> This patch fixes this kind of deadlock by removing rt_mutext_unlock() from
> rcu_read_unlock(), new rt_mutex_rcu_deboost_unlock() is called instead.
> Thus rtmutex's lock->wait_lock will not be called from rcu_read_unlock().
> 
> This patch does not eliminate all kinds of rcu-read-site deadlock,
> if @L is a scheduler lock, it will be deadlock, we should apply Paul's rule
> in this case.(avoid overlapping or preempt_disable()).
> 
> rt_mutex_rcu_deboost_unlock() requires the @waiter is queued, so we
> can't directly call rt_mutex_lock(&mtx) in the rcu_boost thread,
> we split rt_mutex_lock(&mtx) into two steps just like pi-futex.
> This result a internal state in rcu_boost thread and cause
> rcu_boost thread a bit more complicated.
> 
> Thanks
> Lai
> 
> diff --git a/include/linux/init_task.h b/include/linux/init_task.h
> index 5cd0f09..8830874 100644
> --- a/include/linux/init_task.h
> +++ b/include/linux/init_task.h
> @@ -102,7 +102,7 @@ extern struct group_info init_groups;
>  
>  #ifdef CONFIG_RCU_BOOST
>  #define INIT_TASK_RCU_BOOST()						\
> -	.rcu_boost_mutex = NULL,
> +	.rcu_boost_waiter = NULL,
>  #else
>  #define INIT_TASK_RCU_BOOST()
>  #endif
> diff --git a/include/linux/sched.h b/include/linux/sched.h
> index e9995eb..1eca99f 100644
> --- a/include/linux/sched.h
> +++ b/include/linux/sched.h
> @@ -1078,7 +1078,7 @@ struct task_struct {
>  	struct rcu_node *rcu_blocked_node;
>  #endif /* #ifdef CONFIG_TREE_PREEMPT_RCU */
>  #ifdef CONFIG_RCU_BOOST
> -	struct rt_mutex *rcu_boost_mutex;
> +	struct rt_mutex_waiter *rcu_boost_waiter;
>  #endif /* #ifdef CONFIG_RCU_BOOST */
>  
>  #if defined(CONFIG_SCHEDSTATS) || defined(CONFIG_TASK_DELAY_ACCT)
> @@ -1723,7 +1723,7 @@ static inline void rcu_copy_process(struct task_struct *p)
>  	p->rcu_blocked_node = NULL;
>  #endif /* #ifdef CONFIG_TREE_PREEMPT_RCU */
>  #ifdef CONFIG_RCU_BOOST
> -	p->rcu_boost_mutex = NULL;
> +	p->rcu_boost_waiter = NULL;
>  #endif /* #ifdef CONFIG_RCU_BOOST */
>  	INIT_LIST_HEAD(&p->rcu_node_entry);
>  }
> diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
> index 769e12e..d207ddd 100644
> --- a/kernel/rcutree_plugin.h
> +++ b/kernel/rcutree_plugin.h
> @@ -33,6 +33,7 @@
>  #define RCU_KTHREAD_PRIO 1
>  
>  #ifdef CONFIG_RCU_BOOST
> +#include "rtmutex_common.h"
>  #define RCU_BOOST_PRIO CONFIG_RCU_BOOST_PRIO
>  #else
>  #define RCU_BOOST_PRIO RCU_KTHREAD_PRIO
> @@ -340,7 +341,7 @@ void rcu_read_unlock_special(struct task_struct *t)
>  	unsigned long flags;
>  	struct list_head *np;
>  #ifdef CONFIG_RCU_BOOST
> -	struct rt_mutex *rbmp = NULL;
> +	struct rt_mutex_waiter *waiter = NULL;
>  #endif /* #ifdef CONFIG_RCU_BOOST */
>  	struct rcu_node *rnp;
>  	int special;
> @@ -397,10 +398,10 @@ void rcu_read_unlock_special(struct task_struct *t)
>  #ifdef CONFIG_RCU_BOOST
>  		if (&t->rcu_node_entry == rnp->boost_tasks)
>  			rnp->boost_tasks = np;
> -		/* Snapshot/clear ->rcu_boost_mutex with rcu_node lock held. */
> -		if (t->rcu_boost_mutex) {
> -			rbmp = t->rcu_boost_mutex;
> -			t->rcu_boost_mutex = NULL;
> +		/* Snapshot/clear ->rcu_boost_waiter with rcu_node lock held. */
> +		if (t->rcu_boost_waiter) {
> +			waiter = t->rcu_boost_waiter;
> +			t->rcu_boost_waiter = NULL;
>  		}
>  #endif /* #ifdef CONFIG_RCU_BOOST */
>  
> @@ -426,8 +427,8 @@ void rcu_read_unlock_special(struct task_struct *t)
>  
>  #ifdef CONFIG_RCU_BOOST
>  		/* Unboost if we were boosted. */
> -		if (rbmp)
> -			rt_mutex_unlock(rbmp);
> +		if (waiter)
> +			rt_mutex_rcu_deboost_unlock(t, waiter);
>  #endif /* #ifdef CONFIG_RCU_BOOST */
>  
>  		/*
> @@ -1129,9 +1130,6 @@ void exit_rcu(void)
>  #endif /* #else #ifdef CONFIG_TREE_PREEMPT_RCU */
>  
>  #ifdef CONFIG_RCU_BOOST
> -
> -#include "rtmutex_common.h"
> -
>  #ifdef CONFIG_RCU_TRACE
>  
>  static void rcu_initiate_boost_trace(struct rcu_node *rnp)
> @@ -1181,14 +1179,15 @@ static int rcu_boost(struct rcu_node *rnp)
>  {
>  	unsigned long flags;
>  	struct rt_mutex mtx;
> +	struct rt_mutex_waiter rcu_boost_waiter;
>  	struct task_struct *t;
>  	struct list_head *tb;
> +	int ret;
>  
>  	if (rnp->exp_tasks == NULL && rnp->boost_tasks == NULL)
>  		return 0;  /* Nothing left to boost. */
>  
>  	raw_spin_lock_irqsave(&rnp->lock, flags);
> -
>  	/*
>  	 * Recheck under the lock: all tasks in need of boosting
>  	 * might exit their RCU read-side critical sections on their own.
> @@ -1215,7 +1214,7 @@ static int rcu_boost(struct rcu_node *rnp)
>  
>  	/*
>  	 * We boost task t by manufacturing an rt_mutex that appears to
> -	 * be held by task t.  We leave a pointer to that rt_mutex where
> +	 * be held by task t.  We leave a pointer to that rt_mutex_waiter where
>  	 * task t can find it, and task t will release the mutex when it
>  	 * exits its outermost RCU read-side critical section.  Then
>  	 * simply acquiring this artificial rt_mutex will boost task
> @@ -1230,11 +1229,30 @@ static int rcu_boost(struct rcu_node *rnp)
>  	 * section.
>  	 */
>  	t = container_of(tb, struct task_struct, rcu_node_entry);
> +	get_task_struct(t);
>  	rt_mutex_init_proxy_locked(&mtx, t);
> -	t->rcu_boost_mutex = &mtx;
>  	raw_spin_unlock_irqrestore(&rnp->lock, flags);
> -	rt_mutex_lock(&mtx);  /* Side effect: boosts task t's priority. */
> -	rt_mutex_unlock(&mtx);  /* Keep lockdep happy. */
> +
> +	debug_rt_mutex_init_waiter(&rcu_boost_waiter);
> +	/* Side effect: boosts task t's priority. */
> +	ret = rt_mutex_start_proxy_lock(&mtx, &rcu_boost_waiter, current, 0);
> +	if (WARN_ON_ONCE(ret)) {
> +		put_task_struct(t);
> +		return 0; /* temporary stop boosting */
> +	}
> +
> +	raw_spin_lock_irqsave(&rnp->lock, flags);
> +	if (&t->rcu_node_entry == rnp->exp_tasks ||
> +	    &t->rcu_node_entry == rnp->boost_tasks) {
> +		t->rcu_boost_waiter = &rcu_boost_waiter;
> +		raw_spin_unlock_irqrestore(&rnp->lock, flags);
> +	} else {
> +		raw_spin_unlock_irqrestore(&rnp->lock, flags);
> +		rt_mutex_rcu_deboost_unlock(t, &rcu_boost_waiter);
> +	}
> +
> +	put_task_struct(t);
> +	rt_mutex_finish_proxy_lock(&mtx, NULL, &rcu_boost_waiter, 0);
>  
>  	return ACCESS_ONCE(rnp->exp_tasks) != NULL ||
>  	       ACCESS_ONCE(rnp->boost_tasks) != NULL;
> diff --git a/kernel/rtmutex.c b/kernel/rtmutex.c
> index 0dd6aec..2f3caee 100644
> --- a/kernel/rtmutex.c
> +++ b/kernel/rtmutex.c
> @@ -734,6 +734,43 @@ rt_mutex_slowunlock(struct rt_mutex *lock)
>  	rt_mutex_adjust_prio(current);
>  }
>  
> +#ifdef CONFIG_RCU_BOOST
> +/*
> + * rt_mutex_rcu_deboost_unlock() - unlock in irq/bh/process context
> + *
> + * please revert the patch which introduces this function when
> + * rt_mutex's ->wait_lock is irq-off.

I don't think we ever want wait_lock to disable interrupts. Doing so
for just rcu boosting is not enough IMO.

Please remove that comment.

Honestly, I like this solution better than the original :-) It only
uses the pi boosting and not the rest of the rt_mutex, which is really
just overhead.

Looks good to me. Other than what I already commented:

Reviewed-by: Steven Rostedt <rostedt@goodmis.org>

-- Steve

> + */
> +void rt_mutex_rcu_deboost_unlock(struct task_struct *owner,
> +				 struct rt_mutex_waiter *waiter)
> +{
> +	unsigned long flags;
> +	struct rt_mutex *lock = waiter->lock;
> +
> +	/*
> +	 * The correction of the following code is based on
> +	 * 1) current lock is owned by @owner
> +	 * 2) only one task(@waiter->task) is waiting on the @lock
> +	 * 3) the @waiter has been queued and keeps been queued

"keeps been queued"?  Do you mean "keeps being queued"?

> +	 */
> +	if (WARN_ON_ONCE(rt_mutex_owner(lock) != owner))
> +		return; /* 1) */
> +	if (WARN_ON_ONCE(rt_mutex_top_waiter(lock) != waiter))
> +		return; /* 2) & 3) */
> +	if (WARN_ON_ONCE(plist_node_empty(&waiter->pi_list_entry)))
> +		return; /* 2) & 3) */
> +
> +	raw_spin_lock_irqsave(&owner->pi_lock, flags);
> +	plist_del(&waiter->pi_list_entry, &owner->pi_waiters);
> +	lock->owner = NULL;
> +	raw_spin_unlock_irqrestore(&owner->pi_lock, flags);
> +
> +	wake_up_process(waiter->task);
> +	/* Undo pi boosting if necessary: */
> +	rt_mutex_adjust_prio(owner);
> +}
> +#endif /* #ifdef CONFIG_RCU_BOOST */
> +
>  /*
>   * debug aware fast / slowpath lock,trylock,unlock
>   *
> diff --git a/kernel/rtmutex_common.h b/kernel/rtmutex_common.h
> index 53a66c8..3cdbe82 100644
> --- a/kernel/rtmutex_common.h
> +++ b/kernel/rtmutex_common.h
> @@ -117,6 +117,11 @@ extern int rt_mutex_finish_proxy_lock(struct rt_mutex *lock,
>  				      struct rt_mutex_waiter *waiter,
>  				      int detect_deadlock);
>  
> +#ifdef CONFIG_RCU_BOOST
> +void rt_mutex_rcu_deboost_unlock(struct task_struct *owner,
> +				 struct rt_mutex_waiter *waiter);
> +#endif /* #ifdef CONFIG_RCU_BOOST */
> +
>  #ifdef CONFIG_DEBUG_RT_MUTEXES
>  # include "rtmutex-debug.h"
>  #else


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 1/8] rcu: add a warn to rcu_preempt_note_context_switch()
  2013-08-07 10:24 ` [PATCH 1/8] rcu: add a warn to rcu_preempt_note_context_switch() Lai Jiangshan
@ 2013-10-30 11:02   ` Paul E. McKenney
  0 siblings, 0 replies; 49+ messages in thread
From: Paul E. McKenney @ 2013-10-30 11:02 UTC (permalink / raw)
  To: Lai Jiangshan
  Cc: Steven Rostedt, Peter Zijlstra, linux-kernel, Dipankar Sarma

On Wed, Aug 07, 2013 at 06:24:57PM +0800, Lai Jiangshan wrote:
> It is expected that _nesting == INT_MIN if _nesting < 0.
> Add a warning to it if something unexpected happen.
> 
> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
> ---
>  kernel/rcutree_plugin.h |    1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
> index 63098a5..8fd947e 100644
> --- a/kernel/rcutree_plugin.h
> +++ b/kernel/rcutree_plugin.h
> @@ -243,6 +243,7 @@ static void rcu_preempt_note_context_switch(int cpu)
>  				       : rnp->gpnum + 1);
>  		raw_spin_unlock_irqrestore(&rnp->lock, flags);
>  	} else if (t->rcu_read_lock_nesting < 0 &&
> +		   !WARN_ON_ONCE(t->rcu_read_lock_nesting != INT_MIN) &&

Finally getting back to this...

>From what I can see, this is safe right now because
->rcu_read_lock_nesting is incremented only in case of an interrupt, NMI,
or softirq interrupting the rcu_read_unlock() code path on the one hand,
and because the functions called from rcu_read_unlock_special() currently
disable interrupts before doing any rcu_read_lock()s.  With this in
mind, it is currently impossible to have a context switch occur within
an RCU read-side critical section that is invoked (either directly or
indirectly) from the portion of __rcu_read_unlock() that has negative
->rcu_read_lock_nesting.

But this could change should any part of the rt_mutex_unlock() code
called from rcu_read_unlock_special() were to do rcu_read_lock() before
disabling interrupts.  Is there any reason we should prohibit such a
pattern in rt_mutex_unlock()?

(For the record, I am currently OK prohibiting this pattern in
rcu_report_exp_rnp(), which is also called from rcu_read_unlock_special()
-- it seems unlikely that someone would use RCU to protect RCU's
expedited-grace-period data structures.)

							Thanx, Paul


>  		   t->rcu_read_unlock_special) {
> 
>  		/*
> -- 
> 1.7.4.4
> 


^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 2/8] rcu: remove irq/softirq context check in rcu_read_unlock_special()
  2013-08-07 10:24 ` [PATCH 2/8] rcu: remove irq/softirq context check in rcu_read_unlock_special() Lai Jiangshan
@ 2013-10-30 11:18   ` Paul E. McKenney
  0 siblings, 0 replies; 49+ messages in thread
From: Paul E. McKenney @ 2013-10-30 11:18 UTC (permalink / raw)
  To: Lai Jiangshan
  Cc: Steven Rostedt, Peter Zijlstra, linux-kernel, Dipankar Sarma

On Wed, Aug 07, 2013 at 06:24:58PM +0800, Lai Jiangshan wrote:
> After patch 10f39bb1, "special & RCU_READ_UNLOCK_BLOCKED" can't be true
> in irq nor softirq.(due to RCU_READ_UNLOCK_BLOCKED can only be set
> when preemption)
> 
> Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
> ---
>  kernel/rcutree_plugin.h |    6 ------
>  1 files changed, 0 insertions(+), 6 deletions(-)
> 
> diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
> index 8fd947e..54f7e45 100644
> --- a/kernel/rcutree_plugin.h
> +++ b/kernel/rcutree_plugin.h
> @@ -361,12 +361,6 @@ void rcu_read_unlock_special(struct task_struct *t)
>  		rcu_preempt_qs(smp_processor_id());
>  	}
> 
> -	/* Hardware IRQ handlers cannot block. */
> -	if (in_irq() || in_serving_softirq()) {
> -		local_irq_restore(flags);
> -		return;
> -	}
> -

Good point, it is time to relax the redundant checking.  Paranoid that
I am, I took an intermediate position, wrapping a WARN_ON_ONCE() around
the check as follows:

	if (WARN_ON_ONCE(in_irq() || in_serving_softirq())) {
		local_irq_restore(flags);
		return;
	}

If this warning never triggers over a period of some time, we can remove
it entirely.

I have queued this for 3.14 with your Signed-off-by.  Please let me know
if you have any objections.

							Thanx, Paul

>  	/* Clean up if blocked during RCU read-side critical section. */
>  	if (special & RCU_READ_UNLOCK_BLOCKED) {
>  		t->rcu_read_unlock_special &= ~RCU_READ_UNLOCK_BLOCKED;
> -- 
> 1.7.4.4
> 


^ permalink raw reply	[flat|nested] 49+ messages in thread

end of thread, other threads:[~2013-10-30 11:19 UTC | newest]

Thread overview: 49+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-08-07 10:24 [PATCH 0/8] rcu: Ensure rcu read site is deadlock-immunity Lai Jiangshan
2013-08-07 10:24 ` [PATCH 1/8] rcu: add a warn to rcu_preempt_note_context_switch() Lai Jiangshan
2013-10-30 11:02   ` Paul E. McKenney
2013-08-07 10:24 ` [PATCH 2/8] rcu: remove irq/softirq context check in rcu_read_unlock_special() Lai Jiangshan
2013-10-30 11:18   ` Paul E. McKenney
2013-08-07 10:24 ` [PATCH 3/8] rcu: keep irqs disabled " Lai Jiangshan
2013-08-07 10:25 ` [PATCH 4/8] rcu: delay task rcu state cleanup in exit_rcu() Lai Jiangshan
2013-08-07 10:25 ` [PATCH 5/8] rcu: eliminate deadlock for rcu read site Lai Jiangshan
2013-08-08 20:40   ` Paul E. McKenney
2013-08-09  9:31     ` Lai Jiangshan
2013-08-09 17:58       ` Paul E. McKenney
2013-08-12 13:55       ` Peter Zijlstra
2013-08-12 15:16         ` Paul E. McKenney
2013-08-12 16:21           ` Peter Zijlstra
2013-08-12 16:44             ` Paul E. McKenney
2013-08-10  3:43     ` Lai Jiangshan
2013-08-10 15:07       ` Paul E. McKenney
2013-08-10 15:08         ` Paul E. McKenney
2013-08-21  3:17         ` Paul E. McKenney
2013-08-21  3:25           ` Lai Jiangshan
2013-08-21 13:42             ` Paul E. McKenney
2013-08-12 13:53       ` Peter Zijlstra
2013-08-12 14:10         ` Steven Rostedt
2013-08-12 14:14           ` Peter Zijlstra
     [not found]           ` <CACvQF51-oAGkdxwku+orKSQ=SZd1A4saXzkrgcRGi+KnZUZYxQ@mail.gmail.com>
2013-08-22 14:34             ` Steven Rostedt
2013-08-22 14:41               ` Steven Rostedt
2013-08-23  6:26               ` Lai Jiangshan
     [not found]                 ` <CACvQF51kcLrJsa=zBKhLkJfFBh109TW+Zrepm+tRxmEp0gALbQ@mail.gmail.com>
2013-08-25 17:43                   ` Paul E. McKenney
2013-08-26  2:39                     ` Lai Jiangshan
2013-08-30  2:05                       ` Paul E. McKenney
2013-09-05 15:22                 ` Steven Rostedt
2013-08-07 10:25 ` [PATCH 6/8] rcu: call rcu_read_unlock_special() in rcu_preempt_check_callbacks() Lai Jiangshan
2013-08-07 10:25 ` [PATCH 7/8] rcu: add # of deferred _special() statistics Lai Jiangshan
2013-08-07 16:42   ` Paul E. McKenney
2013-08-07 10:25 ` [PATCH 8/8] rcu: remove irq work for rsp_wakeup() Lai Jiangshan
2013-08-07 12:38 ` [PATCH 0/8] rcu: Ensure rcu read site is deadlock-immunity Paul E. McKenney
2013-08-07 19:29   ` Carsten Emde
2013-08-07 19:52     ` Paul E. McKenney
2013-08-08  1:17     ` Lai Jiangshan
2013-08-08  0:36   ` Paul E. McKenney
2013-08-08  1:47     ` Lai Jiangshan
2013-08-08  2:12       ` Steven Rostedt
2013-08-08  2:33         ` Lai Jiangshan
2013-08-08  2:33           ` Paul E. McKenney
2013-08-08  3:10             ` Lai Jiangshan
2013-08-08  4:18               ` Paul E. McKenney
2013-08-08  5:27                 ` Lai Jiangshan
2013-08-08  7:05                   ` Paul E. McKenney
2013-08-08  2:45         ` Lai Jiangshan

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.