[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Oops in JFFS



> -----Original Message-----
> From: David Woodhouse [mailto:dwmw2@xxxxxxx.org]
> 
> Just in case anyone here is interested but isn't also 
> subscribed to the 
> JFFS list - I've posted a patch which appears to fix this problem.
> 

Thanks David,

It does seem to fix the specific test case, BUT...  

What I was doing was run a stress test which highlighted the original
problem, and I was able to simplify it to the test case. Running the stress
test with the patch applied gives another oops:

...
***jffs_remove(): file = "dir1", ino = 193
Deleting nonexistent file inode: 193, nlink: 0
jffs_write_node(): filename = "", ino = 193, total_size = 60
jffs_fmalloc(): fmc = 0xc0090ac0, size = 60, node = 0xc0dc1410
jffs_write_node(): setting version of dir1 to 5
jffs_insert_node(): ino = 193, version = 5, name = "", deleted = 1
jffs_remove_redundant_nodes(): Removing node: ino: 193, version: 4,
mod_type: 1
jffs_fmfree(): node->ino = 193, node->version = 4
thread_should_wake(): free=8209096, dirty=32976, blocksize=131072.
***jffs_rename()
jffs_rename(): old_dir: 0xc0f67dc0, old name: 0xc0f34f00, new_dir:
0xc0f67dc0, new name: 0xc0d99070
jffs_write_node(): filename = "dir1", ino = 200, total_size = 68
jffs_fmalloc(): fmc = 0xc0090ac0, size = 68, node = 0xc0da6a10
jffs_write_node(): setting version of test1 to 3
Unable to handle kernel NULL pointer dereference at virtual address 00000018
current->tss.cr3 = 00e47000, %cr3 = 00e47000
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<c015272f>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010246
eax: 00000000   ebx: 00000004   ecx: 00000000   edx: 00000000
esi: c0d99074   edi: c0d99010   ebp: 000081a4   esp: c0e49e94
ds: 0018   es: 0018   ss: 0018
Process mv (pid: 662, process nr: 20, stackpage=c0e49000)
Stack: c0d8bd10 c0da6a10 c0de0430 00000044 00000004 00000004 c0d1fa10
c0e49f14 
       0000003c c0d99070 00000004 c0e49f10 00000004 c01ddd67 c0f92010
c0151de1 
       c0090910 c0da6a10 c0e49f14 c0151e32 c0f67dc0 c0d99010 000081a4
c0f67dc0 
Call Trace: [<c0151de1>] [<c0151e32>] [<c012a539>] [<c012a599>] [<c012a6c1>]
[<c0107be8>] 
Code: 8b 40 18 50 8b 7c 24 14 57 68 a0 5f 1b c0 e8 9e fd fb ff 8b 

>>EIP; c015272f <jffs_remove+4f/300>   <=====
Trace; c0151de1 <jffs_rename+211/330>
Trace; c0151e32 <jffs_rename+262/330>
Trace; c012a539 <vfs_rename_other+1c9/1f0>
Trace; c012a599 <vfs_rename+39/40>
Trace; c012a6c1 <sys_rename+121/190>
Trace; c0107be8 <system_call+34/38>
Code;  c015272f <jffs_remove+4f/300>
00000000 <_EIP>:
Code;  c015272f <jffs_remove+4f/300>   <=====
   0:   8b 40 18                  movl   0x18(%eax),%eax   <=====
Code;  c0152732 <jffs_remove+52/300>
   3:   50                        pushl  %eax
Code;  c0152733 <jffs_remove+53/300>
   4:   8b 7c 24 14               movl   0x14(%esp,1),%edi
Code;  c0152737 <jffs_remove+57/300>
   8:   57                        pushl  %edi
Code;  c0152738 <jffs_remove+58/300>
   9:   68 a0 5f 1b c0            pushl  $0xc01b5fa0
Code;  c015273d <jffs_remove+5d/300>
   e:   e8 9e fd fb ff            call   fffbfdb1 <_EIP+0xfffbfdb1> c01124e0
<printk+0/180>
Code;  c0152742 <jffs_remove+62/300>
  13:   8b 00                     movl   (%eax),%eax

Unfortunately, I've not managed to generate a simple test case, and I won't
be around for the next week, so I've attached the files used to do the
stress test; extract into a JFFS partition, and do:
. ln1 & . ln2 & . ln3 & . try1 & . try2 & . try3 &

and eventually it causes the oops

========================================================
Simon Munton				simonm@xxxxxxx.uk
M4 Data Ltd					Tel: 44-1749-683800
Mendip Court, Bath Rd, Wells		Fax: 44-1749-673928
Somerset, BA5 3DG, England



fs-test.tar.gz