linux-kernel - Re: [BUG] 2.6.23-git8 kernel oops at __rb_rotate

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20071017150056.GA28135@linux.vnet.ibm.com>
Date:	Wed, 17 Oct 2007 20:30:56 +0530
From:	Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Kamalesh Babulal <kamalesh@...ux.vnet.ibm.com>,
	LKML <linux-kernel@...r.kernel.org>,
	torvalds@...ux-foundation.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andy Whitcroft <apw@...dowen.org>,
	Dmitry Adamushko <dmitry.adamushko@...il.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Srivatsa Vaddagiri <vatsa@...ibm.com>,
	Mike Galbraith <efault@....de>,
	Dhaval Giani <dhaval@...ux.vnet.ibm.com>
Subject: Re: [BUG] 2.6.23-git8 kernel oops at __rb_rotate_left+0x7/0x70

On Wed, Oct 17, 2007 at 04:21:40PM +0200, Ingo Molnar wrote:
> * Kamalesh Babulal <kamalesh@...ux.vnet.ibm.com> wrote:
> 
> > While running kernbench with the 2.6.23-git8 following oops is 
> > produced
> 
> Dmitry found something that might explain the crash: could you check 
> whether the patch below fixes it?

> this should fix the put_prev_task crashes that were reported,
> Dmitry Adamushko noticed that it's not valid to call into
> task_new_fair() if this_cpu != task_cpu(p).

I don't see a fundamental reason why it would be invalid to call
task_new_fair() when this_cpu != task_cpu(p). Besides, calling 
activate_task->enqueue_task->enqueue_task_fair() on a new born task (as
is being done in the patch you have sent) is slightly buggy in the sense that 
its p->se.vruntime is not properly calculated (because we set wakeup argument 
as 0).

We (myself, Kamalesh and Dhaval) have tested the patch below, w/o being
able to recreate the problem. The patch allows for task_new_fair() to be
called even for the case when child is being added to another cpu's
runqueue.

--

Child task may be added on a different cpu that the one on which parent
is running. In which case, task_new_fair() should check whether the new
born task's parent entity should be added as well on the cfs_rq.

Patch below fixes the problem in task_new_fair.

Signed-off-by : Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>


---
 kernel/sched.c      |    2 +-
 kernel/sched_fair.c |    6 +-----
 2 files changed, 2 insertions(+), 6 deletions(-)

Index: current/kernel/sched.c
===================================================================
--- current.orig/kernel/sched.c
+++ current/kernel/sched.c
@@ -1712,7 +1712,7 @@ void fastcall wake_up_new_task(struct ta
 
 	p->prio = effective_prio(p);
 
-	if (!p->sched_class->task_new || !current->se.on_rq || !rq->cfs.curr) {
+	if (!p->sched_class->task_new || !current->se.on_rq) {
 		activate_task(rq, p, 0);
 	} else {
 		/*
Index: current/kernel/sched_fair.c
===================================================================
--- current.orig/kernel/sched_fair.c
+++ current/kernel/sched_fair.c
@@ -1031,12 +1031,8 @@ static void task_new_fair(struct rq *rq,
 		swap(curr->vruntime, se->vruntime);
 	}
 
-	update_stats_enqueue(cfs_rq, se);
-	check_spread(cfs_rq, se);
-	check_spread(cfs_rq, curr);
-	__enqueue_entity(cfs_rq, se);
-	account_entity_enqueue(cfs_rq, se);
 	se->peer_preempt = 0;
+	enqueue_task_fair(rq, p, 0);
 	resched_task(rq->curr);
 }
 
-- 
Regards,
vatsa
-
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/