Re: 2.6.17-rc5-mm1

[Ingo Molnar <mingo@elte.hu>]

* Martin J. Bligh <mbligh@mbligh.org> 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