public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Konstantin Kletschke <lists@ku-gbr.de>
Cc: linux-mtd@lists.infradead.org
Subject: Re: jffs2 Oops on 2.6.10-rc2
Date: Sat, 20 Nov 2004 14:47:03 +0000	[thread overview]
Message-ID: <1100962023.8600.38.camel@localhost.localdomain> (raw)
In-Reply-To: <1100959034.8600.33.camel@localhost.localdomain>

[-- 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/

  reply	other threads:[~2004-11-20 14:47 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-11-18 16:35 jffs2 Oops on 2.6.10-rc2 Konstantin Kletschke
2004-11-18 17:20 ` Konstantin Kletschke
2004-11-20 13:57 ` David Woodhouse
2004-11-20 14:47   ` David Woodhouse [this message]
2004-11-20 14:50   ` Konstantin Kletschke
2004-11-20 14:57     ` David Woodhouse
2004-11-20 15:13       ` Artem B. Bityuckiy
2004-11-20 16:28         ` Konstantin Kletschke
2004-11-20 16:31       ` Konstantin Kletschke
2004-11-20 16:35       ` Konstantin Kletschke
2004-11-20 16:34         ` David Woodhouse
2004-11-22 10:27           ` Ian Campbell
2004-11-22 10:50             ` Ian Campbell
2004-11-22 11:05               ` David Woodhouse
2004-11-22 11:42                 ` Ian Campbell
2004-11-20 15:12     ` David Woodhouse

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1100962023.8600.38.camel@localhost.localdomain \
    --to=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=lists@ku-gbr.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox