Re: latest -git: BUG at fs/jfs/namei.c:512 assert(ip->i_nlink)

["Vegard Nossum" <vegard.nossum@gmail.com>]

On Fri, Jul 18, 2008 at 10:29 AM, Vegard Nossum <vegard.nossum@gmail.com> wrote:
> BUG: unable to handle kernel paging request at c08845af
> IP: [<c02f9122>] release_metapage+0x32/0x1c0

Hi,

I am still unable to see the "already zero" message. I'll post this as
well because it looks completely different:

------------[ cut here ]------------
WARNING: at kernel/mutex.c:134 mutex_lock_nested+0x2d4/0x320()
Pid: 5335, comm: cp Not tainted 2.6.26-03415-gdf3030b #45
 [<c0135b6f>] warn_on_slowpath+0x4f/0xa0
 [<c015b6e9>] ? __lock_acquire+0x2c9/0x1110
 [<c015906b>] ? trace_hardirqs_off+0xb/0x10
 [<c015ab70>] ? mark_held_locks+0x40/0x80
 [<c015addb>] ? trace_hardirqs_on+0xb/0x10
 [<c015ad76>] ? trace_hardirqs_on_caller+0x116/0x170
 [<c0748da4>] mutex_lock_nested+0x2d4/0x320
 [<c02eb38b>] ? diAlloc+0x28b/0x680
 [<c02eb38b>] diAlloc+0x28b/0x680
 [<c074a6d7>] ? _spin_unlock+0x27/0x50
 [<c02f7bc9>] ialloc+0x49/0x320
 [<c02dffa7>] jfs_mkdir+0x77/0x3c0
 [<c015906b>] ? trace_hardirqs_off+0xb/0x10
 [<c015addb>] ? trace_hardirqs_on+0xb/0x10
 [<c015906b>] ? trace_hardirqs_off+0xb/0x10
 [<c03030b0>] ? jfs_permission+0x0/0x10
 [<c02dff30>] ? jfs_mkdir+0x0/0x3c0
 [<c01acb27>] vfs_mkdir+0xb7/0x130
 [<c074a6d7>] ? _spin_unlock+0x27/0x50
 [<c01af4b8>] sys_mkdirat+0xe8/0x100
 [<c0430948>] ? trace_hardirqs_on_thunk+0xc/0x10
 [<c0120140>] ? do_page_fault+0x0/0x880
 [<c01af4f0>] sys_mkdir+0x20/0x30
 [<c010407f>] sysenter_past_esp+0x78/0xc5
 =======================
---[ end trace 010115e08457f5d6 ]---
BUG: unable to handle kernel paging request at fff7f7f7
IP: [<c04401b0>] __list_add+0x10/0x70
*pde = 00007067 *pte = 00000000
Oops: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC
Pid: 5335, comm: cp Tainted: G        W (2.6.26-03415-gdf3030b #45)
EIP: 0060:[<c04401b0>] EFLAGS: 00210046 CPU: 1
EIP is at __list_add+0x10/0x70
EAX: fff7f7f7 EBX: e5b77d88 ECX: e5f68a70 EDX: fff7f7f7
ESI: e5f68a50 EDI: 00200246 EBP: e5b77d60 ESP: e5b77d4c
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process cp (pid: 5335, ti=e5b76000 task=f69acfb0 task.ti=e5b76000)
Stack: c02eb38b e5f68a84 e5f68a4c e5f68a50 e5f68a4c e5b77da8 c0748baa 00000000
       00000002 c02eb38b c02eb38b 00000000 f69acfb0 e5f68a70 e5f68a84 e5b77d88
       e5b77d88 11111111 e5f68a4c e5b77d88 de0a9d8c de0a82d4 de0a9d8c e5b77e0c
Call Trace:
 [<c02eb38b>] ? diAlloc+0x28b/0x680
 [<c0748baa>] ? mutex_lock_nested+0xda/0x320
 [<c02eb38b>] ? diAlloc+0x28b/0x680
 [<c02eb38b>] ? diAlloc+0x28b/0x680
 [<c02eb38b>] ? diAlloc+0x28b/0x680
 [<c074a6d7>] ? _spin_unlock+0x27/0x50
 [<c02f7bc9>] ? ialloc+0x49/0x320
 [<c02dffa7>] ? jfs_mkdir+0x77/0x3c0
 [<c015906b>] ? trace_hardirqs_off+0xb/0x10
 [<c015addb>] ? trace_hardirqs_on+0xb/0x10
 [<c015906b>] ? trace_hardirqs_off+0xb/0x10
 [<c03030b0>] ? jfs_permission+0x0/0x10
 [<c02dff30>] ? jfs_mkdir+0x0/0x3c0
 [<c01acb27>] ? vfs_mkdir+0xb7/0x130
 [<c074a6d7>] ? _spin_unlock+0x27/0x50
 [<c01af4b8>] ? sys_mkdirat+0xe8/0x100
 [<c0430948>] ? trace_hardirqs_on_thunk+0xc/0x10
 [<c0120140>] ? do_page_fault+0x0/0x880
 [<c01af4f0>] ? sys_mkdir+0x20/0x30
 [<c010407f>] ? sysenter_past_esp+0x78/0xc5
 =======================
Code: 54 24 04 c7 04 24 80 59 88 c0 e8 20 bf 30 00 0f 0b eb fe 90 8d
b4 26 00 00 00 00 55 89 e5 53 89 c3 83 ec 10 8b 41 04 39 d0 75 16 <8b>
10 39 ca 75 32 89 5a 04 89 13 89 43 04 89 18 83 c4 10 5b 5d
EIP: [<c04401b0>] __list_add+0x10/0x70 SS:ESP 0068:e5b77d4c
Kernel panic - not syncing: Fatal exception

(Followed by similar smp_call_function warnings as before.)

But I think I'll stop testing now until we have another patch.


Vegard

-- 
"The animistic metaphor of the bug that maliciously sneaked in while
the programmer was not looking is intellectually dishonest as it
disguises that the error is the programmer's own creation."
	-- E. W. Dijkstra, EWD1036