On Fri, Mar 06, 2015 at 09:56:07AM +0800, Qu Wenruo wrote: > > > -------- Original Message -------- > Subject: Re: btrfs oops while mounting fuzzed btrfs image > From: Liu Bo <bo.li.liu@xxxxxxxxxx> > To: Eryu Guan <guaneryu@xxxxxxxxx> > Date: 2015年03月05日 18:27 > > >On Thu, Mar 05, 2015 at 06:13:54PM +0800, Eryu Guan wrote: > >>On Thu, Mar 05, 2015 at 05:46:12PM +0800, Liu Bo wrote: > >>>On Thu, Mar 05, 2015 at 03:09:33PM +0800, Eryu Guan wrote: > >>>>Hi, > >>>> > >>>>I was testing btrfs with fsfuzzer and encountered a divide error on > >>>>mount, kernel version 3.19 and 4.0-rc1. > >>>> > >>>>I found a similar bug on kernel bugzilla > >>>> > >>>>https://bugzilla.kernel.org/show_bug.cgi?id=88611 > >>>> > >>>>Please find the fuzzed btrfs image in the buzilla, and the following > >>>>command will reproduce: > >>>> > >>>>mount -o loop btrfs.img /mnt/btrfs > >>> > >>>A divide by 0 oops. > >>> > >>>My printk shows that a raid56 chunk has a negative map->length, so we need to find out > >>>how fsfuzzer made that. Can you share your script so that we can > >>>reproduce the oops? > >> > >>You can download fsfuzzer from here: > >> > >>http://people.redhat.com/sgrubb/files/fsfuzzer-0.7.tar.gz > >> > >>What it does is simply writing random garbage to the first 10% of the > >>fs image. You can take a look at fsfuzz and mangle.c > > > >Will take a look, but I guess writing the first 10% of fs image may mess up fs's super block, > >if it does then we can do nothing about it except throwing a WARNING_ONCE(). > > > >Thanks, > > > >-liubo > I'm using the same tool to do enhance btrfsck, and the tool will skip the > first 1M bytes by default, so superblock is not affected. > > Thanks, > Qu Hi, Qu, I'm not seeing that in the code I'm looking at :( In fsfuzz:447, I see the mangle executable called with an offset starting at 0, which would mean that the superblock isn't safe. (Btw, that line also indicates that we potentially write to the entire file system image, not just the beginning. My understanding from mangle.c is that up to 10% of the file contents are modified, not the first 10% of the file by length. Someone please correct me if I'm wrong!). Indeed, Eryu's dmesg shows: [ 309.384037] BTRFS: super block crcs don't match, older mkfs detected This commit is relevant: ---- commit 667e7d94a1683661cff5fe9a0fa0d7f8fdd2c007 Author: Chris Mason <chris.mason@xxxxxxxxxxxx> Date: Tue May 7 11:00:13 2013 -0400 Btrfs: allow superblock mismatch from older mkfs We've added new checks to make sure the super block crc is correct during mount. A fresh filesystem from an older mkfs won't have the crc set. This adds a warning when it finds a newly created filesystem but doesn't fail the mount. Signed-off-by: Chris Mason <chris.mason@xxxxxxxxxxxx> diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c index bc423f7e..4e9ebe1 100644 --- a/fs/btrfs/disk-io.c +++ b/fs/btrfs/disk-io.c @@ -383,6 +383,11 @@ static int btrfs_check_super_csum(char *raw_disk_sb) if (memcmp(raw_disk_sb, result, csum_size)) ret = 1; + + if (ret && btrfs_super_generation(disk_sb) < 10) { + printk(KERN_WARNING "btrfs: super block crcs don't match, older mkfs detected\n"); + ret = 0; + } } if (csum_type >= ARRAY_SIZE(btrfs_csum_sizes)) { ---- So, it looks like the super block is corrupted, but we ignore it because this is a fresh filesystem. I can easily trigger a related panic with this: ---- while true; do dd if=/dev/urandom of=btrfs.img bs=1M count=16 mkfs.btrfs btrfs.img dd if=/dev/urandom of=btrfs.img bs=1 seek=$((64 * 1024 + 88)) count=8 conv=notrunc mount -o loop btrfs.img /mnt && umount /mnt done ---- I'm not sure that this is exactly what's happening with Eryu's image, but it's definitely an issue. I also don't know whether it's safe to get rid of that special case. It looks like it's needed for btrfs-progs before v3.12 (November 2013). Chris? David? Thanks! -- Omar -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
