[BUG] JFFS2 usage of write_begin and write_end functions causes kernel panic
Anders Grafström
grfstrm at users.sourceforge.net
Mon Apr 28 16:00:16 EDT 2008
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)
More information about the linux-mtd
mailing list