From: Peter Zijlstra <peterz@infradead.org>
To: michal.simek@petalogix.com
Cc: Russell King - ARM Linux <linux@arm.linux.org.uk>,
Ingo Molnar <mingo@elte.hu>,
Catalin Marinas <catalin.marinas@arm.com>,
Marc Zyngier <Marc.Zyngier@arm.com>,
Frank Rowand <frank.rowand@am.sony.com>,
Oleg Nesterov <oleg@redhat.com>,
linux-kernel@vger.kernel.org, Yong Zhang <yong.zhang0@gmail.com>,
linux-arm-kernel@lists.infradead.org,
Michal Simek <monstr@monstr.eu>
Subject: Re: [BUG] "sched: Remove rq->lock from the first half of ttwu()" locks up on ARM
Date: Tue, 31 May 2011 15:22:17 +0200 [thread overview]
Message-ID: <1306848137.2353.91.camel@twins> (raw)
In-Reply-To: <4DE4CC33.7090404@petalogix.com>
On Tue, 2011-05-31 at 13:08 +0200, Michal Simek wrote:
>
> please correct me if I am wrong but this is workaround just for ARM.
> I am not aware that we need to do anything with caches. I enabled that options
> after our discussion (http://lkml.org/lkml/2009/12/3/204) because of problems
> with lockdep. I will look if I can remove that option but it will be necessary
> to do some changes in code. switch_to should be called with irq OFF right?
Hmm, so the problem was that interrupts got enabled on microblaze (or
lockdep thought they were), so we need to figure out why that is so
instead of ensuring that it is so.
/me goes poke about in the microblaze code..
So on fork() the child ip gets set to ret_from_fork(), then when we wake
the child we'll eventually schedule to it. So we get a context switch
like X -> child.
Then X calls schedule()->context_switch()->switch_to() which will
continue at ret_from_fork()->schedule_tail()->finish_task_switch()->
finish_lock_switch()->spin_acquire(&rq->lock.depmap..)
Now the lockdep report says that at that point interrupts were enabled,
and I can't quite see how that would happen, we go into switch_to() with
interrupts disabled (assuming !__ARCH_WANT_INTERRUPTS_ON_CTXSW), so the
whole ret_from_fork()->... path should run with interrupts disabled as
well.
I can't find where it would have enabled IRQs. Maybe the current
microblaze code doesn't suffer this, or I simply missed it in the
entry.S magic -- its not like I can actually read microblaze asm well.
Does it still explode like back then, if so, can you see where it
enables IRQs?
WARNING: multiple messages have this Message-ID (diff)
From: peterz@infradead.org (Peter Zijlstra)
To: linux-arm-kernel@lists.infradead.org
Subject: [BUG] "sched: Remove rq->lock from the first half of ttwu()" locks up on ARM
Date: Tue, 31 May 2011 15:22:17 +0200 [thread overview]
Message-ID: <1306848137.2353.91.camel@twins> (raw)
In-Reply-To: <4DE4CC33.7090404@petalogix.com>
On Tue, 2011-05-31 at 13:08 +0200, Michal Simek wrote:
>
> please correct me if I am wrong but this is workaround just for ARM.
> I am not aware that we need to do anything with caches. I enabled that options
> after our discussion (http://lkml.org/lkml/2009/12/3/204) because of problems
> with lockdep. I will look if I can remove that option but it will be necessary
> to do some changes in code. switch_to should be called with irq OFF right?
Hmm, so the problem was that interrupts got enabled on microblaze (or
lockdep thought they were), so we need to figure out why that is so
instead of ensuring that it is so.
/me goes poke about in the microblaze code..
So on fork() the child ip gets set to ret_from_fork(), then when we wake
the child we'll eventually schedule to it. So we get a context switch
like X -> child.
Then X calls schedule()->context_switch()->switch_to() which will
continue at ret_from_fork()->schedule_tail()->finish_task_switch()->
finish_lock_switch()->spin_acquire(&rq->lock.depmap..)
Now the lockdep report says that at that point interrupts were enabled,
and I can't quite see how that would happen, we go into switch_to() with
interrupts disabled (assuming !__ARCH_WANT_INTERRUPTS_ON_CTXSW), so the
whole ret_from_fork()->... path should run with interrupts disabled as
well.
I can't find where it would have enabled IRQs. Maybe the current
microblaze code doesn't suffer this, or I simply missed it in the
entry.S magic -- its not like I can actually read microblaze asm well.
Does it still explode like back then, if so, can you see where it
enables IRQs?
next prev parent reply other threads:[~2011-05-31 13:22 UTC|newest]
Thread overview: 102+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-24 18:13 [BUG] "sched: Remove rq->lock from the first half of ttwu()" locks up on ARM Marc Zyngier
2011-05-24 18:13 ` Marc Zyngier
2011-05-24 21:32 ` Peter Zijlstra
2011-05-24 21:32 ` Peter Zijlstra
2011-05-24 21:39 ` Ingo Molnar
2011-05-24 21:39 ` Ingo Molnar
2011-05-25 12:23 ` Marc Zyngier
2011-05-25 12:23 ` Marc Zyngier
2011-05-25 17:08 ` Peter Zijlstra
2011-05-25 17:08 ` Peter Zijlstra
2011-05-25 21:15 ` Peter Zijlstra
2011-05-25 21:15 ` Peter Zijlstra
2011-05-26 7:29 ` Yong Zhang
2011-05-26 7:29 ` Yong Zhang
2011-05-26 10:32 ` Peter Zijlstra
2011-05-26 10:32 ` Peter Zijlstra
2011-05-26 11:02 ` Marc Zyngier
2011-05-26 11:02 ` Marc Zyngier
2011-05-26 11:32 ` Peter Zijlstra
2011-05-26 11:32 ` Peter Zijlstra
2011-05-26 12:21 ` Peter Zijlstra
2011-05-26 12:21 ` Peter Zijlstra
2011-05-26 12:26 ` Ingo Molnar
2011-05-26 12:26 ` Ingo Molnar
2011-05-26 12:31 ` Russell King - ARM Linux
2011-05-26 12:31 ` Russell King - ARM Linux
2011-05-26 12:37 ` Peter Zijlstra
2011-05-26 12:37 ` Peter Zijlstra
2011-05-26 12:50 ` Ingo Molnar
2011-05-26 12:50 ` Ingo Molnar
2011-05-26 13:36 ` Russell King - ARM Linux
2011-05-26 13:36 ` Russell King - ARM Linux
2011-05-26 14:45 ` Catalin Marinas
2011-05-26 14:45 ` Catalin Marinas
2011-05-27 12:06 ` Ingo Molnar
2011-05-27 12:06 ` Ingo Molnar
2011-05-27 17:55 ` Russell King - ARM Linux
2011-05-27 17:55 ` Russell King - ARM Linux
2011-05-27 19:41 ` Nicolas Pitre
2011-05-27 19:41 ` Nicolas Pitre
2011-05-27 20:52 ` Russell King - ARM Linux
2011-05-27 20:52 ` Russell King - ARM Linux
2011-05-28 13:13 ` Peter Zijlstra
2011-05-28 13:13 ` Peter Zijlstra
2011-05-31 11:08 ` Michal Simek
2011-05-31 11:08 ` Michal Simek
2011-05-31 13:22 ` Peter Zijlstra [this message]
2011-05-31 13:22 ` Peter Zijlstra
2011-05-31 13:37 ` Michal Simek
2011-05-31 13:37 ` Michal Simek
2011-05-31 13:52 ` Peter Zijlstra
2011-05-31 13:52 ` Peter Zijlstra
2011-05-31 14:08 ` Michal Simek
2011-05-31 14:08 ` Michal Simek
2011-05-31 14:29 ` Peter Zijlstra
2011-05-31 14:29 ` Peter Zijlstra
2011-05-29 10:21 ` Catalin Marinas
2011-05-29 10:21 ` Catalin Marinas
2011-05-29 10:26 ` Russell King - ARM Linux
2011-05-29 10:26 ` Russell King - ARM Linux
2011-05-29 12:01 ` Catalin Marinas
2011-05-29 12:01 ` Catalin Marinas
2011-05-29 13:19 ` Russell King - ARM Linux
2011-05-29 13:19 ` Russell King - ARM Linux
2011-05-29 21:21 ` Catalin Marinas
2011-05-29 21:21 ` Catalin Marinas
2011-05-29 9:51 ` Catalin Marinas
2011-05-29 9:51 ` Catalin Marinas
2011-06-06 10:29 ` Pavel Machek
2011-06-06 10:29 ` Pavel Machek
2011-05-26 14:56 ` Marc Zyngier
2011-05-26 14:56 ` Marc Zyngier
2011-05-26 15:45 ` Oleg Nesterov
2011-05-26 15:45 ` Oleg Nesterov
2011-05-26 15:59 ` Peter Zijlstra
2011-05-26 15:59 ` Peter Zijlstra
2011-05-26 16:09 ` Peter Zijlstra
2011-05-26 16:09 ` Peter Zijlstra
2011-05-26 16:20 ` Marc Zyngier
2011-05-26 16:20 ` Marc Zyngier
2011-05-26 16:32 ` Peter Zijlstra
2011-05-26 16:32 ` Peter Zijlstra
2011-05-27 8:01 ` Marc Zyngier
2011-05-27 8:01 ` Marc Zyngier
2011-05-26 16:22 ` Marc Zyngier
2011-05-26 16:22 ` Marc Zyngier
2011-05-26 17:04 ` Oleg Nesterov
2011-05-26 17:04 ` Oleg Nesterov
2011-05-26 17:17 ` Peter Zijlstra
2011-05-26 17:17 ` Peter Zijlstra
2011-05-26 17:23 ` Peter Zijlstra
2011-05-26 17:23 ` Peter Zijlstra
2011-05-26 17:49 ` Oleg Nesterov
2011-05-26 17:49 ` Oleg Nesterov
2011-05-27 7:01 ` Yong Zhang
2011-05-27 7:01 ` Yong Zhang
2011-05-27 15:23 ` Santosh Shilimkar
2011-05-27 15:23 ` Santosh Shilimkar
2011-05-27 15:29 ` Marc Zyngier
2011-05-27 15:29 ` Marc Zyngier
2011-05-27 15:30 ` Santosh Shilimkar
2011-05-27 15:30 ` Santosh Shilimkar
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=1306848137.2353.91.camel@twins \
--to=peterz@infradead.org \
--cc=Marc.Zyngier@arm.com \
--cc=catalin.marinas@arm.com \
--cc=frank.rowand@am.sony.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@arm.linux.org.uk \
--cc=michal.simek@petalogix.com \
--cc=mingo@elte.hu \
--cc=monstr@monstr.eu \
--cc=oleg@redhat.com \
--cc=yong.zhang0@gmail.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.