Bug 66251 - Dropped inode_lock in invalidate_list causes oops during unmount
Dropped inode_lock in invalidate_list causes oops during unmount
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 2.1
Classification: Red Hat
Component: kernel (Show other bugs)
2.1
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Larry Woodman
Brian Brock
:
Depends On: 66521
Blocks:
  Show dependency treegraph
 
Reported: 2002-06-06 15:38 EDT by Need Real Name
Modified: 2007-11-30 17:06 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-19 15:26:21 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2002-06-06 15:38:09 EDT
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 &regs = 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:
Comment 1 Arjan van de Ven 2002-06-06 17:13:23 EDT
Which filesystem (ext3?) was involved ?
Comment 2 Need Real Name 2002-06-10 11:08:14 EDT
We have seen the bug with ext3 filesystems and our proprietary filesystem.
Comment 3 Need Real Name 2002-06-21 17:05:27 EDT
Why does this bug depend on bug #65521? I don't see any relation, and bug #65521
is closed anyway.
Comment 4 RHEL Product and Program Management 2007-10-19 15:26:21 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.