LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Peter Zijlstra <a.p.zijlstra@chello.nl>
To: Ed Tomlinson <edt@aei.ca>
Cc: paulmck@linux.vnet.ibm.com, Steven Rostedt <rostedt@goodmis.org>,
	Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
	Ingo Molnar <mingo@elte.hu>, Thomas Gleixner <tglx@linutronix.de>,
	Andrew Morton <akpm@linux-foundation.org>,
	Dipankar Sarma <dipankar@in.ibm.com>,
	linux-kernel@vger.kernel.org
Subject: Re: INFO: possible circular locking dependency detected
Date: Mon, 18 Jul 2011 11:29:44 +0200	[thread overview]
Message-ID: <1310981384.13765.40.camel@twins> (raw)
In-Reply-To: <201107161542.31755.edt@aei.ca>

On Sat, 2011-07-16 at 15:42 -0400, Ed Tomlinson wrote:
> [39066.195274] -> #2 (rcu_node_level_0){..-.-.}:
> [39066.195274]        [<ffffffff8108b805>] lock_acquire+0x95/0x140
> [39066.195274]        [<ffffffff815780fb>] _raw_spin_lock+0x3b/0x50
> [39066.195274]        [<ffffffff810ba7bf>] __rcu_read_unlock+0x19f/0x2d0
> [39066.195274]        [<ffffffff8103ffc8>] cpuacct_charge+0xc8/0xe0
> [39066.195274]        [<ffffffff81040ee5>] update_curr+0x1a5/0x210
> [39066.195274]        [<ffffffff81043f8a>] enqueue_task_fair+0x7a/0x650
> [39066.195274]        [<ffffffff81035369>] enqueue_task+0x79/0x90
> [39066.195274]        [<ffffffff810353ad>] activate_task+0x2d/0x40
> [39066.195274]        [<ffffffff81036921>] ttwu_activate+0x21/0x50
> [39066.195274]        [<ffffffff810424cc>] T.2447+0x3c/0x60
> [39066.195274]        [<ffffffff81042534>] sched_ttwu_pending+0x44/0x60
> [39066.195274]        [<ffffffff8104255e>] scheduler_ipi+0xe/0x10
> [39066.195274]        [<ffffffff8101e6aa>] smp_reschedule_interrupt+0x2a/0x30 

To go on top of my other patch


---
Subject: sched: Add irq_{enter,exit}() to scheduler_ipi()

Ensure scheduler_ipi() calls irq_{enter,exit} when it does some actual
work. Traditionally we never did any actual work from the resched IPI
and all magic happened in the return from interrupt path.

Now that we do do some work, we need to ensure irq_{enter,exit} are
called so that we don't confuse things.

This affects things like timekeeping, NO_HZ and RCU, basically
everything with a hook in irq_enter/exit.

Explicit examples of things going wrong are:

  sched_clock_cpu() -- has a callback when leaving NO_HZ state to take
                    a new reading from GTOD and TSC. Without this
                    callback, time is stuck in the past.

  RCU -- needs in_irq() to work in order to avoid some nasty deadlocks

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
---
 kernel/sched.c |   40 ++++++++++++++++++++++++++++++++++------
 1 files changed, 34 insertions(+), 6 deletions(-)

diff --git a/kernel/sched.c b/kernel/sched.c
index 8fb4245..eb9cbe7 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -2544,13 +2544,9 @@ static int ttwu_remote(struct task_struct *p, int wake_flags)
 }
 
 #ifdef CONFIG_SMP
-static void sched_ttwu_pending(void)
+static void sched_ttwu_do_pending(struct task_struct *list)
 {
 	struct rq *rq = this_rq();
-	struct task_struct *list = xchg(&rq->wake_list, NULL);
-
-	if (!list)
-		return;
 
 	raw_spin_lock(&rq->lock);
 
@@ -2563,9 +2559,41 @@ static void sched_ttwu_pending(void)
 	raw_spin_unlock(&rq->lock);
 }
 
+static void sched_ttwu_pending(void)
+{
+	struct rq *rq = this_rq();
+	struct task_struct *list = xchg(&rq->wake_list, NULL);
+
+	if (!list)
+		return;
+
+	sched_ttwu_do_pending(list);
+}
+
 void scheduler_ipi(void)
 {
-	sched_ttwu_pending();
+	struct rq *rq = this_rq();
+	struct task_struct *list = xchg(&rq->wake_list, NULL);
+
+	if (!list)
+		return;
+
+	/*
+	 * Not all reschedule IPI handlers call irq_enter/irq_exit, since
+	 * traditionally all their work was done from the interrupt return
+	 * path. Now that we actually do some work, we need to make sure
+	 * we do call them.
+	 *
+	 * Some archs already do call them, luckily irq_enter/exit nest
+	 * properly.
+	 *
+	 * Arguably we should visit all archs and update all handlers,
+	 * however a fair share of IPIs are still resched only so this would
+	 * somewhat pessimize the simple resched case.
+	 */
+	irq_enter();
+	sched_ttwu_do_pending(list);
+	irq_exit();
 }
 
 static void ttwu_queue_remote(struct task_struct *p, int cpu)


  parent reply	other threads:[~2011-07-18  9:30 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-14 14:49 Sergey Senozhatsky
2011-07-14 16:41 ` Peter Zijlstra
2011-07-14 16:57   ` Paul E. McKenney
2011-07-14 19:16     ` Sergey Senozhatsky
2011-07-14 19:15   ` Sergey Senozhatsky
2011-07-14 19:34     ` Paul E. McKenney
2011-07-14 19:38       ` Dave Jones
2011-07-14 20:33         ` Paul E. McKenney
2011-07-14 19:38       ` Sergey Senozhatsky
2011-07-14 16:58 ` Steven Rostedt
2011-07-14 17:02   ` Steven Rostedt
2011-07-14 17:05     ` Paul E. McKenney
2011-07-14 17:32       ` Steven Rostedt
2011-07-14 17:46         ` Steven Rostedt
2011-07-14 19:18           ` Paul E. McKenney
2011-07-14 19:41             ` Steven Rostedt
2011-07-14 20:33               ` Paul E. McKenney
2011-07-15 11:05             ` Ed Tomlinson
2011-07-15 11:29               ` Peter Zijlstra
2011-07-15 11:35                 ` Ed Tomlinson
2011-07-15 11:39                 ` Peter Zijlstra
2011-07-15 18:11                   ` Paul E. McKenney
2011-07-15 12:42                 ` Paul E. McKenney
2011-07-15 13:07                   ` Peter Zijlstra
2011-07-15 14:36                     ` Paul E. McKenney
2011-07-15 15:04                       ` Peter Zijlstra
2011-07-15 15:59                         ` Paul E. McKenney
2011-07-15 16:11                           ` Peter Zijlstra
2011-07-15 16:56                             ` Paul E. McKenney
2011-07-15 21:48                               ` Ed Tomlinson
2011-07-15 22:04                                 ` Paul E. McKenney
2011-07-16 19:42                                   ` Ed Tomlinson
2011-07-17  0:02                                     ` Paul E. McKenney
2011-07-17  1:56                                       ` Ed Tomlinson
2011-07-17 14:28                                         ` Paul E. McKenney
2011-07-18 15:15                                           ` Paul E. McKenney
2011-07-18  9:29                                     ` Peter Zijlstra [this message]
2011-07-18 15:29                                       ` Paul E. McKenney
2011-07-15 16:55                     ` Steven Rostedt
2011-07-15 17:03                       ` Paul E. McKenney
2011-07-15 17:16                         ` Steven Rostedt
2011-07-15 17:24                           ` Paul E. McKenney
2011-07-15 17:42                             ` Steven Rostedt
2011-07-15 18:33                               ` Paul E. McKenney
  -- strict thread matches above, loose matches on Subject: below --
2011-08-07 16:22 Justin P. Mattock
2011-08-11 20:57 ` Justin P. Mattock
2009-12-06 10:11 Richard Zidlicky
2009-10-10 23:09 John Kacur
2007-02-08 15:03 Pedro M. López
2006-10-16 14:05 alpha @ steudten Engineering
2006-10-16 14:32 ` Nick Piggin
2006-10-16 15:42   ` Randy Dunlap
2006-10-16 15:46     ` Nick Piggin
2006-10-19  6:02   ` Andrew Morton
2006-10-19  6:30     ` Nick Piggin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1310981384.13765.40.camel@twins \
    --to=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=dipankar@in.ibm.com \
    --cc=edt@aei.ca \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=rostedt@goodmis.org \
    --cc=sergey.senozhatsky@gmail.com \
    --cc=tglx@linutronix.de \
    --subject='Re: INFO: possible circular locking dependency detected' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).