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 for Android: free password hash cracker in your pocket

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

Date:	Mon, 26 Mar 2007 08:49:07 +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 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.

> Torsten

Thanks!

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