public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: "Craig A. Vanderborgh" <craigv@voxware.com>
To: dedekind@infradead.org,  linux-mtd@lists.infradead.org
Subject: Re: [BUGFIX] JFFS2 NOR problem
Date: Sat, 26 Feb 2005 22:43:52 -0500	[thread overview]
Message-ID: <422141F8.7050707@voxware.com> (raw)
In-Reply-To: <1109444967.4688.19.camel@sauron.oktetlabs.ru>

Artem B. Bityuckiy wrote:

>Hello,
>
>I've detected major JFFS2 bug and have attached the fix. The bug seems
>to be NOR-only. I believe everybody who uses JFFS2 on top of NOR flash
>should have this bug fixed.
>
>The brief problem description:
>
>JFFS2 clears the JFFS2_SB_FLAG_MOUNTING (c-flags) superblock flag after
>it has done the 1st filesystem build pass. But it still has non NULL
>ic->scan_dents pointers which are actually assigned NULL at the very end
>of the file system build procedure. Next FS build passes call the
>jffs2_mark_node_obsolete() function which, in turn, utilizes the
>jffs2_raw_ref_to_ic() function which *requires* ic->scan_dents = NULL.
>
>This might cause infinite loops and oopses.
>
>I think it is safe to clear the JFFS2_SB_FLAG_MOUNTING flag at the end
>of JFFS2 filesystem build routine. Comments?
>
>P.S. Possibly, the patch will fix Konstantin Kletschke's and Craig A.
>Vanderborgh's problems. Guys, please try.
>
>  
>
>------------------------------------------------------------------------
>
>--- build.c	2005-02-26 22:08:17.503657749 +0300
>+++ build.c_fixed	2005-02-26 22:07:55.806278357 +0300
>@@ -116,7 +116,6 @@
> 			cond_resched();
> 		}
> 	}
>-	c->flags &= ~JFFS2_SB_FLAG_MOUNTING;
> 
> 	D1(printk(KERN_DEBUG "Pass 1 complete\n"));
> 
>@@ -164,6 +163,8 @@
> 		ic->scan_dents = NULL;
> 		cond_resched();
> 	}
>+	c->flags &= ~JFFS2_SB_FLAG_MOUNTING;
>+
> 	D1(printk(KERN_DEBUG "Pass 3 complete\n"));
> 	D2(jffs2_dump_block_lists(c));
> 
>  
>
Hello Artem:

Thank you for taking pity on us :^)

I have succeeded in resolving the oops that I reported in 2 different ways:

1. I applied your patch to the "vanilla" 2.6.10 sources.  To test, I 
compiled and
installed the modified kernel, and had it mount a large (~7MB) JFFS2 
root filesystem
that was "virginal".  This works.  Previously, it was this very same 
testing procedure
that produced a kernel oops "every time".

2. Before receiving your patch, I back-ported the 2.6.11-rc5 sources for 
fs/jffs2
(and the required related header files). I tested using the same 
procedure mentioned
above, and this also works.

Would you please comment on this:  which solution do you think is the 
better one?  Now that we have the newer MTD code working in the 
otherwise "vanilla" 2.6.10 kernel, is this the best solution?  Or is the 
build.c patch solution the safer bet for us?

Please advise.

Thanks a lot for looking into this, we REALLY appreciate it and it's 
great to be fully operational on kernel 2.6!!

Best regards,
craig vanderborgh
voxware incorporated
The 4th Reich

       reply	other threads:[~2005-02-27  3:44 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1109444967.4688.19.camel@sauron.oktetlabs.ru>
2005-02-27  3:43 ` Craig A. Vanderborgh [this message]
2005-02-27 11:26   ` [BUGFIX] JFFS2 NOR problem Artem B. Bityuckiy
2005-02-27 18:10   ` Ray Lehtiniemi
2005-02-27 18:31     ` Artem B. Bityuckiy
2005-02-27 22:44       ` Ray Lehtiniemi
2005-02-26 19:19 Artem B. Bityuckiy
2005-02-27  9:40 ` 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=422141F8.7050707@voxware.com \
    --to=craigv@voxware.com \
    --cc=dedekind@infradead.org \
    --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