2009-06-23 15:54:49

by Andrew Randrianasulu

[permalink] [raw]
Subject: list_add corruption in current Linus's tree?


Hello!

I'm currently using vanilla kernel form kernel.org, up to commit d888a4c76c51092993643f8992bf55b3c28da483. Since yesterday i saw many warnings like this in dmesg:

------------[ cut here ]------------
WARNING: at lib/list_debug.c:26 __list_add+0x27/0x5c()
Hardware name: MS-6380E
list_add corruption. next->prev should be prev (cf801454), but was c22302fc. (next=c2282c28).
Modules linked in: radeon ttm drm i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect sg snd_seq_dummy snd_seq_oss sd_mod snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss ipv6 nfsd lockd nfs_acl auth_rpcgss sunrpc usb_storage scsi_mod usb_libusual tuner_simple tuner_types ppdev tda9887 tda8290 snd_cs4236 snd_mpu401 snd_emu10k1 snd_via82xx snd_wavefront snd_ac97_codec snd_wss_lib ac97_bus snd_opl3_lib uhci_hcd saa7134 snd_mpu401_uart snd_pcm ir_common snd_rawmidi snd_timer snd_page_alloc ehci_hcd snd_util_mem videobuf_dma_sg snd_seq_device snd_hwdep videobuf_core snd parport_pc tveeprom usbcore rtc_cmos rtc_core emu10k1_gp ns558 soundcore parport floppy gameport rtc_lib shpchp 8139too pci_hotplug via_agp xfs exportfs ufs agpgart tuner v4l2_common videodev v4l1_compat w83627hf hwmon_vid hwmon i2c_viapro i2c_dev fbcon tileblit font bitblit softcursor fb
Pid: 4000, comm: X Tainted: G W 2.6.30-i486 #17
Call Trace:
[<c1033bd6>] warn_slowpath_common+0x65/0x95
[<c1033c44>] warn_slowpath_fmt+0x29/0x2c
[<c1156ebf>] __list_add+0x27/0x5c
[<c10b9381>] mem_cgroup_add_lru_list+0x43/0x55
[<c10975b4>] add_page_to_lru_list+0x3d/0x42
[<c10978a1>] ____pagevec_lru_add+0xea/0x12c
[<c1097be4>] lru_add_drain+0x3c/0x86
[<c10a68a3>] unmap_region+0x34/0x10d
[<c10a7629>] do_munmap+0x1df/0x235
[<c10a76b4>] sys_munmap+0x35/0x44
[<c1002bc5>] syscall_call+0x7/0xb
---[ end trace fda7f44fa2651cfc ]---

but many, many more. Should i create bug in kernel bugzilla, or it is known issue?



2009-06-23 16:11:52

by Daisuke Nishimura

[permalink] [raw]
Subject: Re: list_add corruption in current Linus's tree?

On Tue, 23 Jun 2009 08:48:04 -0700 (PDT)
Andrew Randrianasulu <[email protected]> wrote:

>
> Hello!
>
> I'm currently using vanilla kernel form kernel.org, up to commit d888a4c76c51092993643f8992bf55b3c28da483. Since yesterday i saw many warnings like this in dmesg:
>
> ------------[ cut here ]------------
> WARNING: at lib/list_debug.c:26 __list_add+0x27/0x5c()
> Hardware name: MS-6380E
> list_add corruption. next->prev should be prev (cf801454), but was c22302fc. (next=c2282c28).
> Modules linked in: radeon ttm drm i2c_algo_bit cfbcopyarea cfbimgblt cfbfillrect sg snd_seq_dummy snd_seq_oss sd_mod snd_seq_midi_event snd_seq snd_pcm_oss snd_mixer_oss ipv6 nfsd lockd nfs_acl auth_rpcgss sunrpc usb_storage scsi_mod usb_libusual tuner_simple tuner_types ppdev tda9887 tda8290 snd_cs4236 snd_mpu401 snd_emu10k1 snd_via82xx snd_wavefront snd_ac97_codec snd_wss_lib ac97_bus snd_opl3_lib uhci_hcd saa7134 snd_mpu401_uart snd_pcm ir_common snd_rawmidi snd_timer snd_page_alloc ehci_hcd snd_util_mem videobuf_dma_sg snd_seq_device snd_hwdep videobuf_core snd parport_pc tveeprom usbcore rtc_cmos rtc_core emu10k1_gp ns558 soundcore parport floppy gameport rtc_lib shpchp 8139too pci_hotplug via_agp xfs exportfs ufs agpgart tuner v4l2_common videodev v4l1_compat w83627hf hwmon_vid hwmon i2c_viapro i2c_dev fbcon tileblit font bitblit softcursor fb
> Pid: 4000, comm: X Tainted: G W 2.6.30-i486 #17
> Call Trace:
> [<c1033bd6>] warn_slowpath_common+0x65/0x95
> [<c1033c44>] warn_slowpath_fmt+0x29/0x2c
> [<c1156ebf>] __list_add+0x27/0x5c
> [<c10b9381>] mem_cgroup_add_lru_list+0x43/0x55
> [<c10975b4>] add_page_to_lru_list+0x3d/0x42
> [<c10978a1>] ____pagevec_lru_add+0xea/0x12c
> [<c1097be4>] lru_add_drain+0x3c/0x86
> [<c10a68a3>] unmap_region+0x34/0x10d
> [<c10a7629>] do_munmap+0x1df/0x235
> [<c10a76b4>] sys_munmap+0x35/0x44
> [<c1002bc5>] syscall_call+0x7/0xb
> ---[ end trace fda7f44fa2651cfc ]---
>
> but many, many more. Should i create bug in kernel bugzilla, or it is known issue?
>
It's a known issue.

I think Andrew has already queued the fix(http://lkml.org/lkml/2009/6/22/566).

Thank you for your report.

Daisuke Nishimura.