linux-kernel - Re: [BUG] "sched: Remove rq->lock from the first half of ttwu()" locks up on ARM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1306430633.2497.91.camel@laptop>
Date:	Thu, 26 May 2011 19:23:53 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Marc Zyngier <Marc.Zyngier@....com>,
	Yong Zhang <yong.zhang0@...il.com>,
	Ingo Molnar <mingo@...e.hu>,
	Frank Rowand <frank.rowand@...sony.com>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org
Subject: Re: [BUG] "sched: Remove rq->lock from the first half of ttwu()"
 locks up on ARM

On Thu, 2011-05-26 at 19:17 +0200, Peter Zijlstra wrote:
> On Thu, 2011-05-26 at 19:04 +0200, Oleg Nesterov wrote:
> > On 05/26, Peter Zijlstra wrote:
> > >
> > > @@ -2636,7 +2636,8 @@ try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags)
> > >  		 * to spin on ->on_cpu if p is current, since that would
> > >  		 * deadlock.
> > >  		 */
> > > -		if (p == current) {
> > > +		if (cpu == smp_processor_id()) {
> > > +			p->sched_contributes_to_load = 0;
> > >  			ttwu_queue(p, cpu);
> > 
> > Btw. I do not pretend I really understand se->vruntime, but in this
> > case we are doing enqueue_task() without ->task_waking(), however we
> > pass ENQUEUE_WAKING. Is it correct?
> 
> No its not, that's the thing that I got wrong the first time and caused
> these pauses.

We'd end up with something like the below, which isn't too different
from what I've now got queued.

It has the extra cpu == smp_processor_id() check, but I'm not sure this
whole case is worth the trouble. I could go stick some counters in to
verify how often all this happens I guess.

---
 arch/x86/include/asm/system.h |    2 ++
 kernel/sched.c                |   14 +++++++++++---
 kernel/sched_debug.c          |    7 +++++++
 3 files changed, 20 insertions(+), 3 deletions(-)

diff --git a/arch/x86/include/asm/system.h b/arch/x86/include/asm/system.h
index c2ff2a1..2c597e8 100644
--- a/arch/x86/include/asm/system.h
+++ b/arch/x86/include/asm/system.h
@@ -10,6 +10,8 @@
 #include <linux/kernel.h>
 #include <linux/irqflags.h>
 
+#define __ARCH_WANT_INTERRUPTS_ON_CTXSW
+
 /* entries in ARCH_DLINFO: */
 #if defined(CONFIG_IA32_EMULATION) || !defined(CONFIG_X86_64)
 # define AT_VECTOR_SIZE_ARCH 2
diff --git a/kernel/sched.c b/kernel/sched.c
index 2d12893..e4f7a9f 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -2636,9 +2636,17 @@ try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags)
 		 * to spin on ->on_cpu if p is current, since that would
 		 * deadlock.
 		 */
-		if (p == current) {
-			ttwu_queue(p, cpu);
-			goto stat;
+		if (cpu == smp_processor_id()) {
+			struct rq *rq;
+
+			rq = __task_rq_lock(p);
+			if (p->on_cpu) {
+				ttwu_activate(rq, p, ENQUEUE_WAKEUP);
+				ttwu_do_wakeup(rq, p, wake_flags);
+				__task_rq_unlock(rq);
+				goto stat;
+			}
+			__task_rq_unlock(rq);
 		}
 #endif
 		cpu_relax();
diff --git a/kernel/sched_debug.c b/kernel/sched_debug.c
index a6710a1..f0ff1de 100644
--- a/kernel/sched_debug.c
+++ b/kernel/sched_debug.c
@@ -332,6 +332,13 @@ static int sched_debug_show(struct seq_file *m, void *v)
 		(int)strcspn(init_utsname()->version, " "),
 		init_utsname()->version);
 
+#ifdef __ARCH_WANT_INTERRUPTS_ON_CTXSW
+	SEQ_printf(m, "__ARCH_WANT_INTERRUPTS_ON_CTXSW\n");
+#endif
+#ifdef __ARCH_WANT_UNLOCKED_CTXSW
+	SEQ_printf(m, "__ARCH_WANT_UNLOCKED_CTXSW\n");                                  
+#endif
+
 #define P(x) \
 	SEQ_printf(m, "%-40s: %Ld\n", #x, (long long)(x))
 #define PN(x) \


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/