jffs2 Oops on 2.6.10-rc2

jffs2 Oops on 2.6.10-rc2

[Konstantin Kletschke]

Well I tried out the jffs2 which is in 2.6.10-rc2 vanilla and
experienced the same:

>>EIP; c00b55a0 <jffs2_garbage_collect_metadata+2a4/2e0>   <=====

>>r3; c0179f24 <init_thread_union+1f24/2000>

Trace; c00b5570 <jffs2_garbage_collect_metadata+274/2e0>
Trace; c00b53c8 <jffs2_garbage_collect_metadata+cc/2e0>
Trace; c00b51e4 <jffs2_garbage_collect_pristine+4c4/5dc>
Trace; c00b5904 <jffs2_garbage_collect_hole+d0/478>
Trace; c00b56dc <jffs2_garbage_collect_dirent+100/1cc>
Trace; c00b78ac <jffs2_do_setattr+38/780>
Trace; c00b777c <jffs2_garbage_collect_thread+cc/1c4>
Trace; c00b7ee4 <jffs2_do_setattr+670/780>
Trace; c00b7e4c <jffs2_do_setattr+5d8/780>
Trace; c00b8130 <jffs2_read_inode+58/2f8>

>>r8; c017e040 <def_chr_fops+1c/64>

Trace; c00b7f9c <jffs2_do_setattr+728/780>
Trace; c00789f4 <generic_shutdown_super+70/178>
Trace; c0078998 <generic_shutdown_super+14/178>
Trace; c008fe8c <__mntput+2c/30>
Trace; c008fe08 <clone_mnt+94/ec>
Trace; c0090610 <copy_tree+24/174>
Trace; c00904c0 <do_umount+1bc/1c0>
Trace; c0090a5c <do_loopback+160/1c0>
Trace; c00909b4 <do_loopback+b8/1c0>
Trace; c0008f18 <do_mount_root+30/bc>

>>r8; c0190600 <uidhash_table+7c8/800>
>>r7; c015a8e8 <border+28/4c>

Trace; c0008ee8 <do_mount_root+0/bc>
Trace; c0008ffc <mount_block_root+58/124>
Trace; c0008fa4 <mount_block_root+0/124>
Trace; c0009194 <prepare_namespace+60/a0>

>>r4; c0016628 <tmp_cmdline.1+3a8/400>

Trace; c0009134 <prepare_namespace+0/a0>
Trace; c0017258 <thash_entries+204/fac>

>>r4; c015a700 <__lock_text_end+42c/5ec>

Trace; c0017204 <thash_entries+1b0/fac>
Trace; c00359cc <__set_special_pids+54/8c>

Code;  c00b5590 <jffs2_garbage_collect_metadata+294/2e0>
00000000 <_EIP>:
Code;  c00b5590 <jffs2_garbage_collect_metadata+294/2e0>
   0:   05 00 00 0a 04            add    $0x40a0000,%eax
Code;  c00b5595 <jffs2_garbage_collect_metadata+299/2e0>
   5:   10 a0 e1 07 00 a0         adc    %ah,0xa00007e1(%eax)
Code;  c00b559b <jffs2_garbage_collect_metadata+29f/2e0>
   b:   e1 d1                     loope  ffffffde <_EIP+0xffffffde>
Code;  c00b559d <jffs2_garbage_collect_metadata+2a1/2e0>
   d:   e3 ff                     jecxz  e <_EIP+0xe>
Code;  c00b559f <jffs2_garbage_collect_metadata+2a3/2e0>   <=====
   f:   eb 00                     jmp    11 <_EIP+0x11>   <=====
Code;  c00b55a1 <jffs2_garbage_collect_metadata+2a5/2e0>
  11:   40                        inc    %eax
Code;  c00b55a2 <jffs2_garbage_collect_metadata+2a6/2e0>
  12:   94                        xchg   %eax,%esp
Code;  c00b55a3 <jffs2_garbage_collect_metadata+2a7/2e0>
  13:   e5 00                     in     $0x0,%eax

 <0>Kernel panic - not syncing: Attempted to kill init!

1 error issued.  Results may not be reliable.

I just wanted to inform you to guide to direction where to search.
Also "fixing" with booting 2.6.9 once helps here :)

I haven't found out yet how to test with emulation driver on host PC.

Konsti

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

Re: jffs2 Oops on 2.6.10-rc2

[Konstantin Kletschke]

In nodemgmt.c I remove the following code, which was added after 2.6.9:

#undef KONSTI
#ifdef KONSTI

        /* Nodes which have been marked obsolete no longer need to be
           associated with any inode. Remove them from the per-inode list */
        if (ref->next_in_ino) {
                struct jffs2_inode_cache *ic;
                struct jffs2_raw_node_ref **p;

                ic = jffs2_raw_ref_to_ic(ref);
                for (p = &ic->nodes; (*p) != ref; p = &((*p)->next_in_ino))
                        ;

                *p = ref->next_in_ino;
                ref->next_in_ino = NULL;
        }


        /* Merge with the next node in the physical list, if there is one
           and if it's also obsolete. */
        if (ref->next_phys && ref_obsolete(ref->next_phys) ) {
                struct jffs2_raw_node_ref *n = ref->next_phys;

                ref->__totlen += n->__totlen;
                ref->next_phys = n->next_phys;
                if (jeb->last_node == n) jeb->last_node = ref;
                if (jeb->gc_node == n) {
                        /* gc will be happy continuing gc on this node */
                        jeb->gc_node=ref;
                }
                BUG_ON(n->next_in_ino);
                jffs2_free_raw_node_ref(n);
        }

        /* Also merge with the previous node in the list, if there is one
           and that one is obsolete */
        if (ref != jeb->first_node ) {
                struct jffs2_raw_node_ref *p = jeb->first_node;

                while (p->next_phys != ref)
                        p = p->next_phys;

                if (ref_obsolete(p) ) {
                        p->__totlen += ref->__totlen;
                        if (jeb->last_node == ref) {
                                jeb->last_node = p;
                        }
                        if (jeb->gc_node == ref) {
                                /* gc will be happy continuing gc on this node */
                                jeb->gc_node=p;
                        }
                        p->next_phys = ref->next_phys;
                        jffs2_free_raw_node_ref(ref);
                }
        }

#endif


That helps, the Kernel doesn't Oops on fresh flashed filesystem. Don't know
if the error is this code or only triggered by it though.

Konsti

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

Re: jffs2 Oops on 2.6.10-rc2

[David Woodhouse]

On Thu, 2004-11-18 at 17:35 +0100, Konstantin Kletschke wrote:
> Well I tried out the jffs2 which is in 2.6.10-rc2 vanilla and
> experienced the same:

Is this with an SMP or preemptable kernel? If so, I think I see the
problem. Does it also fix it if you wrap the code you disabled with 
	spin_lock(&c->erase_completion_lock);
	<...>
	spin_unlock(&c->erase_completion_lock);
?

-- 
dwmw2

Re: jffs2 Oops on 2.6.10-rc2

[David Woodhouse]

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

On Sat, 2004-11-20 at 13:57 +0000, David Woodhouse wrote:
> On Thu, 2004-11-18 at 17:35 +0100, Konstantin Kletschke wrote:
> > Well I tried out the jffs2 which is in 2.6.10-rc2 vanilla and
> > experienced the same:
> 
> Is this with an SMP or preemptable kernel? If so, I think I see the
> problem. Does it also fix it if you wrap the code you disabled with 
> 	spin_lock(&c->erase_completion_lock);
> 	<...>
> 	spin_unlock(&c->erase_completion_lock);

Alternatively try the better fix I committed to CVS, which is attached. 

There was another race in jffs2_mark_node_obsolete() anyway -- we were
marking the ref as REF_OBSOLETE and then potentially filing its
eraseblock onto the erase_pending_list, but then we were dropping the
lock -- and nothing was preventing the erase code from actually erasing
the block and then freeing 'ref' before we got round to clearing the
JFFS2_NODETYPE_OBSOLETE bit and trying to merge with adjacent obsolete
refs.

-- 
dwmw2

[-- Attachment #2: Attached message - mtd/fs/jffs2 nodemgmt.c,1.111,1.112 --]
[-- Type: message/rfc822, Size: 7876 bytes --]

From: David Woodhouse <dwmw2@infradead.org>
To: linux-mtd-cvs@lists.infradead.org
Subject: mtd/fs/jffs2 nodemgmt.c,1.111,1.112
Date: Sat, 20 Nov 2004 14:25:09 +0000
Message-ID: <E1CVWAn-0004sU-3M@phoenix.infradead.org>

Update of /home/cvs/mtd/fs/jffs2
In directory phoenix.infradead.org:/tmp/cvs-serv18719

Modified Files:
	nodemgmt.c 
Log Message:
Fix race in jffs2_mark_node_obsolete(). There was nothing preventing the
block from being erased and 'ref' from being freed before we even got
around to marking it obsolete and then trying to merge nodes.


Index: nodemgmt.c
===================================================================
RCS file: /home/cvs/mtd/fs/jffs2/nodemgmt.c,v
retrieving revision 1.111
retrieving revision 1.112
diff -u -r1.111 -r1.112
--- nodemgmt.c	16 Nov 2004 20:36:11 -0000	1.111
+++ nodemgmt.c	20 Nov 2004 14:25:05 -0000	1.112
@@ -399,6 +399,17 @@
 	}
 	jeb = &c->blocks[blocknr];
 
+	if (jffs2_can_mark_obsolete(c) && !jffs2_is_readonly(c) &&
+	    !(c->flags & JFFS2_SB_FLAG_MOUNTING)) {
+		/* Hm. This may confuse static lock analysis. If any of the above 
+		   three conditions is false, we're going to return from this 
+		   function without actually obliterating any nodes or freeing
+		   any jffs2_raw_node_refs. So we don't need to stop erases from
+		   happening, or protect against people holding an obsolete
+		   jffs2_raw_node_ref without the erase_completion_lock. */
+		down(&c->erase_free_sem);
+	}
+
 	spin_lock(&c->erase_completion_lock);
 
 	if (ref_flags(ref) == REF_UNCHECKED) {
@@ -463,6 +474,7 @@
 		   marked obsolete on the flash at the time they _became_
 		   obsolete, there was probably a reason for that. */
 		spin_unlock(&c->erase_completion_lock);
+		/* We didn't lock the erase_free_sem */
 		return;
 	}
 
@@ -515,53 +527,66 @@
 
 	spin_unlock(&c->erase_completion_lock);
 
-	if (!jffs2_can_mark_obsolete(c))
-		return;
-	if (jffs2_is_readonly(c))
+	if (!jffs2_can_mark_obsolete(c) || jffs2_is_readonly(c)) {
+		/* We didn't lock the erase_free_sem */
 		return;
+	}
+
+	/* The erase_free_sem is locked, and has been since before we marked the node obsolete
+	   and potentially put its eraseblock onto the erase_pending_list. Thus, we know that
+	   the block hasn't _already_ been erased, and that 'ref' itself hasn't been freed yet
+	   by jffs2_free_all_node_refs() in erase.c. Which is nice. */
 
 	D1(printk(KERN_DEBUG "obliterating obsoleted node at 0x%08x\n", ref_offset(ref)));
 	ret = jffs2_flash_read(c, ref_offset(ref), sizeof(n), &retlen, (char *)&n);
 	if (ret) {
 		printk(KERN_WARNING "Read error reading from obsoleted node at 0x%08x: %d\n", ref_offset(ref), ret);
-		return;
+		goto out_erase_sem;
 	}
 	if (retlen != sizeof(n)) {
 		printk(KERN_WARNING "Short read from obsoleted node at 0x%08x: %zd\n", ref_offset(ref), retlen);
-		return;
+		goto out_erase_sem;
 	}
 	if (PAD(je32_to_cpu(n.totlen)) != PAD(ref_totlen(c, jeb, ref))) {
 		printk(KERN_WARNING "Node totlen on flash (0x%08x) != totlen from node ref (0x%08x)\n", je32_to_cpu(n.totlen), ref_totlen(c, jeb, ref));
-		return;
+		goto out_erase_sem;
 	}
 	if (!(je16_to_cpu(n.nodetype) & JFFS2_NODE_ACCURATE)) {
 		D1(printk(KERN_DEBUG "Node at 0x%08x was already marked obsolete (nodetype 0x%04x)\n", ref_offset(ref), je16_to_cpu(n.nodetype)));
-		return;
+		goto out_erase_sem;
 	}
 	/* XXX FIXME: This is ugly now */
 	n.nodetype = cpu_to_je16(je16_to_cpu(n.nodetype) & ~JFFS2_NODE_ACCURATE);
 	ret = jffs2_flash_write(c, ref_offset(ref), sizeof(n), &retlen, (char *)&n);
 	if (ret) {
 		printk(KERN_WARNING "Write error in obliterating obsoleted node at 0x%08x: %d\n", ref_offset(ref), ret);
-		return;
+		goto out_erase_sem;
 	}
 	if (retlen != sizeof(n)) {
 		printk(KERN_WARNING "Short write in obliterating obsoleted node at 0x%08x: %zd\n", ref_offset(ref), retlen);
-		return;
+		goto out_erase_sem;
 	}
 
 	/* Nodes which have been marked obsolete no longer need to be
-	   associated with any inode. Remove them from the per-inode list */
+	   associated with any inode. Remove them from the per-inode list.
+	   
+	   Note we can't do this for NAND at the moment because we need 
+	   obsolete dirent nodes to stay on the lists, because of the
+	   horridness in jffs2_garbage_collect_deletion_dirent(). */
 	if (ref->next_in_ino) {
 		struct jffs2_inode_cache *ic;
 		struct jffs2_raw_node_ref **p;
 
+		spin_lock(&c->erase_completion_lock);
+
 		ic = jffs2_raw_ref_to_ic(ref);
 		for (p = &ic->nodes; (*p) != ref; p = &((*p)->next_in_ino))
 			;
 
 		*p = ref->next_in_ino;
 		ref->next_in_ino = NULL;
+
+		spin_unlock(&c->erase_completion_lock);
 	}
 
 
@@ -570,6 +595,8 @@
 	if (ref->next_phys && ref_obsolete(ref->next_phys) ) {
 		struct jffs2_raw_node_ref *n = ref->next_phys;
 		
+		spin_lock(&c->erase_completion_lock);
+
 		ref->__totlen += n->__totlen;
 		ref->next_phys = n->next_phys;
                 if (jeb->last_node == n) jeb->last_node = ref;
@@ -577,6 +604,8 @@
 			/* gc will be happy continuing gc on this node */
 			jeb->gc_node=ref;
 		}
+		spin_unlock(&c->erase_completion_lock);
+
 		BUG_ON(n->next_in_ino);
 		jffs2_free_raw_node_ref(n);
 	}
@@ -585,7 +614,9 @@
 	   and that one is obsolete */
 	if (ref != jeb->first_node ) {
 		struct jffs2_raw_node_ref *p = jeb->first_node;
-		
+
+		spin_lock(&c->erase_completion_lock);
+
 		while (p->next_phys != ref)
 			p = p->next_phys;
 		
@@ -601,7 +632,10 @@
 			p->next_phys = ref->next_phys;
 			jffs2_free_raw_node_ref(ref);
 		}
+		spin_unlock(&c->erase_completion_lock);
 	}
+ out_erase_sem:
+	up(&c->erase_free_sem);
 }
 
 #if CONFIG_JFFS2_FS_DEBUG >= 2


__________________________________________________________
Linux-MTD CVS commit list
http://lists.infradead.org/mailman/listinfo/linux-mtd-cvs/

Re: jffs2 Oops on 2.6.10-rc2

[Konstantin Kletschke]

Am 2004-11-20 13:57 +0000 schrieb David Woodhouse:

> Is this with an SMP or preemptable kernel? If so, I think I see the

Its not SMP but preemtive. Is this even recommend on an embedded system?

> problem. Does it also fix it if you wrap the code you disabled with 
> 	spin_lock(&c->erase_completion_lock);
> 	<...>
> 	spin_unlock(&c->erase_completion_lock);

No, that does not help. I replaced my disabling #defines by the
lock<->unlcocp pair, no avail:

>>EIP; c00b1c74 <jffs2_build_remove_unlinked_inode+30/ec>   <=====

>>r3; c0177f24 <log_wait+0/8>

Trace; c00b1c44 <jffs2_build_remove_unlinked_inode+0/ec>
Trace; c00b1a9c <jffs2_build_filesystem+1e4/38c>
Trace; c00b18b8 <jffs2_build_filesystem+0/38c>
Trace; c00b1fd8 <jffs2_do_mount_fs+228/270>
Trace; c00b1db0 <jffs2_do_mount_fs+0/270>
Trace; c00b3f80 <jffs2_do_fill_super+130/238>
Trace; c00b3e50 <jffs2_do_fill_super+0/238>
Trace; c00b45b8 <jffs2_get_sb_mtd+98/f8>
Trace; c00b4520 <jffs2_get_sb_mtd+0/f8>
Trace; c00b4804 <jffs2_get_sb+194/1d0>

>>r8; c017bdf0 <jffs2_fs_type+0/20>

Trace; c00b4670 <jffs2_get_sb+0/1d0>
Trace; c00750c0 <do_kern_mount+5c/f4>
Trace; c0075064 <do_kern_mount+0/f4>
Trace; c008c558 <do_new_mount+84/b8>
Trace; c008c4d4 <do_new_mount+0/b8>
Trace; c008ccdc <do_mount+150/16c>
Trace; c008cb8c <do_mount+0/16c>
Trace; c008d128 <sys_mount+a8/f0>
Trace; c008d080 <sys_mount+0/f0>
Trace; c0008f18 <do_mount_root+30/bc>

>>r8; c018e3c8 <names_cachep+0/4>
>>r7; c01581c8 <__func__.1+458/f5f0>

Trace; c0008ee8 <do_mount_root+0/bc>
Trace; c0008ffc <mount_block_root+58/124>
Trace; c0008fa4 <mount_block_root+0/124>
Trace; c0009194 <prepare_namespace+60/a0>

>>r4; c0016648 <root_device_name+0/4>

Trace; c0009134 <prepare_namespace+0/a0>
Trace; c0017258 <init+54/f8>

>>r4; c0157fe0 <__func__.1+270/f5f0>

Trace; c0017204 <init+0/f8>
Trace; c00359cc <do_exit+0/500>

Code;  c00b1c64 <jffs2_build_remove_unlinked_inode+20/ec>
00000000 <_EIP>:
Code;  c00b1c64 <jffs2_build_remove_unlinked_inode+20/ec>
   0:   05 00 00 0a 04            add    $0x40a0000,%eax
Code;  c00b1c69 <jffs2_build_remove_unlinked_inode+25/ec>
   5:   10 a0 e1 07 00 a0         adc    %ah,0xa00007e1(%eax)
Code;  c00b1c6f <jffs2_build_remove_unlinked_inode+2b/ec>
   b:   e1 cd                     loope  ffffffda <_EIP+0xffffffda>
Code;  c00b1c71 <jffs2_build_remove_unlinked_inode+2d/ec>
   d:   e3 ff                     jecxz  e <_EIP+0xe>
Code;  c00b1c73 <jffs2_build_remove_unlinked_inode+2f/ec>   <=====
   f:   eb 00                     jmp    11 <_EIP+0x11>   <=====
Code;  c00b1c75 <jffs2_build_remove_unlinked_inode+31/ec>
  11:   40                        inc    %eax
Code;  c00b1c76 <jffs2_build_remove_unlinked_inode+32/ec>
  12:   94                        xchg   %eax,%esp
Code;  c00b1c77 <jffs2_build_remove_unlinked_inode+33/ec>
  13:   e5 00                     in     $0x0,%eax

 <0>Kernel panic - not syncing: Attempted to kill init!

1 error issued.  Results may not be reliable.


Even disabling preemtion generates the same Oops :(

Regards, Konsti

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

Re: jffs2 Oops on 2.6.10-rc2

[David Woodhouse]

On Sat, 2004-11-20 at 15:50 +0100, Konstantin Kletschke wrote:
> No, that does not help. I replaced my disabling #defines by the
> lock<->unlcocp pair, no avail:

Hm, OK. I don't think the other patch is likely to fix it either then.
I'll take another look.

Are you able to join us on IRC? Channel #mtd of irc.freenode.net

-- 
dwmw2

Re: jffs2 Oops on 2.6.10-rc2

[Artem B. Bityuckiy]

Just to exclude the race errors, could you try to disable Preemption and 
try?

On Sat, 20 Nov 2004, David Woodhouse wrote:

> On Sat, 2004-11-20 at 15:50 +0100, Konstantin Kletschke wrote:
> > No, that does not help. I replaced my disabling #defines by the
> > lock<->unlcocp pair, no avail:
> 
> Hm, OK. I don't think the other patch is likely to fix it either then.
> I'll take another look.
> 
> Are you able to join us on IRC? Channel #mtd of irc.freenode.net
> 
> -- 
> dwmw2
> 
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 

--
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.

Re: jffs2 Oops on 2.6.10-rc2

[Konstantin Kletschke]

Am 2004-11-20 15:13 +0000 schrieb Artem B. Bityuckiy:
> Just to exclude the race errors, could you try to disable Preemption and 
> try?

Yes, I did, same error.

K

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

Re: jffs2 Oops on 2.6.10-rc2

[Konstantin Kletschke]

Am 2004-11-20 14:57 +0000 schrieb David Woodhouse:

> Hm, OK. I don't think the other patch is likely to fix it either then.
> I'll take another look.

OK, take your time :)

> Are you able to join us on IRC? Channel #mtd of irc.freenode.net

Argh, sadly not this weekend, I have a visit from my ex gf this evening
and I have a judo tournament on sunday, but on monday or so I will
definately show up in IRC if this is sufficient :)

Regards, Konsti

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

Re: jffs2 Oops on 2.6.10-rc2

[Konstantin Kletschke]

Am 2004-11-20 14:57 +0000 schrieb David Woodhouse:
> On Sat, 2004-11-20 at 15:50 +0100, Konstantin Kletschke wrote:
> > No, that does not help. I replaced my disabling #defines by the
> > lock<->unlcocp pair, no avail:
> 
> Hm, OK. I don't think the other patch is likely to fix it either then.
> I'll take another look.

Sadly I overlooked your other (cvs comitted) patch this evening and I am
at home now, what a pity... That would have cleared the situation up in
5 minutes :/

K

-- 
GPG KeyID EF62FCEF
Fingerprint: 13C9 B16B 9844 EC15 CC2E  A080 1E69 3FDA EF62 FCEF

Re: jffs2 Oops on 2.6.10-rc2

[David Woodhouse]

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

On Sat, 2004-11-20 at 17:35 +0100, Konstantin Kletschke wrote:
> Sadly I overlooked your other (cvs comitted) patch this evening and I am
> at home now, what a pity... That would have cleared the situation up in
> 5 minutes :/

No it wouldn't -- that isn't the problem either. I _think_ this is...

-- 
dwmw2

[-- Attachment #2: Attached message - mtd/fs/jffs2 build.c,1.64,1.65 --]
[-- Type: message/rfc822, Size: 3393 bytes --]

From: David Woodhouse <dwmw2@infradead.org>
To: linux-mtd-cvs@lists.infradead.org
Subject: mtd/fs/jffs2 build.c,1.64,1.65
Date: Sat, 20 Nov 2004 16:19:42 +0000
Message-ID: <E1CVXxd-00050i-W8@phoenix.infradead.org>

Update of /home/cvs/mtd/fs/jffs2
In directory phoenix.infradead.org:/tmp/cvs-serv19258

Modified Files:
	build.c 
Log Message:
Fix freeing of refs belonging to unlinked inode


Index: build.c
===================================================================
RCS file: /home/cvs/mtd/fs/jffs2/build.c,v
retrieving revision 1.64
retrieving revision 1.65
diff -u -r1.64 -r1.65
--- build.c	20 Nov 2004 10:44:07 -0000	1.64
+++ build.c	20 Nov 2004 16:19:38 -0000	1.65
@@ -191,9 +191,12 @@
 
 	D1(printk(KERN_DEBUG "JFFS2: Removing ino #%u with nlink == zero.\n", ic->ino));
 	
-	for (raw = ic->nodes; raw != (void *)ic; raw = raw->next_in_ino) {
+	raw = ic->nodes;
+	while (raw != (void *)ic) {
+		struct jffs2_raw_node_ref *next = raw->next_in_ino;
 		D1(printk(KERN_DEBUG "obsoleting node at 0x%08x\n", ref_offset(raw)));
 		jffs2_mark_node_obsolete(c, raw);
+		raw = next;
 	}
 
 	if (ic->scan_dents) {


__________________________________________________________
Linux-MTD CVS commit list
http://lists.infradead.org/mailman/listinfo/linux-mtd-cvs/

Re: jffs2 Oops on 2.6.10-rc2

[Ian Campbell]

On Sat, 2004-11-20 at 16:34 +0000, David Woodhouse wrote:
> On Sat, 2004-11-20 at 17:35 +0100, Konstantin Kletschke wrote:
> > Sadly I overlooked your other (cvs comitted) patch this evening and I am
> > at home now, what a pity... That would have cleared the situation up in
> > 5 minutes :/
> 
> No it wouldn't -- that isn't the problem either. I _think_ this is...

Just FYI, either this fix (to build.c) or the other one (to nodemgmt.c)
also fixed the BUG_ON I reported earlier in the month...

Many thanks! 
Ian.

-- 
Ian Campbell, Senior Design Engineer
                                        Web: http://www.arcom.com
Arcom, Clifton Road,                    Direct: +44 (0)1223 403 465
Cambridge CB1 7EA, United Kingdom       Phone:  +44 (0)1223 411 200

Re: jffs2 Oops on 2.6.10-rc2

[Ian Campbell]

On Mon, 2004-11-22 at 10:27 +0000, Ian Campbell wrote:
> On Sat, 2004-11-20 at 16:34 +0000, David Woodhouse wrote:
> > On Sat, 2004-11-20 at 17:35 +0100, Konstantin Kletschke wrote:
> > > Sadly I overlooked your other (cvs comitted) patch this evening and I am
> > > at home now, what a pity... That would have cleared the situation up in
> > > 5 minutes :/
> > 
> > No it wouldn't -- that isn't the problem either. I _think_ this is...
> 
> Just FYI, either this fix (to build.c) or the other one (to nodemgmt.c)
> also fixed the BUG_ON I reported earlier in the month...

Gah! Looks like I spoke to soon. Even with both of these patches I still
see the BUG_ON, I've turned off pre-empt as well.

kernel BUG at /home/icampbell/devel/kernel/arm/2.6/fs/jffs2/nodemgmt.c:609!
Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = c3b58000
[00000000] *pgd=a3a87011, *pte=00000000, *ppte=00000000
Internal error: Oops: 807 [#1]
Modules linked in: ds1307
CPU: 0
PC is at __bug+0x40/0x54
LR is at 0x1
pc : [<c0023274>]    lr : [<00000001>]    Not tainted
sp : c3b1fc14  ip : 60000093  fp : c3b1fc24
r10: c3cc4d04  r9 : c3b1fc44  r8 : c3c47400
r7 : c02c12c0  r6 : c3b1fc3c  r5 : 00000000  r4 : 00000000
r3 : 00000000  r2 : 00000000  r1 : 60000013  r0 : 00000001
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  Segment user
Control: 397F  Table: A3B58000  DAC: 00000015
Process rpc.statd (pid: 1011, stack limit = 0xc3b1e190)
Stack: (0xc3b1fc14 to 0xc3b20000)
fc00:                                              c3cc4cf4 c3b1fc78 c3b1fc28
fc20: c00b9764 c0023240 c3b1fc3c c3b1fc44 00000000 00000000 c3c47400 0000000c
fc40: c3b1c002 c0021985 00000048 d22144a5 c3f52ccc c3f52ccc c3f52dac 00000004
fc60: c3805844 c3c47400 c3f9fe24 c3b1fc8c c3b1fc7c c00b9dec c00b9174 00000004
fc80: c3b1fcb8 c3b1fc90 c00ba11c c00b9da8 c3f9fe24 00000000 00000000 c00184f4
fca0: c3805830 00000000 c3c47400 c3b1fd18 c3b1fcbc c00bbdd4 c00b9e0c 00000004
fcc0: 01da5b58 00000003 00000000 00000000 c3ab7000 00000004 00000004 c3ab7000
fce0: 0001a4a8 01da5b58 86dabaa9 86dabaa9 c3b1fd3c c001851c c0018518 c00184f4
fd00: c3805858 00000000 c02706e0 c3b1fd6c c3b1fd1c c00b75b8 c00bba94 00000000
fd20: 00000004 c3b1fd38 c3c47400 c3805830 00000004 00000000 00000000 41a1a5a0
fd40: 41a1a5a0 c02706e0 00000004 00000000 00000000 00000000 00000000 00000004
fd60: c3b1fe0c c3b1fd70 c004e818 c00b741c 00000004 00000000 00018310 c3805858
fd80: c01b4d88 c38058f0 c38c5ae0 00000001 c3b1fe78 00000000 c3b1ff18 00000000
fda0: 1b80589c 00000000 00000000 c3b1fdb8 c0089828 c00c1d4c c02706e0 00000000
fdc0: c3805858 00000001 c38058a4 c380589c 41a1a5a0 c3b1fe10 c3b1fde4 c00814d0
fde0: c00897fc 00000000 00000000 00000000 c38c5ae0 c3b1fe40 00000000 00000000
fe00: c3b1fe74 c3b1fe14 c004f060 c004e4cc 00000000 00000000 c3b1ff78 00000004
fe20: 00000000 00000000 c3805858 00000004 c3b1ff78 c3b1ff18 c3b1fe78 00000001
fe40: 00000004 00000000 00000000 c3f7fd00 c3b1fed8 c3b1fe78 00000000 00000000
fe60: c3b1e000 c3b1ff78 c3b1ff10 c3b1fe78 c004f110 c004ec24 c3f7fd00 00000000
fe80: 00000000 00000001 ffffffff c38c5ae0 c3fec3e4 00000000 c3b1e000 00000000
fea0: c004f568 c3a0dff8 c3f7fd00 00000000 00000000 beffe000 c3a0dff8 c01eb614
fec0: c3b1ff04 c3b1fed0 c005c0c0 c0024ab8 c3f7fd00 c004743c c3b1fed8 c3b1fed8
fee0: 00000000 c3fef46c beffe000 c3b1e000 c38058c0 c38058f0 00000000 c3805858
ff00: c38c5ae0 c3b1ff44 c3b1ff14 c004f270 c004f098 00000006 00018310 00000004
ff20: c38c5ae0 00000000 00000000 00000004 c3b1ff78 00018310 c3b1ff74 c3b1ff48
ff40: c0067d24 c004f220 c3b1ff54 c0067580 c38c5b04 c38c5ae0 c3b1ff78 00000000
ff60: 00000000 00000001 c3b1ffa4 c3b1ff78 c0067e08 c0067c4c 00000000 00000000
ff80: 00000000 00018310 00000006 00017d9c 00000004 c001ea24 00000000 c3b1ffa8
ffa0: c001e8a0 c0067dc8 00018310 c00251e0 00000006 00018310 00000004 00000000
ffc0: 00018310 00000006 00017d9c 0001830c 4016b074 0000b6dc 00000001 000181c4
ffe0: 00000000 befff8d4 00002678 40109a20 60000010 00000006 00000000 00000000
Backtrace:
[<c0023234>] (__bug+0x0/0x54) from [<c00b9764>] (jffs2_mark_node_obsolete+0x5fc/0x6ec)
 r4 = C3CC4CF4
[<c00b9168>] (jffs2_mark_node_obsolete+0x0/0x6ec) from [<c00b9dec>] (jffs2_obsolete_node_frag+0x50/0x64)
[<c00b9d9c>] (jffs2_obsolete_node_frag+0x0/0x64) from [<c00ba11c>] (jffs2_add_full_dnode_to_inode+0x31c/0x440)
 r4 = 00000004
[<c00b9e00>] (jffs2_add_full_dnode_to_inode+0x0/0x440) from [<c00bbdd4>] (jffs2_write_inode_range+0x34c/0x460)
[<c00bba88>] (jffs2_write_inode_range+0x0/0x460) from [<c00b75b8>] (jffs2_commit_write+0x1a8/0x304)
[<c00b7410>] (jffs2_commit_write+0x0/0x304) from [<c004e818>] (generic_file_buffered_write+0x35c/0x5b8)
[<c004e4c0>] (generic_file_buffered_write+0x4/0x5b8) from [<c004f060>] (__generic_file_aio_write_nolock+0x448/0x474)
[<c004ec18>] (__generic_file_aio_write_nolock+0x0/0x474) from [<c004f110>] (__generic_file_write_nolock+0x84/0xb0)
[<c004f08c>] (__generic_file_write_nolock+0x0/0xb0) from [<c004f270>] (generic_file_write+0x5c/0xec)
 r8 = C38C5AE0  r7 = C3805858  r6 = 00000000  r5 = C38058F0
 r4 = C38058C0
[<c004f214>] (generic_file_write+0x0/0xec) from [<c0067d24>] (vfs_write+0xe4/0x108)
[<c0067c40>] (vfs_write+0x0/0x108) from [<c0067e08>] (sys_write+0x4c/0x74)
[<c0067dbc>] (sys_write+0x0/0x74) from [<c001e8a0>] (ret_fast_syscall+0x0/0x2c)
 r8 = C001EA24  r7 = 00000004  r6 = 00017D9C  r5 = 00000006
 r4 = 00018310
Code: 1b00434a e59f0014 eb004348 e3a03000 (e5833000)



-- 
Ian Campbell, Senior Design Engineer
                                        Web: http://www.arcom.com
Arcom, Clifton Road,                    Direct: +44 (0)1223 403 465
Cambridge CB1 7EA, United Kingdom       Phone:  +44 (0)1223 411 200

Re: jffs2 Oops on 2.6.10-rc2

[David Woodhouse]

On Mon, 2004-11-22 at 10:50 +0000, Ian Campbell wrote:
> Gah! Looks like I spoke to soon. Even with both of these patches I still
> see the BUG_ON, I've turned off pre-empt as well.

Quick fix... I suspect the real answer is a pass after the mount has
completed which merges all already-adjacent obsolete nodes, and
disassociates them from their inode.

Index: nodemgmt.c
===================================================================
RCS file: /home/cvs/mtd/fs/jffs2/nodemgmt.c,v
retrieving revision 1.114
diff -u -p -r1.114 nodemgmt.c
--- nodemgmt.c	20 Nov 2004 16:39:59 -0000	1.114
+++ nodemgmt.c	22 Nov 2004 11:03:49 -0000
@@ -601,8 +601,9 @@ void jffs2_mark_node_obsolete(struct jff
 
 
 	/* Merge with the next node in the physical list, if there is one
-	   and if it's also obsolete. */
-	if (ref->next_phys && ref_obsolete(ref->next_phys) ) {
+	   and if it's also obsolete and if it doesn't belong to any inode */
+	if (ref->next_phys && ref_obsolete(ref->next_phys) &&
+	    !ref->next_phys->next_in_ino) {
 		struct jffs2_raw_node_ref *n = ref->next_phys;
 		
 		spin_lock(&c->erase_completion_lock);


-- 
dwmw2

Re: jffs2 Oops on 2.6.10-rc2

[Ian Campbell]

On Mon, 2004-11-22 at 11:05 +0000, David Woodhouse wrote:
> On Mon, 2004-11-22 at 10:50 +0000, Ian Campbell wrote:
> > Gah! Looks like I spoke to soon. Even with both of these patches I still
> > see the BUG_ON, I've turned off pre-empt as well.
> 
> Quick fix... 

It's looking good. Many thanks!
Ian.

-- 
Ian Campbell, Senior Design Engineer
                                        Web: http://www.arcom.com
Arcom, Clifton Road,                    Direct: +44 (0)1223 403 465
Cambridge CB1 7EA, United Kingdom       Phone:  +44 (0)1223 411 200

Re: jffs2 Oops on 2.6.10-rc2

[David Woodhouse]

On Sat, 2004-11-20 at 15:50 +0100, Konstantin Kletschke wrote:
> >>EIP; c00b1c74 <jffs2_build_remove_unlinked_inode+30/ec>   <=====

> Code;  c00b1c71 <jffs2_build_remove_unlinked_inode+2d/ec>
>    d:   e3 ff                     jecxz  e <_EIP+0xe>
> Code;  c00b1c73 <jffs2_build_remove_unlinked_inode+2f/ec>   <=====
>    f:   eb 00                     jmp    11 <_EIP+0x11>   <=====
> Code;  c00b1c75 <jffs2_build_remove_unlinked_inode+31/ec>
>   11:   40                        inc    %eax

Would be nice to see the actual code at jffs2_b_r_u_i+0x30, which isn't
in the above. Can you show the output of 'objdump -d' for the function
in question? And/or the result of telling gdb 'list *0xc00b1c74' on your
vmlinux?

It would also be useful to see the output with CONFIG_JFFS2_FS_DEBUG=1
when mounting the offending file system.

-- 
dwmw2