> On Fri, Jul 18, 2008 at 10:10 AM, Vegard Nossum <vegard.nossum@gmail.com> wrote:
> > On Fri, Jul 18, 2008 at 1:09 AM, Dave Kleikamp
> > <shaggy@linux.vnet.ibm.com> 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@linux.vnet.ibm.com>
> >
> > 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
