This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 32420 - oops unmounting msdos fs mounted via loopback
oops unmounting msdos fs mounted via loopback
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
7.1
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Alexander Viro
Brock Organ
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-03-20 14:08 EST by Jeremy Katz
Modified: 2007-04-18 12:32 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-04-09 14:14:25 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 Jeremy Katz 2001-03-20 14:08:29 EST
Under kernel-2.4.2-0.1.29 running the buildinstall from anaconda-runtime
from the qa0319 build hung while creating one of the boot disk images.  At
first I thought it was the loop hangs returning, but the oops in dmesg
shows that it was waiting for a umount of the image which caused an oops.

ksymoops gives:

Oops: 0002
CPU:    0
EIP:    0010:[<cd565dc8>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00210246
eax: 00000000   ebx: c0746204   ecx: c0746204   edx: 00000000
esi: c4141f14   edi: c0a13048   ebp: 00000000   esp: c4141edc
ds: 0018   es: 0018   ss: 0018
Process umount (pid: 22591, stackpage=c4141000)
Stack: c0746204 c014d8b2 c0746204 c014d090 cbfea4a0 c1f20204 c1f20204 c0746204 
       c014d920 c0746204 c4141f14 c4141f14 c014da38 c4141f14 c352b20c ca93440c 
       c0a13000 c8859900 cd56ad40 cd4556c0 c013dac9 c0a13000 c012de5e c195b290 
Call Trace: [<c014d8b2>] [<c014d090>] [<c014d920>] [<c014da38>]
[<cd56ad40>] [<cd4556c0>] [<c013dac9>] 
       [<c012de5e>] [<c013df81>] [<c013e0a3>] [<c013e11c>] [<c010910b>] 
Code: 89 50 04 89 02 5b c3 90 53 8b 5c 24 08 8b 83 5c 01 00 00 8b 

>>EIP; cd565dc8 <[fat]fat_clear_inode+18/20>   <=====
Trace; c014d8b2 <clear_inode+102/130>
Trace; c014d090 <destroy_inode+30/40>
Trace; c014d920 <dispose_list+40/60>
Trace; c014da38 <invalidate_inodes+48/60>
Trace; cd56ad40 <[fat]fat_sops+0/38>
Trace; cd4556c0 <[msdos]msdos_fs_type+0/17>
Trace; c013dac9 <kill_super+79/170>
Trace; c012de5e <kfree+20e/2b0>
Trace; c013df81 <do_umount+1d1/1e0>
Trace; c013e0a3 <sys_umount+113/180>
Trace; c013e11c <sys_oldumount+c/10>
Trace; c010910b <system_call+33/38>
Code;  cd565dc8 <[fat]fat_clear_inode+18/20>
00000000 <_EIP>:
Code;  cd565dc8 <[fat]fat_clear_inode+18/20>   <=====
   0:   89 50 04                  mov    %edx,0x4(%eax)   <=====
Code;  cd565dcb <[fat]fat_clear_inode+1b/20>
   3:   89 02                     mov    %eax,(%edx)
Code;  cd565dcd <[fat]fat_clear_inode+1d/20>
   5:   5b                        pop    %ebx
Code;  cd565dce <[fat]fat_clear_inode+1e/20>
   6:   c3                        ret    
Code;  cd565dcf <[fat]fat_clear_inode+1f/20>
   7:   90                        nop    
Code;  cd565dd0 <[fat]fat_put_super+0/b0>
   8:   53                        push   %ebx
Code;  cd565dd1 <[fat]fat_put_super+1/b0>
   9:   8b 5c 24 08               mov    0x8(%esp,1),%ebx
Code;  cd565dd5 <[fat]fat_put_super+5/b0>
   d:   8b 83 5c 01 00 00         mov    0x15c(%ebx),%eax
Code;  cd565ddb <[fat]fat_put_super+b/b0>
  13:   8b 00                     mov    (%eax),%eax
Comment 1 Arjan van de Ven 2001-04-07 19:46:22 EDT
Have you tested with a more recent kernel?
Comment 2 Jeremy Katz 2001-04-09 14:14:20 EDT
I'm not seeing it now, but since I'm not overly certain of the test parameters,
I'm still a little leery...  I'll keep trying to see if I can trigger it with
2.4.2-2 since I'm sure I'll be running buildinstall several times over the next
little bit.
Comment 3 Michael K. Johnson 2001-07-03 17:15:00 EDT
If you ever reproduce with 2.4.3-12 or later please re-open, thanks.

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