Re: list corruption in next-20080903
From: Jens Axboe
Date: Thu Sep 04 2008 - 03:20:01 EST
On Wed, Sep 03 2008, Alexey Dobriyan wrote:
> Reproducible, happens during init scripts.
>
> ------------[ cut here ]------------
> WARNING: at lib/list_debug.c:30 __list_add+0x95/0xa0()
> list_add corruption. prev->next should be next (ffff88017fb70420), but was ffff88017fb70588. (prev=ffff88017fb70858).
> Modules linked in: xt_state iptable_filter ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack ip_tables xt_tcpudp ip6table_filter ip6_tables x_tables ipv6 nls_utf8 ntfs fuse sr_mod cdrom
> Pid: 4006, comm: bash Tainted: G W 2.6.27-rc5-next-20080903 #2
> Call Trace:
> [<ffffffff80232837>] warn_slowpath+0xb7/0xe0
> [<ffffffff8026ac31>] ? mempool_alloc_slab+0x11/0x20
> [<ffffffff8026ad8a>] ? mempool_alloc+0x4a/0x130
> [<ffffffff8028ec87>] ? kmem_cache_alloc+0x67/0xd0
> [<ffffffff80312bb0>] ? sg_init_table+0x20/0x80
> [<ffffffff80312c8c>] ? __sg_alloc_table+0x7c/0x140
> [<ffffffff80385801>] ? scsi_init_sgtable+0x51/0xb0
> [<ffffffff80385acf>] ? scsi_init_io+0x1f/0xd0
> [<ffffffff8038e3fc>] ? sd_prep_fn+0x5c/0x580
> [<ffffffff803145d5>] __list_add+0x95/0xa0
> [<ffffffff80301740>] blk_add_timer+0x50/0xd0
> [<ffffffff80386ce1>] scsi_request_fn+0xa1/0x380
> [<ffffffff802fd297>] __generic_unplug_device+0x27/0x30
> [<ffffffff802fda31>] ? generic_unplug_device+0x21/0x40
> [<ffffffff802fda39>] generic_unplug_device+0x29/0x40
> [<ffffffff802fb842>] blk_unplug+0x12/0x20
> [<ffffffff802fb85d>] blk_backing_dev_unplug+0xd/0x10
> [<ffffffff802b630e>] block_sync_page+0x3e/0x50
> [<ffffffff80267ff9>] sync_page+0x39/0x60
> [<ffffffff80269c29>] sync_page_killable+0x9/0x40
> [<ffffffff8042e61e>] __wait_on_bit_lock+0x4e/0x80
> [<ffffffff80269c20>] ? sync_page_killable+0x0/0x40
> [<ffffffff80267f35>] __lock_page_killable+0x65/0x70
> [<ffffffff802483a0>] ? wake_bit_function+0x0/0x30
> [<ffffffff8026a018>] generic_file_aio_read+0x3b8/0x660
> [<ffffffff802938b1>] do_sync_read+0xf1/0x130
> [<ffffffff80248360>] ? autoremove_wake_function+0x0/0x40
> [<ffffffff80256add>] ? trace_hardirqs_on+0xd/0x10
> [<ffffffff80430ef2>] ? _spin_unlock_irqrestore+0x42/0x80
> [<ffffffff80294017>] vfs_read+0xa7/0xe0
> [<ffffffff8029820a>] kernel_read+0x3a/0x60
> [<ffffffff8029831c>] prepare_binprm+0xec/0x120
> [<ffffffff80299467>] do_execve+0x197/0x280
> [<ffffffff80209b69>] sys_execve+0x49/0x80
> [<ffffffff8020bb2a>] stub_execve+0x6a/0xc0
> ---[ end trace 4eaa2a86a8e2da22 ]---
Thanks Alexey, I hit a problem with it yesterday as well. So it needs
more development before going into -next/-mm, I'll put it in a seperate
testing branch for now.
--
Jens Axboe
--
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/