RE: Oops in JFFS

RE: Oops in JFFS

[Simon Munton]

[-- Attachment #1: Type: text/plain, Size: 3695 bytes --]

> -----Original Message-----
> From: David Woodhouse [mailto:dwmw2@infradead.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@m4data.co.uk
M4 Data Ltd					Tel: 44-1749-683800
Mendip Court, Bath Rd, Wells		Fax: 44-1749-673928
Somerset, BA5 3DG, England




[-- Attachment #2: fs-test.tar.gz --]
[-- Type: application/octet-stream, Size: 1355 bytes --]

Re: Oops in JFFS

[David Woodhouse]

Simon.Munton@m4data.co.uk said:
>  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: 

Which didn't happen before?

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Oops in JFFS

[David Woodhouse]

Appears to be dying at 

    printk("***jffs_remove(): file = \"%s\", ino = %ld\n", _name, dentry->d_inode->i_ino);

dentry->d_inode == NULL?



--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Oops in JFFS

[David Woodhouse]

This code in jffs_rename() looks strange to me. Why are we passing
new_dentry to jffs_remove() when we want the _old_ file with the same name 
to be removed? I think we need to do a lookup to get the dentry for the old 
file with that name, don't we?



--        /* See if there already exists a file with the same name as
           new_name.  */
        if ((del_f = jffs_find_child(new_dir_f, new_dentry->d_name.name,
                                     new_dentry->d_name.len))) {
                raw_inode.rename = 1;
                raw_inode.dsize = sizeof(__u32);
                rename_data = del_f->ino;
        }

        /* Write the new node to the flash memory.  */
        if ((result = jffs_write_node(c, node, &raw_inode,
                                      new_dentry->d_name.name,
                                      (unsigned char*)&rename_data, 0, f)) < 0) {
                D(printk("jffs_rename(): Failed to write node to flash.\n"));
                kfree(node);
                DJM(no_jffs_node--);
                goto jffs_rename_end;
        }
        raw_inode.dsize = 0;

        if (raw_inode.rename) {
                /* The file with the same name must be deleted.  */
                //FIXME deadlock                down(&c->fmc->gclock);
                if ((result = jffs_remove(new_dir, new_dentry,
                                          del_f->mode)) < 0) {
                        /* This is really bad.  */
                        printk(KERN_ERR "JFFS: An error occurred in "
                               "rename().\n");
                }
                //              up(&c->fmc->gclock);
        }


dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RE: Oops in JFFS

[Simon Munton]

> -----Original Message-----
> 
> Which didn't happen before?
> 

No - after the first oops, anything that was talking to JFFS just stopped,
and trying to unmount JFFS came back with device busy.

Simon


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Oops in JFFS

[Simon Munton]

The following program which runs fine on ext2 causes an oops on JFFS:

#include <stdio.h>

int main (int argc, char *argv[])
{
  FILE *fp1;
  char buf[100];
  
  fp1 = fopen ("foo", "w");
  fputs ("hello", fp1);
  fclose (fp1);

  fp1 = fopen ("foo", "r");
  
  unlink ("foo");
  
  fgets (buf, 100, fp1);
  printf("read: %s\n", buf);
  fclose (fp1);
}

What seems to be happening is that after the unlink, the u.generic_ip field
of the inode is set to 0; and then when the file is read, this value is
dereferenced and causes the oops. I believe that JFFS is getting rid of the
file too soon, ie not waiting until all file descriptors referring to the
file are closed.

Suggestions, anyone?

Here is the debug output:

jffs_create(): dir: 0xc0358440, name: "foo"
jffs_write_node(): filename = "foo", ino = 28, total_size = 64
jffs_fmalloc(): fmc = 0xc0090a30, size = 64, node = 0xc0093590
jffs_insert_node(): ino = 28, version = 1, name = "foo", deleted = 0
thread_should_wake(): free=8251696, dirty=5776, blocksize=131072.
***jffs_file_write(): inode: 0xc0f6add0 (ino: 28), filp: 0xc01d9b00, buf:
0x4001
4000, count: 5
jffs_write_node(): filename = "foo", ino = 28, total_size = 72
jffs_fmalloc(): fmc = 0xc0090a30, size = 72, node = 0xc00935e0
jffs_write_node(): setting version of foo to 2
jffs_insert_node(): ino = 28, version = 2, name = "", deleted = 0
jffs_remove_redundant_nodes(): Removing node: ino: 28, version: 1, mod_type:
3
jffs_fmfree(): node->ino = 28, node->version = 1
thread_should_wake(): free=8251624, dirty=5840, blocksize=131072.
***jffs_remove(): file = "foo", ino = 28
jffs_write_node(): filename = "", ino = 28, total_size = 60
jffs_fmalloc(): fmc = 0xc0090a30, size = 60, node = 0xc0093590
jffs_write_node(): setting version of foo to 3
jffs_insert_node(): ino = 28, version = 3, name = "", deleted = 1
jffs_fmfree(): node->ino = 28, node->version = 2
jffs_fmfree(): node->ino = 28, node->version = 3
Unable to handle kernel NULL pointer dereference at virtual address 00000020
current->tss.cr3 = 00ffd000, %cr3 = 00ffd000
*pde = 00000000
Oops: 0000
CPU:    0
EIP:    0010:[<c0152256>]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010292
eax: 00000000   ebx: c0220db8   ecx: c01d9b00   edx: c01fa000
esi: c0f6add0   edi: c0f6add0   ebp: fffffffb   esp: c0f37f10
ds: 0018   es: 0018   ss: 0018
Process jffstest (pid: 70, process nr: 14, stackpage=c0f37000)
Stack: c0f6add0 c0220db8 00000000 00000000 c00909a0 00000000 c011989c
c01d9b00
       c0220db8 00001000 40014000 00000000 00001000 c009ab74 00000000
00000000
       40015000 c00382e0 c0036de0 00000000 00000001 00000000 c0f6add0
c0119a23
Call Trace: [<c011989c>] [<c0119a23>] [<c0119970>] [<c0121d36>] [<c0107be8>]
Code: 8b 50 20 85 d2 75 05 ba a0 5d 1b c0 52 68 c0 5d 1b c0 e8 73

>>EIP; c0152256 <jffs_readpage+36/190>   <=====
Trace; c011989c <do_generic_file_read+56c/640>
Trace; c0119a23 <generic_file_read+63/80>
Trace; c0119970 <file_read_actor+0/50>
Trace; c0121d36 <sys_read+b6/d0>
Trace; c0107be8 <system_call+34/38>
Code;  c0152256 <jffs_readpage+36/190>
00000000 <_EIP>:
Code;  c0152256 <jffs_readpage+36/190>   <=====
   0:   8b 50 20                  movl   0x20(%eax),%edx   <=====
Code;  c0152259 <jffs_readpage+39/190>
   3:   85 d2                     testl  %edx,%edx
Code;  c015225b <jffs_readpage+3b/190>
   5:   75 05                     jne    c <_EIP+0xc> c0152262
<jffs_readpage+42/190>
Code;  c015225d <jffs_readpage+3d/190>
   7:   ba a0 5d 1b c0            movl   $0xc01b5da0,%edx
Code;  c0152262 <jffs_readpage+42/190>
   c:   52                        pushl  %edx
Code;  c0152263 <jffs_readpage+43/190>
   d:   68 c0 5d 1b c0            pushl  $0xc01b5dc0
Code;  c0152268 <jffs_readpage+48/190>
  12:   e8 73 00 00 00            call   8a <_EIP+0x8a> c01522e0
<jffs_readpage+c0/190>

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




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Oops in JFFS

[David Woodhouse]

Simon.Munton@m4data.co.uk said:
> The following program which runs fine on ext2 causes an oops on JFFS: 

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.

--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org