Sami Liedes <sami.liedes@xxxxxx> writes: > Hi! Hi, > I ran some fuzz tests on a vfat filesystem on 3.17 and found a > filesystem that differs from a pristine filesystem by one bit and > causes a kernel BUG. This seems to be an old bug; I can also replicate > it on a 3.3.4 kernel I happened to have lying around. > > The set of operations I run for filesystems is this: > > mount $TARGET_DEV /mnt -t vfat > cd /mnt > timeout 30 cp -r doc doc2 >&/dev/null > timeout 30 find -xdev >&/dev/null > timeout 30 find -xdev -print0 2>/dev/null |xargs -0 touch -- >&/dev/null > timeout 30 mkdir tmp >&/dev/null > timeout 30 echo whoah >tmp/filu >&/dev/null > timeout 30 rm -rf /mnt/* >&/dev/null > cd / > umount /mnt > > The backtrace seems to indicate that the BUG happens at the rm phase. > > You can get the pristine filesystem from > > http://www.niksula.hut.fi/~sliedes/vfat/testimg.vfat.bz2 > > The broken filesystem is at > > http://www.niksula.hut.fi/~sliedes/vfat/testimg.vfat.24.min.bz2 > > The only difference is this one bit: Hm, "." entry in directly seems to be corrupted. Maybe, possible causes are, memory error, memory corruption, fat bug, other bug? Well, this is 1 bit flip. Can you check memory by memtest or such? Do you know how this reproduce? testimg.vfat was empty, and testimg.vfat.24.min was corrupted already. We would need the way how make corrupted image like testimg.vfat.24.min, to find the cause of this problem. Base image for reproducing this bug, and way to do are very helpful. Thanks. -- OGAWA Hirofumi <hirofumi@xxxxxxxxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
