Re: 2.6.17-rc5-mm1

From: Ingo Molnar
Date: Thu Jun 01 2006 - 03:09:16 EST



* Martin J. Bligh <mbligh@xxxxxxxxxx> wrote:

> >>>EIP is at check_deadlock+0x15/0xe0

i took your config and ran a few tests. Your kernel crashed here:

BUG: unable to handle kernel paging request at virtual address 22222232
CPU: 1
EIP: 0060:[<c012b6eb>] Not tainted VLI
EFLAGS: 00010002 (2.6.17-rc5-mm1-autokern1 #1)
EIP is at check_deadlock+0x15/0xe0
eax: 22222222 ebx: 00000001 ecx: d4996000 edx: 00000001
esi: d686f550 edi: 22222222 ebp: 22222222 esp: d5bdfec8
ds: 007b es: 007b ss: 0068
Process mkdir09 (pid: 18867, threadinfo=d5bdf000 task=d5c0e000)
Stack: 00000000 d686f550 d3960568 22222222 c012b77b d3960568 d5bdf000 d5bdff00
d5c0e000 c012b922 d5bdff48 d3960568 00000246 c02d50de d5bdff00 d5bdff00
11111111 11111111 d5bdff00 ffffff9c d5bdff48 00000000 d5bdff48 ffffffef

which is:

(gdb) list *0xc012a26e
0xc012a26e is in check_deadlock (kernel/mutex-debug.c:98).
93 struct task_struct *task;
94
95 if (!debug_locks)
96 return 0;
97
98 ti = lock->owner;
99 if (!ti)
100 return 0;
101
102 task = ti->task;
(gdb)

i.e. "lock" was 0x22222222. I have not changed this particular deadlock
detection code for some time and it's been stable for many weeks. (the
changes in -mm1 were in another area of mutex-debug.c, and even those
mostly removed code and didnt add new logic)

the stack looks weird:

Stack: 00000000 d686f550 d3960568 22222222 c012b77b d3960568 d5bdf000 d5bdff00
d5c0e000 c012b922 d5bdff48 d3960568 00000246 c02d50de d5bdff00 d5bdff00
11111111 11111111 d5bdff00 ffffff9c d5bdff48 00000000 d5bdff48 ffffffef

where does the 0x11111111 and the 0x22222222 come from? It doesnt ring
any bells in terms of kernel-internal magic or poison values. My
impression is that there's some other badness going on (some sort of
memory corruption) and the mutex debugging code just got caught up in
the crossfire.

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