Description of Problem: In inode.c, invalidate_list() drops inode_lock after saving the "next" link of the current inode. While the lock is dropped the inode associated with next can be removed from the list which is being traversed. This can result in several different flavors of oops, here is one example: Red Hat Linux Advanced Server release 2.1AS/i686 (Pensacola) ####### login: Entering kdb (current=0xf552a000, pid 20265) on processor 1 Oops: Oops due to oops @ 0xc015b029 eax = 0xf5242800 ebx = 0x00000000 ecx = 0x00000001 edx = 0xf552a000 esi = 0xdcf53ac0 edi = 0x00000000 esp = 0xf552bee8 eip = 0xc015b029 ebp = 0xf552bf00 xss = 0x00000018 xcs = 0x00000010 eflags = 0x00010206 xds = 0xf5520018 xes = 0x00000018 origeax = 0xffffffff ®s = 0xf552beb4 [1]kdb> bt EBP EIP Function(args) 0xf552bf00 0xc015b029 invalidate_list+0xd9 (0xc0335fa8, 0xf5242800, 0xf552bf18, 0xf4828e00, 0xf552bf18) kernel .text 0xc0100000 0xc015af50 0xc015b050 0xf552bf2c 0xc015b080 invalidate_inodes+0x30 kernel .text 0xc0100000 0xc015b050 0xc015b0e0 0xf552bf4c 0xc014b3d7 kill_super+0xd7 kernel .text 0xc0100000 0xc014b300 0xc014b4d0 0xc015b004 invalidate_list+0xb4mov (%edx),%eax 0xc015b006 invalidate_list+0xb6mov %ebx,0x4(%eax) 0xc015b009 invalidate_list+0xb9mov %eax,0x8(%esi) 0xc015b00c invalidate_list+0xbcmov %edx,0x4(%ebx) 0xc015b00f invalidate_list+0xbfmov %ebx,(%edx) 0xc015b011 invalidate_list+0xc1orl $0x10,0x10c(%esi) 0xc015b018 invalidate_list+0xc8incl 0xffffffec(%ebp) 0xc015b01b invalidate_list+0xcbjmp 0xc015b027 invalidate_list+0xd7 0xc015b01d invalidate_list+0xcdlea 0x0(%esi),%esi 0xc015b020 invalidate_list+0xd0movl $0x1,0xfffffff0(%ebp) 0xc015b027 invalidate_list+0xd7mov %edi,%ebx 0xc015b029 invalidate_list+0xd9mov (%ebx),%edi 0xc015b02b invalidate_list+0xdbcmp 0x8(%ebp),%ebx 0xc015b02e invalidate_list+0xdejne 0xc015af90 invalidate_list+0x40 0xc015b034 invalidate_list+0xe4mov 0xffffffec(%ebp),%eax The inode corresponding to previous "next" value is in %esi. The i_list for this inode is cleared. "next" is NULL, and the line next = next->next results in an oops. [1]kdb> md 0xdcf53ac0 0xdcf53ac0 dcf53ac0 dcf53ac0 00000000 00000000 ?:???:??........ 0xdcf53ad0 dcf53ad0 dcf53ad0 dcf53ad8 dcf53ad8 ?:???:???:???:?? 0xdcf53ae0 0015357c 00000000 41ed0801 00000002 |5........?A.... 0xdcf53af0 00000000 00000000 0000fe62 00001000 ........b?...... 0xdcf53b00 00000000 3cfe23a2 3117c241 3cfe1f35 ....?#?<A?.15.?< 0xdcf53b10 00001000 00000008 013d10c1 00000000 ........?.=..... 0xdcf53b20 00000001 00000000 00000001 dcf53b2c ............,;?? 0xdcf53b30 dcf53b2c 00000000 00000001 dcf53b3c ,;??........<;?? Version-Release number of selected component (if applicable): kernel-2.4.9-e.3 How Reproducible: Fairly Steps to Reproduce: 1. On an SMP machine, mount several filesystems. 2. Do lots of operations on files on all of the filesystems to get lots of inodes on all of the kernel's inode lists. 3. Unmount several filesystems in parallel. Actual Results: Oops. Expected Results: No oops. Additional Information:
Which filesystem (ext3?) was involved ?
We have seen the bug with ext3 filesystems and our proprietary filesystem.
Why does this bug depend on bug #65521? I don't see any relation, and bug #65521 is closed anyway.
This bug is filed against RHEL2.1, which is in maintenance phase. During the maintenance phase, only security errata and select mission critical bug fixes will be released for enterprise products. Since this bug does not meet that criteria, it is now being closed. For more information of the RHEL errata support policy, please visit: http://www.redhat.com/security/updates/errata/ If you feel this bug is indeed mission critical, please contact your support representative. You may be asked to provide detailed information on how this bug is affecting you.