linux-kernel - Re: debug rsdl 0.33

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: <200703260859.27272.kernel@kolivas.org>
Date:	Mon, 26 Mar 2007 08:59:26 +1000
From:	Con Kolivas <kernel@...ivas.org>
To:	"Torsten Kaiser" <just.for.lkml@...glemail.com>
Cc:	"Andy Whitcroft" <apw@...dowen.org>,
	"William Lee Irwin III" <wli@...omorphy.com>,
	"Andrew Morton" <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, "Steve Fox" <drfickle@...ibm.com>,
	"Martin J. Bligh" <mbligh@...igh.org>
Subject: Re: debug rsdl 0.33

On Monday 26 March 2007 08:49, Con Kolivas wrote:
> On Monday 26 March 2007 04:28, Torsten Kaiser wrote:
> > On 3/24/07, Con Kolivas <kernel@...ivas.org> wrote:
> > >  kernel/sched.c |   51
> > > +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51
> > > insertions(+)
> >
> > 2.6.21-rc4-mm1 also fails for me.
> >
> > I tried pure 2.6.21-rc4-mm1, +hotfixes, +hotfixes+rsdl33 and at last
> > also added above debug patch.
>
> Thank you very much for the effort!
>
> > The oops from with the debug-patch added:
> > [   65.426126] Freeing unused kernel memory: 312k freed
> > (on the console the system is starting up, getting until "Letting udev
> > process events ...")
> > [   66.665611] Unable to handle kernel NULL pointer dereference at
> > 0000000000000020 RIP:
> > [   66.682030]  [<ffffffff8026167c>] __sched_text_start+0x4dc/0xa0e
>
> The debug patch didn't do anything. This means it is not an unset bitmap
> problem at all otherwise it should have self corrected itself.
>
> > The system in x86_64, two 2218 on a MCP55 nvidia chipset.
> >
> > 2.6.21-rc3-mm1 works fine.
> >
> > (gdb) list *0xffffffff8026167c
> > 0xffffffff8026167c is in schedule (kernel/sched.c:3619).
>
> 	next = list_entry(queue->next, struct task_struct, run_list);
> 	rq->prio_level = idx;
>
> > 3614            /*
> > 3615             * When the task is chosen it is checked to see if its
> > quota has been
> > 3616             * added to this runqueue level which is only performed
> > once per 3617             * level per major rotation for each running
> > task. 3618             */
> > 3619            if (next->rotation != rq->prio_rotation) {
>
> Urgh. Dereferencing there? That can only be next that's deferencing meaning
> the run_list entry is bogus. That should only ever be done under runqueue
> lock so I have a race somewhere where it's not. Time for more looking.

This is about the only place I can see the run_list is looked at unlocked. Can
you see if this simple patch helps? The debug patch is unnecessary now.

Thanks!

--
Ensure checking task_queued() is only done under runqueue lock.

Signed-off-by: Con Kolivas <kernel@...ivas.org>

---
 kernel/sched.c |   10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

Index: linux-2.6.21-rc4-mm1/kernel/sched.c
===================================================================
--- linux-2.6.21-rc4-mm1.orig/kernel/sched.c	2007-03-26 08:54:15.000000000 +1000
+++ linux-2.6.21-rc4-mm1/kernel/sched.c	2007-03-26 08:55:21.000000000 +1000
@@ -3421,16 +3421,16 @@ static inline void rotate_runqueue_prior
 
 static void task_running_tick(struct rq *rq, struct task_struct *p, int tick)
 {
-	if (unlikely(!task_queued(p))) {
-		/* Task has expired but was not scheduled yet */
-		set_tsk_need_resched(p);
-		return;
-	}
 	/* SCHED_FIFO tasks never run out of timeslice. */
 	if (unlikely(p->policy == SCHED_FIFO))
 		return;
 
 	spin_lock(&rq->lock);
+	if (unlikely(!task_queued(p))) {
+		/* Task has expired but was not scheduled off yet */
+		set_tsk_need_resched(p);
+		goto out_unlock;
+	}
 	/*
 	 * Accounting is performed by both the task and the runqueue. This
 	 * allows frequently sleeping tasks to get their proper quota of


-- 
-ck
-
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/