headers
Adrian Bunk | 15 Aug 02:42
Picon
Favicon

[2.6 patch] fs/jffs2/xattr.c: remove dead code

This patch removes some obvious dead code spotted by the Coverity 
checker.

Signed-off-by: Adrian Bunk <bunk <at> stusta.de>

--- linux-2.6.18-rc4-mm1/fs/jffs2/xattr.c.old	2006-08-15 02:11:07.000000000 +0200
+++ linux-2.6.18-rc4-mm1/fs/jffs2/xattr.c	2006-08-15 02:11:25.000000000 +0200
@@ -1215,7 +1215,6 @@ int jffs2_garbage_collect_xattr_datum(st
 	rc = jffs2_reserve_space_gc(c, totlen, &length, JFFS2_SUMMARY_XATTR_SIZE);
 	if (rc) {
 		JFFS2_WARNING("jffs2_reserve_space_gc()=%d, request=%u\n", rc, totlen);
-		rc = rc ? rc : -EBADFD;
 		goto out;
 	}
 	rc = save_xattr_datum(c, xd);
Permalink | Reply | 0 comments |
headers
Detlef Vollmann | 16 Aug 23:07
Picon

Lost CRC error

Hello,

on doing some tests with JFFS2 (agreed not the latest version) I
found a serious problem: a CRC error in the data part of a node
never gets through to an application reading the file containing
the erronous node.

My test case was this:
On a read-only filesystem I did a md5sum of the file, afterwards
changed some bytes in the data part of one of the nodes belonging
to that file through /dev/mtdblock1, and did the md5sum again.
I got the same sum and no I/O error.

Not too surprising, the file was still cached.

So I did an umount and after that again a mount.
At mount time, I got an error message in syslog with a CRC error.
Fine.
But when I tried to read the file, it succeeded: no I/O error.
But I got a different md5sum.

So I looked a bit into this and found that the scan at mount time
built an inode cache, but didn't include the node with the
CRC error.
On file read, only the inodes in the inode cache were checked,
and for the missing range a hole frag was created!
So an application reads zeros instead of getting an I/O error.

Is the problem only in my old version of JFFS2 (I think December
2004 for kernel 2.4), or does it still exist?
(Continue reading)

Permalink | Reply | 0 comments |

Gmane