All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Sasha Levin <sasha.levin@oracle.com>
Cc: Jan Kara <jack@suse.cz>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Dave Jones <davej@redhat.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ingo Molnar <mingo@kernel.org>
Subject: Re: mm,console: circular dependency between console_sem and zone lock
Date: Tue, 3 Jun 2014 11:00:10 +0200	[thread overview]
Message-ID: <20140603090010.GP11096@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <538B33D5.8070002@oracle.com>

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

On Sun, Jun 01, 2014 at 10:08:21AM -0400, Sasha Levin wrote:
> On 05/12/2014 12:28 PM, Jan Kara wrote:
> > On Wed 07-05-14 22:03:08, Sasha Levin wrote:
> >> > Hi all,
> >> > 
> >> > While fuzzing with trinity inside a KVM tools guest running the latest -next
> >> > kernel I've stumbled on the following spew:
> >   Thanks for report. So the problem seems to be maginally valid but I'm not
> > 100% sure whom to blame :). So printk() code calls up() which calls
> > try_to_wake_up() under console_sem.lock spinlock. That function can take
> > rq->lock which is all expected.
> > 
> > The next part of the chain is that during CPU initialization we call
> > __sched_fork() with rq->lock which calls into hrtimer_init() which can
> > allocate memory which creates a dependency rq->lock => zone.lock.rlock.
> > 
> > And memory management code calls printk() which zone.lock.rlock held which
> > closes the loop. Now I suspect the second link in the chain can happen only
> > while CPU is booting and might even happen only if some debug options are
> > enabled. But I don't really know scheduler code well enough. Steven?
> 
> I've cc'ed Peter and Ingo who may be able to answer that, as it still happens
> on -next.

Ah, cute.

So the second paragraph seems to miss the detail that this is the
__sched_fork() call from init_idle(), all other callers don't actually
hold the rq->lock.

Now init_idle() is called from:

	sched_init()
	fork_idle()
	idle_thread_get()

Now fork_idle() is called from:

	smp_init() -> idle_threads_init() -> idle_init()

and idle_thread_get is called from:

	_cpu_up()


So while it looks we're calling __sched_fork() twice for every !boot
idle thread (urgh) we do appear to call it before anything is running on
that cpu, so I don't see any particular problem with removing the call
from under that lock.

Something like so should do I suppose.

---
 kernel/sched/core.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 240aa83e73f5..99609c33482b 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -4505,9 +4505,10 @@ void init_idle(struct task_struct *idle, int cpu)
 	struct rq *rq = cpu_rq(cpu);
 	unsigned long flags;
 
+	__sched_fork(0, idle);
+
 	raw_spin_lock_irqsave(&rq->lock, flags);
 
-	__sched_fork(0, idle);
 	idle->state = TASK_RUNNING;
 	idle->se.exec_start = sched_clock();
 

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

      parent reply	other threads:[~2014-06-03  9:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-05-08  2:03 mm,console: circular dependency between console_sem and zone lock Sasha Levin
2014-05-08  2:03 ` Sasha Levin
2014-05-12 16:28 ` Jan Kara
2014-05-12 16:28   ` Jan Kara
2014-06-01 14:08   ` Sasha Levin
2014-06-01 14:08     ` Sasha Levin
2014-06-03  1:55     ` Steven Rostedt
2014-06-03  1:55       ` Steven Rostedt
2014-06-03  8:47       ` Peter Zijlstra
2014-06-03  9:00     ` Peter Zijlstra [this message]

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=20140603090010.GP11096@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=akpm@linux-foundation.org \
    --cc=davej@redhat.com \
    --cc=jack@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mingo@kernel.org \
    --cc=rostedt@goodmis.org \
    --cc=sasha.levin@oracle.com \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.