Re: latest -git: BUG at fs/jfs/namei.c:512 assert(ip->i_nlink)
From: Dave Kleikamp
Date: Fri Jul 18 2008 - 13:29:34 EST
On Fri, 2008-07-18 at 10:29 +0200, Vegard Nossum wrote:
> On Fri, Jul 18, 2008 at 10:10 AM, Vegard Nossum <vegard.nossum@xxxxxxxxx> wrote:
> > On Fri, Jul 18, 2008 at 1:09 AM, Dave Kleikamp
> > <shaggy@xxxxxxxxxxxxxxxxxx> wrote:
> >> On Thu, 2008-07-17 at 20:35 +0200, Vegard Nossum wrote:
> >>> Hi,
> >>>
> >>> I got this on latest -git with an intentionally corrupted filesystem image:
> >>>
> >>> BUG at fs/jfs/namei.c:512 assert(ip->i_nlink)
> >>
> >> This assert shouldn't be here. It would be better to handle this with
> >> jfs_error(), which will mark the superblock dirty, and take appropriate
> >> action.
> >>
> >>> Full log at http://folk.uio.no/vegardno/linux/log-1216318656.txt, but
> >>> I think the preceding messages are just left-overs from previous
> >>> mount/remount attempts. I can test patches.
> >>
> >> How about this one? So far, compile tested only.
> >>
> >> JFS: The kernel shouldn't trap when deleting a file with nlink == 0.
> >>
> >> Signed-off-by: Dave Kleikamp <shaggy@xxxxxxxxxxxxxxxxxx>
> >
> > Thanks!
> >
> > But whether it truly helped or not, I don't know. I got something different now:
> >
> > jfs_unlink: dtDelete returned -116
> > jfs_unlink: dtDelete returned -116
> > ------------[ cut here ]------------
> > kernel BUG at fs/inode.c:262!
>
> Running the test for some more on a freshly booted system also gives
> me this after a while (I don't know if it's related, but it might give
> some additional clues?):
>
> BUG: unable to handle kernel paging request at c08845af
> IP: [<c02f9122>] release_metapage+0x32/0x1c0
> *pde = 37ab2163 *pte = 00884161
> Oops: 0003 [#1] PREEMPT SMP DEBUG_PAGEALLOC
> Pid: 387, comm: jfsCommit Not tainted (2.6.26-03415-gdf3030b #45)
> EIP: 0060:[<c02f9122>] EFLAGS: 00010202 CPU: 1
> EIP is at release_metapage+0x32/0x1c0
> EAX: 00000246 EBX: f470e5d8 ECX: f7a2afd0 EDX: 00000000
> ESI: c08845af EDI: 00000000 EBP: f735fd98 ESP: f735fd7c
> DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
> Process jfsCommit (pid: 387, ti=f735e000 task=f7a2afd0 task.ti=f735e000)
> Stack: c015b6e9 00000001 00000286 00000246 00000002 00000000 00000000 f735fed0
> c02e4202 00000020 f7a2afd0 c015addb 00000000 f470e9a4 f735fe34 00000000
> 00000000 f470e85c c015addb 00000000 00000000 f470e5d8 f470e6d8 00000002
> Call Trace:
> [<c015b6e9>] ? __lock_acquire+0x2c9/0x1110
> [<c02e4202>] ? xtTruncate+0xd42/0x1060
xtTruncate can call release_metapage() in several places. If you still
have this kernel, could you please run addr2line against c02e4202? If
you've rebuilt your kernel since then, I understand.
Thanks,
Shaggy
--
David Kleikamp
IBM Linux Technology Center
--
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/