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

Anders Grafström
2008-04-28T20:00:40Z

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)