Re: [BUG] JFFS2 usage of write_begin and write_end functions causes kernel panic

["Anders Grafström" <grfstrm@users.sourceforge.net>]

Anders Grafström wrote:
> The panic occurs at fs/jffs2/file.c:251 which is
> BUG_ON(!PageUptodate(pg));
> 
> Data CRC 33c102e9 != calculated CRC 0ef77e7b for node at 005d42e4

I think this issue might be a sideeffect of (or related to) the erase suspend problems
I'm having. Sometimes there are data CRC errors.
The error is propagated upwards from jffs2_read_dnode to jffs2_do_readpage_nolock
which calls ClearPageUptodate and returns 0 then jffs2_write_end traps on !PageUptodate.

I hope this illustrates the scenario:

jffs2_write_begin {
     jffs2_do_readpage_nolock {
         jffs2_read_inode_range {
             jffs2_read_dnode -> Data CRC 33c102e9 != calculated CRC 0ef77e7b for node at 005d42e4
         }
         ClearPageUptodate(pg);
         return 0
     }
}

jffs2_write_end {
     BUG_ON(!PageUptodate(pg));
}

Should the error value perhaps be forwarded upwards?
Would that inadvertently prevent a broken node from being replaced by a new one?

diff --git a/fs/jffs2/file.c b/fs/jffs2/file.c
index 5e92034..a146bf4 100644
--- a/fs/jffs2/file.c
+++ b/fs/jffs2/file.c
@@ -99,7 +99,7 @@ static int jffs2_do_readpage_nolock (struct inode *inode, struct page *pg)
  	kunmap(pg);

  	D2(printk(KERN_DEBUG "readpage finished\n"));
-	return 0;
+	return ret;
  }

  int jffs2_do_readpage_unlock(struct inode *inode, struct page *pg)