Re: XFS or Kernel Problem / Bug

[Stefan Priebe - FH <studium@profihost.com>]

Hi!

I do everything you like :-) if we can find the bug.

So here are the files (2.6.18.6):
http://server055.de-nserver.de/filemap.o
http://server055.de-nserver.de/filemap.s

Stefan


Chuck Ebbert schrieb:
> Stefan Priebe - FH wrote:
>
> > I've 3 Servers which works wonderful with 2.6.16.X (also testet the
> > latest 2.6.16.37)
> >
> > but with 2.6.18.6 i get these errors:
> >
> > "general protection fault: 0000 [#1]"
> > "Modules linked in:"
> > "CPU:    0"
> > "EIP:    0060:[<c01c8fd2>]    Not tainted VLI"
> > "EFLAGS: 00010246   (2.6.18.6 #1) "
> > "EIP is at xfs_bmap_add_extent_hole_delay+0x58d/0x59b"
> > "eax: 00000000   ebx: fffe0007   ecx: 0071a4cd   edx: 00000000"
> > "esi: 00000000   edi: 00000000   ebp: 00000015   esp: ce35f8f0"
> > "ds: 0000   es: 007b   ss: 0068"
> > "Process mysqld (pid: 1836, ti=ce35e000 task=ee618550 task.ti=ce35e000)"
> > "Stack: 00000232 00000000 00000233 00000000 00000000 00000000 0000000c
> > 00000000 "
> > "       00000007 00000000 eca90250 eca90278 00000001 eca90200 00000000
> > 000003c3 "
> > "       00000000 010003c3 ffffffc0 ce35fa58 ce35fa58 00000001 00000000
> > 00000000 "
> > "Call Trace:"
> > " [<c01b6c58>] xfs_trans_dqresv+0x3f9/0x405"
> > " [<c01c6485>] xfs_bmap_add_extent+0x163/0x377"
> > " [<c01cd2c3>] xfs_bmapi+0xa4e/0x1109"
> > " [<c01ebbe3>] xfs_iomap_write_delay+0x233/0x2fa"
> > " [<c01eaa31>] xfs_imap_to_bmap+0x29/0x1d6"
> > " [<c01eae1a>] xfs_iomap+0x23c/0x3e1"
> > " [<c01eaebe>] xfs_iomap+0x2e0/0x3e1"
> > " [<c020a71a>] xfs_bmap+0x1a/0x1e"
> > " [<c020471e>] __xfs_get_blocks+0x5d/0x195"
>
> Without the "Code:" line it's hard to tell what happened...
>
> > and sometimes this one:
> >
> > "BUG: unable to handle kernel NULL pointer dereference at virtual
> > address 00000288"
> > " printing eip:"
> > "c0142ff7"
> > "*pde = 00000000"
> > "Oops: 0000 [#1]"
> > "SMP "
> > "Modules linked in: iptable_filter ip_tables x_tables"
> > "CPU:    0"
> > "EIP:    0060:[<c0142ff7>]    Not tainted VLI"
> > "EFLAGS: 00010246   (2.6.18.6 #1) "
> > "EIP is at generic_file_buffered_write+0x390/0x6cf"
> > "eax: 00000000   ebx: 000001ec   ecx: ea029a40   edx: 00008002"
> > "esi: 00000000   edi: e3b28c9c   ebp: 000001ec   esp: dd04bd18"
> > "ds: 007b   es: 007b   ss: 0068"
> > "Process proftpd (pid: 3615, ti=dd04a000 task=eba88a70 task.ti=dd04a000)"
> > "Stack: e3b28d44 00000001 00000010 000001fc c036d793 000001fc c14765c0
> > 00000010 "
> > "       080d404c 000001ec e3b28c9c c03e78c0 e3b28d44 ea029a40 000001fc
> > 00000000 "
> > "       00000000 000001ec dd04beac 00d420b1 00000000 00000000 dd04bd80
> > 45b1fa67 "
> > "Call Trace:"
> > " [<c036d793>] sock_def_readable+0x7f/0x81"
> > " [<c017a03a>] file_update_time+0xad/0xcb"
> > " [<c0232015>] xfs_iunlock+0x55/0x9f"
> > " [<c0262eeb>] xfs_write+0xa74/0xc61"
> > " [<c036a253>] sock_aio_read+0x95/0x99"
> > " [<c025d9fb>] xfs_file_aio_write+0x8f/0xa0"
> > " [<c015fb94>] do_sync_write+0xc9/0x10f"
> > " [<c0133ad6>] autoremove_wake_function+0x0/0x57"
> > " [<c015f3d5>] generic_file_llseek+0x95/0xbc"
> > " [<c015facb>] do_sync_write+0x0/0x10f"
> > " [<c015fc80>] vfs_write+0xa6/0x179"
> > " [<c015fe24>] sys_write+0x51/0x80"
> > " [<c0102d3f>] syscall_call+0x7/0xb"
> >
> > "Code: 04 89 10 8b 44 24 40 85 c0 0f 85 db 00 00 00 8b 5c 24 24 85 db 0f
> > 88 c3 00 00 00 8b 4c 24 34 8b 51 18 f6 c6 10 75 73 8b 7c 24 28 <8b> 85
> > 9c 00 00 00 f6 40 30 10 75 63 f6 87 48 01 00 00 01 75 5a "
> >
> > "EIP: [<c0142ff7>] generic_file_buffered_write+0x390/0x6cf SS:ESP
> > 0068:dd04bd18"
>
> Well that's strange. It's here in mm/filemap.c line 2201:
>
>         /*
>          * For now, when the user asks for O_SYNC, we'll actually give
> O_DSYNC
>          */
>         if (likely(status >= 0)) {
>                 if (unlikely((file->f_flags & O_SYNC) ||
> IS_SYNC(inode))) { <===
>                         if (!a_ops->writepage || !is_sync_kiocb(iocb))
>                                 status = generic_osync_inode(inode, mapping,
>                                                 OSYNC_METADATA|OSYNC_DATA);
>                 }
>         }
>
> ebp holds the value of 'inode' and it's obviously wrong (it's also the same
> as 'written', which is in ebx.) So when it tries to read inode->i_sb, it
> dies.
>
> If you can, post the file mm/filemap.o from your build directory to some
> website.
> And do 'make mm/filemap.s' and post that file too.

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