Bug 242758

Summary: list_del corruption in 2.6.20-2316 kernel
Product: [Fedora] Fedora Reporter: Cameron Schaus <cam>
Component: kernelAssignee: Kernel Maintainer List <kernel-maint>
Status: CLOSED WONTFIX QA Contact: Brian Brock <bbrock>
Severity: high Docs Contact:
Priority: low    
Version: 5CC: triage
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard: bzcl34nup
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-05-06 19:39:58 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
dmesg from an affected system none

Description Cameron Schaus 2007-06-05 17:27:35 UTC 
Description of problem:

I am running the 2.6.20-2316 kernel, rebuilt with CONFIG_SPINLOCK_DEBUG and
CONFIG_SPINLOCK_SLEEP_DEBUG disabled.  I have disabled spinlock debugging on
advice from this kernel thread:
http://lkml.org/lkml/2006/6/12/261

I will attempt to reproduce on the stock kernel.

list_del corruption. next->prev should be c1308018, but was 00000001
------------[ cut here ]------------
kernel BUG at lib/list_debug.c:72!
invalid opcode: 0000 [#1]
SMP
last sysfs file: /block/hdc/hdc1/size
Modules linked in: ipt_REDIRECT iptable_nat nf_nat ipt_REJECT xt_tcpudp
iptable_filter ip_tables x_tables nf_conntrack_ftp nf_conntrack_ipv4
nf_conntrack nfnetlink bridge ipv6 dm_mirror dm_mod video sbs i2c_ec dock
button battery asus_acpi
backlight ac lp parport_pc parport floppy ata_piix libata scsi_mod e100 mii
uhci_hcd ehci_hcd iTCO_wdt iTCO_vendor_support i2c_i810 i2c_algo_bit i2c_i801
i2c_core pcspkr ext3 jbd
CPU:    0
EIP:    0060:[<c04e990e>]    Not tainted VLI
EFLAGS: 00010096   (2.6.20-1.2322wecansmp #1)
EIP is at list_del+0x42/0x5d
eax: 00000048   ebx: 00000001   ecx: 00000086   edx: 00000000
esi: c06c177c   edi: 0000000a   ebp: c06c0680   esp: e0d4cca4
ds: 007b   es: 007b   ss: 0068
Process java (pid: 2368, ti=e0d4c000 task=e25ee3f0 task.ti=e0d4c000)
Stack: c0679633 c1308018 00000001 c1308018 c0455fad 00000000 c1308000 c06c0680
      00000246 c06c0700 00000004 c04567bf 00000001 00000044 f7f27b30 00000001
      00000000 00020050 c06c2b98 00000000 00cf1881 0000001f 00000001 00000000
Call Trace:
[<c0455fad>] __rmqueue+0x32/0xa2
[<c04567bf>] get_page_from_freelist+0xfe/0x2a6
[<c04569c0>] __alloc_pages+0x59/0x29b
[<c0452686>] find_lock_page+0x1a/0x77
[<c0453141>] find_or_create_page+0x4f/0x86
[<c048a55c>] __getblk+0x174/0x277
[<c047524a>] do_lookup+0x4f/0x140
[<f890550b>] ext3_getblk+0x114/0x254 [ext3]
[<f8906390>] ext3_bread+0x19/0x76 [ext3]
[<f89096d8>] htree_dirblock_to_tree+0x27/0x122 [ext3]
[<f8909836>] ext3_htree_fill_tree+0x63/0x1ba [ext3]
[<c047774f>] do_path_lookup+0x172/0x1c2
[<f8911a06>] ext3_permission+0x0/0xa [ext3]
[<c04754c5>] permission+0xc8/0xdb
[<f8902ba3>] ext3_readdir+0x1d4/0x5e9 [ext3]
[<c04e8ef7>] copy_to_user+0x2d/0x42
[<c0471b0f>] cp_new_stat64+0xfc/0x10e
[<c04794dc>] filldir64+0x0/0xc5
[<c04720e7>] sys_fstat64+0x1e/0x23
[<c04796bd>] vfs_readdir+0x63/0x8d
[<c04794dc>] filldir64+0x0/0xc5
[<c047974a>] sys_getdents64+0x63/0xa5
[<c0403f34>] syscall_call+0x7/0xb
=======================
Code: 24 e5 95 67 c0 e8 c6 d4 f3 ff 0f 0b eb fe 8b 10 8b 5a 04 39 c3 74 18 89
5c 24 08 89 44 24 04 c7 04 24 33 96 67 c0 e8 a5 d4 f3 ff <0f> 0b eb fe 89 4a 04
89 11 c7 40 04 00 02 20 00 c7 00 00 01 10
EIP: [<c04e990e>] list_del+0x42/0x5d SS:ESP 0068:e0d4cca4

I will attach a dmesg.

Version-Release number of selected component (if applicable):
FC5 - 2.6.20-2316

How reproducible:
Once the problem manifests itself, it is 100% reproducible.

Steps to Reproduce:
Attempting to update RPMS, or general disk access on affected systems is enough
to trigger this problem on some systems.  Other systems seem ok.
  
Actual results:
Kernel panic.

Expected results:
No kernel panic.

Additional info:

The kernel is set to reboot on panic (after 5 seconds), but does not reboot on
this panic.
Comment 1 Cameron Schaus 2007-06-05 17:27:35 UTC 
Created attachment 156246 [details]
dmesg from an affected system
Comment 2 Bug Zapper 2008-04-04 07:22:23 UTC 
Fedora apologizes that these issues have not been resolved yet. We're
sorry it's taken so long for your bug to be properly triaged and acted
on. We appreciate the time you took to report this issue and want to
make sure no important bugs slip through the cracks.

If you're currently running a version of Fedora Core between 1 and 6,
please note that Fedora no longer maintains these releases. We strongly
encourage you to upgrade to a current Fedora release. In order to
refocus our efforts as a project we are flagging all of the open bugs
for releases which are no longer maintained and closing them.
http://fedoraproject.org/wiki/LifeCycle/EOL

If this bug is still open against Fedora Core 1 through 6, thirty days
from now, it will be closed 'WONTFIX'. If you can reporduce this bug in
the latest Fedora version, please change to the respective version. If
you are unable to do this, please add a comment to this bug requesting
the change.

Thanks for your help, and we apologize again that we haven't handled
these issues to this point.

The process we are following is outlined here:
http://fedoraproject.org/wiki/BugZappers/F9CleanUp

We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.

And if you'd like to join the bug triage team to help make things
better, check out http://fedoraproject.org/wiki/BugZappers
Comment 3 Bug Zapper 2008-05-06 19:39:57 UTC 
This bug is open for a Fedora version that is no longer maintained and
will not be fixed by Fedora. Therefore we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen thus bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.