public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: gleixner@autronix.de
Cc: linux-mtd@lists.infradead.org, jffs-dev@axis.com
Subject: Re: JFFS2 list_dirty corruption
Date: Thu, 21 Feb 2002 08:59:09 +0000	[thread overview]
Message-ID: <28487.1014281949@redhat.com> (raw)
In-Reply-To: <02022021101508.18560@thomas>

gleixner@autronix.de said:
> > While hacking on JFFS2 for NAND I found a possibility, where
> > scan_medium corrupts list_dirty. 
> This patch resolves the problem: 

That's OK, but I think it's cleaner if we prevent the mark_node_obsolete() 
code from touching the lists in the first place. This way, we can also 
prevent it from trying to physically mark them obsolete too - if that 
didn't happen the first time, we shouldn't be doing it on mount. 

This problem didn't turn up on NOR flash because we do mark the nodes 
obsolete on the flash, so the mount code never had to bother with them.

Please could you confirm this also fixes the problem?

Index: include/linux/jffs2_fs_sb.h
===================================================================
RCS file: /home/cvs/mtd/include/linux/jffs2_fs_sb.h,v
retrieving revision 1.18
diff -u -p -r1.18 jffs2_fs_sb.h
--- include/linux/jffs2_fs_sb.h	2002/01/09 11:44:23	1.18
+++ include/linux/jffs2_fs_sb.h	2002/02/21 08:33:56
@@ -12,6 +12,7 @@
 #define INOCACHE_HASHSIZE 1
 
 #define JFFS2_SB_FLAG_RO 1
+#define JFFS2_SB_FLAG_MOUNTING 2
 
 /* A struct for the overall file system control.  Pointers to
    jffs2_sb_info structs are named `c' in the source code.  
Index: fs/jffs2/build.c
===================================================================
RCS file: /home/cvs/mtd/fs/jffs2/build.c,v
retrieving revision 1.22
diff -u -p -r1.22 build.c
--- fs/jffs2/build.c	2002/01/09 16:30:57	1.22
+++ fs/jffs2/build.c	2002/02/21 08:33:56
@@ -293,6 +293,7 @@ int jffs2_do_mount_fs(struct jffs2_sb_in
 	INIT_LIST_HEAD(&c->bad_list);
 	INIT_LIST_HEAD(&c->bad_used_list);
 	c->highest_ino = 1;
+	c->flags |= JFFS2_SB_FLAG_MOUNTING;
 
 	if (jffs2_build_filesystem(c)) {
 		D1(printk(KERN_DEBUG "build_fs failed\n"));
@@ -301,5 +302,8 @@ int jffs2_do_mount_fs(struct jffs2_sb_in
 		kfree(c->blocks);
 		return -EIO;
 	}
+	
+	c->flags &= ~JFFS2_SB_FLAG_MOUNTING;
+
 	return 0;
 }
Index: fs/jffs2/nodemgmt.c
===================================================================
RCS file: /home/cvs/mtd/fs/jffs2/nodemgmt.c,v
retrieving revision 1.52
diff -u -p -r1.52 nodemgmt.c
--- fs/jffs2/nodemgmt.c	2002/01/19 23:16:41	1.52
+++ fs/jffs2/nodemgmt.c	2002/02/21 08:33:57
@@ -318,6 +318,15 @@ void jffs2_mark_node_obsolete(struct jff
 
 	ACCT_PARANOIA_CHECK(jeb);
 
+	if (c->flags & JFFS2_SB_FLAG_MOUNTING) {
+		/* Mount in progress. Don't muck about with the block
+		   lists because they're not ready yet, and don't actually
+		   obliterate nodes that look obsolete. If they weren't 
+		   marked obsolete on the flash at the time they _became_
+		   obsolete, there was probably a reason for that. */
+		spin_unlock_bh(&c->erase_completion_lock);
+		return;
+	}
 	if (jeb == c->nextblock) {
 		D2(printk(KERN_DEBUG "Not moving nextblock 0x%08x to dirty/erase_pending list\n", jeb->offset));
 	} else if (jeb == c->gcblock) {


--
dwmw2

  parent reply	other threads:[~2002-02-21  8:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-02-20 19:41 JFFS2 list_dirty corruption Thomas Gleixner
2002-02-20 20:10 ` Thomas Gleixner
2002-02-20 23:55   ` Adam Wozniak
2002-02-20 23:58   ` Adam Wozniak
2002-02-21  0:26     ` Thomas Gleixner
2002-02-21  8:59   ` David Woodhouse [this message]
2002-02-21  9:19     ` Thomas Gleixner
2002-02-21  9:23       ` 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=28487.1014281949@redhat.com \
    --to=dwmw2@infradead.org \
    --cc=gleixner@autronix.de \
    --cc=jffs-dev@axis.com \
    --cc=linux-mtd@lists.infradead.org \
    /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