Bug 32420 - oops unmounting msdos fs mounted via loopback
Summary: oops unmounting msdos fs mounted via loopback
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.1
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
Assignee: Alexander Viro
QA Contact: Brock Organ
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-03-20 19:08 UTC by Jeremy Katz
Modified: 2007-04-18 16:32 UTC (History)
0 users

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2001-04-09 18:14:25 UTC
Embargoed:


Attachments (Terms of Use)

Description Jeremy Katz 2001-03-20 19:08:29 UTC
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 23:46:22 UTC
Have you tested with a more recent kernel?

Comment 2 Jeremy Katz 2001-04-09 18:14:20 UTC
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 21:15:00 UTC
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.