* btrfs oops while mounting fuzzed btrfs image
@ 2015-03-05 7:09 Eryu Guan
2015-03-05 9:46 ` Liu Bo
0 siblings, 1 reply; 10+ messages in thread
From: Eryu Guan @ 2015-03-05 7:09 UTC (permalink / raw)
To: linux-btrfs
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
Thanks,
Eryu Guan
[ 309.200469] loop: module loaded
[ 309.372689] BTRFS: device fsid 1c0ed5d6-550d-4010-b1b4-ce1828270713 devid 1 transid 4 /dev/loop0
[ 309.384037] BTRFS: super block crcs don't match, older mkfs detected
[ 309.385449] BTRFS info (device loop0): disk space caching is enabled
[ 309.390429] divide error: 0000 [#1] SMP
[ 309.390791] Modules linked in: loop btrfs xor raid6_pq ppdev parport_pc i2c_piix4 parport virtio_balloon pcspkr i2c_core serio_raw xfs sd_mod ata_generic pata_acpi virtio_pci virtio virtio_ring floppy ata_piix libata 8139too 8139cp mii
[ 309.391373] CPU: 2 PID: 1855 Comm: mount Not tainted 3.19.0 #15
[ 309.391373] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007
[ 309.391373] task: ffff880035068d70 ti: ffff8800360f0000 task.ti: ffff8800360f0000
[ 309.391373] RIP: 0010:[<ffffffffa03073a6>] [<ffffffffa03073a6>] __btrfs_map_block+0x176/0x1180 [btrfs]
[ 309.391373] RSP: 0018:ffff8800360f38f8 EFLAGS: 00010206
[ 309.391373] RAX: 0000000000020000 RBX: 0000000000020000 RCX: 000000d9000000a9
[ 309.391373] RDX: 0000000000000000 RSI: 00000000c1400000 RDI: ffffffff8f018100
[ 309.391373] RBP: ffff8800360f39e8 R08: 0000000000000000 R09: 0000000000000001
[ 309.391373] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000020000
[ 309.391373] R13: ffff8802157e56c0 R14: 0000000000020000 R15: 000000008f018100
[ 309.391373] FS: 00007fcf592eb880(0000) GS:ffff88021fd00000(0000) knlGS:0000000000000000
[ 309.391373] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 309.391373] CR2: 00007f9e367fc034 CR3: 0000000035e6e000 CR4: 00000000000006e0
[ 309.391373] Stack:
[ 309.391373] 0000000000001000 ffff880212fc6a68 0000000000000000 ffff880211a98040
[ 309.391373] ffff8800360f3928 ffffffff812eb7be ffff8800360f3988 ffffffffa0300a82
[ 309.391373] ffff8800360f3a50 ffff880035e7f000 0000000000000000 ffff880035e7ff60
[ 309.391373] Call Trace:
[ 309.391373] [<ffffffff812eb7be>] ? bio_add_page+0x5e/0x70
[ 309.391373] [<ffffffffa0300a82>] ? submit_extent_page.isra.34+0xe2/0x1d0 [btrfs]
[ 309.406845] [<ffffffffa0302a20>] ? btrfs_create_repair_bio+0x110/0x110 [btrfs]
[ 309.406845] [<ffffffffa030d8d6>] btrfs_map_bio+0x96/0x550 [btrfs]
[ 309.406845] [<ffffffff811d10b1>] ? kmem_cache_alloc+0x1a1/0x220
[ 309.406845] [<ffffffffa02d9fca>] btree_submit_bio_hook+0x5a/0x100 [btrfs]
[ 309.406845] [<ffffffffa02fcc38>] submit_one_bio+0x68/0xa0 [btrfs]
[ 309.406845] [<ffffffffa0304ab0>] read_extent_buffer_pages+0x270/0x330 [btrfs]
[ 309.406845] [<ffffffffa02d7120>] ? free_root_pointers+0x60/0x60 [btrfs]
[ 309.406845] [<ffffffffa02d8393>] btree_read_extent_buffer_pages.constprop.52+0xb3/0x120 [btrfs]
[ 309.406845] [<ffffffffa02da270>] read_tree_block+0x40/0x70 [btrfs]
[ 309.406845] [<ffffffffa02ddcdc>] open_ctree+0x143c/0x2140 [btrfs]
[ 309.406845] [<ffffffffa02b333e>] btrfs_mount+0x76e/0x900 [btrfs]
[ 309.406845] [<ffffffff81197604>] ? pcpu_alloc+0x364/0x680
[ 309.406845] [<ffffffff811f2e09>] mount_fs+0x39/0x1b0
[ 309.406845] [<ffffffff81197955>] ? __alloc_percpu+0x15/0x20
[ 309.406845] [<ffffffff8120ea0b>] vfs_kern_mount+0x6b/0x110
[ 309.406845] [<ffffffff812117fc>] do_mount+0x22c/0xb60
[ 309.406845] [<ffffffff811926e6>] ? memdup_user+0x46/0x80
[ 309.406845] [<ffffffff81212472>] SyS_mount+0xa2/0x110
[ 309.406845] [<ffffffff816b76e9>] system_call_fastpath+0x12/0x17
[ 309.406845] Code: 23 10 00 00 48 81 c4 c8 00 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 45 89 c8 31 d2 41 29 c0 48 89 d8 4d 63 c0 4c 0f af c7 45 89 c2 <49> f7 f2 4c 0f af c0 f7 c1 f8 01 00 00 4c 89 85 70 ff ff ff 0f
[ 309.406845] RIP [<ffffffffa03073a6>] __btrfs_map_block+0x176/0x1180 [btrfs]
[ 309.406845] RSP <ffff8800360f38f8>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: btrfs oops while mounting fuzzed btrfs image
2015-03-05 7:09 btrfs oops while mounting fuzzed btrfs image Eryu Guan
@ 2015-03-05 9:46 ` Liu Bo
2015-03-05 10:13 ` Eryu Guan
2015-03-05 16:03 ` Eric Sandeen
0 siblings, 2 replies; 10+ messages in thread
From: Liu Bo @ 2015-03-05 9:46 UTC (permalink / raw)
To: Eryu Guan; +Cc: linux-btrfs
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?
Thanks,
-liubo
>
> Thanks,
> Eryu Guan
>
> [ 309.200469] loop: module loaded
> [ 309.372689] BTRFS: device fsid 1c0ed5d6-550d-4010-b1b4-ce1828270713 devid 1 transid 4 /dev/loop0
> [ 309.384037] BTRFS: super block crcs don't match, older mkfs detected
> [ 309.385449] BTRFS info (device loop0): disk space caching is enabled
> [ 309.390429] divide error: 0000 [#1] SMP
> [ 309.390791] Modules linked in: loop btrfs xor raid6_pq ppdev parport_pc i2c_piix4 parport virtio_balloon pcspkr i2c_core serio_raw xfs sd_mod ata_generic pata_acpi virtio_pci virtio virtio_ring floppy ata_piix libata 8139too 8139cp mii
> [ 309.391373] CPU: 2 PID: 1855 Comm: mount Not tainted 3.19.0 #15
> [ 309.391373] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007
> [ 309.391373] task: ffff880035068d70 ti: ffff8800360f0000 task.ti: ffff8800360f0000
> [ 309.391373] RIP: 0010:[<ffffffffa03073a6>] [<ffffffffa03073a6>] __btrfs_map_block+0x176/0x1180 [btrfs]
> [ 309.391373] RSP: 0018:ffff8800360f38f8 EFLAGS: 00010206
> [ 309.391373] RAX: 0000000000020000 RBX: 0000000000020000 RCX: 000000d9000000a9
> [ 309.391373] RDX: 0000000000000000 RSI: 00000000c1400000 RDI: ffffffff8f018100
> [ 309.391373] RBP: ffff8800360f39e8 R08: 0000000000000000 R09: 0000000000000001
> [ 309.391373] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000020000
> [ 309.391373] R13: ffff8802157e56c0 R14: 0000000000020000 R15: 000000008f018100
> [ 309.391373] FS: 00007fcf592eb880(0000) GS:ffff88021fd00000(0000) knlGS:0000000000000000
> [ 309.391373] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 309.391373] CR2: 00007f9e367fc034 CR3: 0000000035e6e000 CR4: 00000000000006e0
> [ 309.391373] Stack:
> [ 309.391373] 0000000000001000 ffff880212fc6a68 0000000000000000 ffff880211a98040
> [ 309.391373] ffff8800360f3928 ffffffff812eb7be ffff8800360f3988 ffffffffa0300a82
> [ 309.391373] ffff8800360f3a50 ffff880035e7f000 0000000000000000 ffff880035e7ff60
> [ 309.391373] Call Trace:
> [ 309.391373] [<ffffffff812eb7be>] ? bio_add_page+0x5e/0x70
> [ 309.391373] [<ffffffffa0300a82>] ? submit_extent_page.isra.34+0xe2/0x1d0 [btrfs]
> [ 309.406845] [<ffffffffa0302a20>] ? btrfs_create_repair_bio+0x110/0x110 [btrfs]
> [ 309.406845] [<ffffffffa030d8d6>] btrfs_map_bio+0x96/0x550 [btrfs]
> [ 309.406845] [<ffffffff811d10b1>] ? kmem_cache_alloc+0x1a1/0x220
> [ 309.406845] [<ffffffffa02d9fca>] btree_submit_bio_hook+0x5a/0x100 [btrfs]
> [ 309.406845] [<ffffffffa02fcc38>] submit_one_bio+0x68/0xa0 [btrfs]
> [ 309.406845] [<ffffffffa0304ab0>] read_extent_buffer_pages+0x270/0x330 [btrfs]
> [ 309.406845] [<ffffffffa02d7120>] ? free_root_pointers+0x60/0x60 [btrfs]
> [ 309.406845] [<ffffffffa02d8393>] btree_read_extent_buffer_pages.constprop.52+0xb3/0x120 [btrfs]
> [ 309.406845] [<ffffffffa02da270>] read_tree_block+0x40/0x70 [btrfs]
> [ 309.406845] [<ffffffffa02ddcdc>] open_ctree+0x143c/0x2140 [btrfs]
> [ 309.406845] [<ffffffffa02b333e>] btrfs_mount+0x76e/0x900 [btrfs]
> [ 309.406845] [<ffffffff81197604>] ? pcpu_alloc+0x364/0x680
> [ 309.406845] [<ffffffff811f2e09>] mount_fs+0x39/0x1b0
> [ 309.406845] [<ffffffff81197955>] ? __alloc_percpu+0x15/0x20
> [ 309.406845] [<ffffffff8120ea0b>] vfs_kern_mount+0x6b/0x110
> [ 309.406845] [<ffffffff812117fc>] do_mount+0x22c/0xb60
> [ 309.406845] [<ffffffff811926e6>] ? memdup_user+0x46/0x80
> [ 309.406845] [<ffffffff81212472>] SyS_mount+0xa2/0x110
> [ 309.406845] [<ffffffff816b76e9>] system_call_fastpath+0x12/0x17
> [ 309.406845] Code: 23 10 00 00 48 81 c4 c8 00 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 45 89 c8 31 d2 41 29 c0 48 89 d8 4d 63 c0 4c 0f af c7 45 89 c2 <49> f7 f2 4c 0f af c0 f7 c1 f8 01 00 00 4c 89 85 70 ff ff ff 0f
> [ 309.406845] RIP [<ffffffffa03073a6>] __btrfs_map_block+0x176/0x1180 [btrfs]
> [ 309.406845] RSP <ffff8800360f38f8>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: btrfs oops while mounting fuzzed btrfs image
2015-03-05 9:46 ` Liu Bo
@ 2015-03-05 10:13 ` Eryu Guan
2015-03-05 10:27 ` Liu Bo
2015-03-05 16:03 ` Eric Sandeen
1 sibling, 1 reply; 10+ messages in thread
From: Eryu Guan @ 2015-03-05 10:13 UTC (permalink / raw)
To: Liu Bo; +Cc: linux-btrfs
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
Thanks,
Eryu
>
> Thanks,
>
> -liubo
>
> >
> > Thanks,
> > Eryu Guan
> >
> > [ 309.200469] loop: module loaded
> > [ 309.372689] BTRFS: device fsid 1c0ed5d6-550d-4010-b1b4-ce1828270713 devid 1 transid 4 /dev/loop0
> > [ 309.384037] BTRFS: super block crcs don't match, older mkfs detected
> > [ 309.385449] BTRFS info (device loop0): disk space caching is enabled
> > [ 309.390429] divide error: 0000 [#1] SMP
> > [ 309.390791] Modules linked in: loop btrfs xor raid6_pq ppdev parport_pc i2c_piix4 parport virtio_balloon pcspkr i2c_core serio_raw xfs sd_mod ata_generic pata_acpi virtio_pci virtio virtio_ring floppy ata_piix libata 8139too 8139cp mii
> > [ 309.391373] CPU: 2 PID: 1855 Comm: mount Not tainted 3.19.0 #15
> > [ 309.391373] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007
> > [ 309.391373] task: ffff880035068d70 ti: ffff8800360f0000 task.ti: ffff8800360f0000
> > [ 309.391373] RIP: 0010:[<ffffffffa03073a6>] [<ffffffffa03073a6>] __btrfs_map_block+0x176/0x1180 [btrfs]
> > [ 309.391373] RSP: 0018:ffff8800360f38f8 EFLAGS: 00010206
> > [ 309.391373] RAX: 0000000000020000 RBX: 0000000000020000 RCX: 000000d9000000a9
> > [ 309.391373] RDX: 0000000000000000 RSI: 00000000c1400000 RDI: ffffffff8f018100
> > [ 309.391373] RBP: ffff8800360f39e8 R08: 0000000000000000 R09: 0000000000000001
> > [ 309.391373] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000020000
> > [ 309.391373] R13: ffff8802157e56c0 R14: 0000000000020000 R15: 000000008f018100
> > [ 309.391373] FS: 00007fcf592eb880(0000) GS:ffff88021fd00000(0000) knlGS:0000000000000000
> > [ 309.391373] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [ 309.391373] CR2: 00007f9e367fc034 CR3: 0000000035e6e000 CR4: 00000000000006e0
> > [ 309.391373] Stack:
> > [ 309.391373] 0000000000001000 ffff880212fc6a68 0000000000000000 ffff880211a98040
> > [ 309.391373] ffff8800360f3928 ffffffff812eb7be ffff8800360f3988 ffffffffa0300a82
> > [ 309.391373] ffff8800360f3a50 ffff880035e7f000 0000000000000000 ffff880035e7ff60
> > [ 309.391373] Call Trace:
> > [ 309.391373] [<ffffffff812eb7be>] ? bio_add_page+0x5e/0x70
> > [ 309.391373] [<ffffffffa0300a82>] ? submit_extent_page.isra.34+0xe2/0x1d0 [btrfs]
> > [ 309.406845] [<ffffffffa0302a20>] ? btrfs_create_repair_bio+0x110/0x110 [btrfs]
> > [ 309.406845] [<ffffffffa030d8d6>] btrfs_map_bio+0x96/0x550 [btrfs]
> > [ 309.406845] [<ffffffff811d10b1>] ? kmem_cache_alloc+0x1a1/0x220
> > [ 309.406845] [<ffffffffa02d9fca>] btree_submit_bio_hook+0x5a/0x100 [btrfs]
> > [ 309.406845] [<ffffffffa02fcc38>] submit_one_bio+0x68/0xa0 [btrfs]
> > [ 309.406845] [<ffffffffa0304ab0>] read_extent_buffer_pages+0x270/0x330 [btrfs]
> > [ 309.406845] [<ffffffffa02d7120>] ? free_root_pointers+0x60/0x60 [btrfs]
> > [ 309.406845] [<ffffffffa02d8393>] btree_read_extent_buffer_pages.constprop.52+0xb3/0x120 [btrfs]
> > [ 309.406845] [<ffffffffa02da270>] read_tree_block+0x40/0x70 [btrfs]
> > [ 309.406845] [<ffffffffa02ddcdc>] open_ctree+0x143c/0x2140 [btrfs]
> > [ 309.406845] [<ffffffffa02b333e>] btrfs_mount+0x76e/0x900 [btrfs]
> > [ 309.406845] [<ffffffff81197604>] ? pcpu_alloc+0x364/0x680
> > [ 309.406845] [<ffffffff811f2e09>] mount_fs+0x39/0x1b0
> > [ 309.406845] [<ffffffff81197955>] ? __alloc_percpu+0x15/0x20
> > [ 309.406845] [<ffffffff8120ea0b>] vfs_kern_mount+0x6b/0x110
> > [ 309.406845] [<ffffffff812117fc>] do_mount+0x22c/0xb60
> > [ 309.406845] [<ffffffff811926e6>] ? memdup_user+0x46/0x80
> > [ 309.406845] [<ffffffff81212472>] SyS_mount+0xa2/0x110
> > [ 309.406845] [<ffffffff816b76e9>] system_call_fastpath+0x12/0x17
> > [ 309.406845] Code: 23 10 00 00 48 81 c4 c8 00 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 45 89 c8 31 d2 41 29 c0 48 89 d8 4d 63 c0 4c 0f af c7 45 89 c2 <49> f7 f2 4c 0f af c0 f7 c1 f8 01 00 00 4c 89 85 70 ff ff ff 0f
> > [ 309.406845] RIP [<ffffffffa03073a6>] __btrfs_map_block+0x176/0x1180 [btrfs]
> > [ 309.406845] RSP <ffff8800360f38f8>
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: btrfs oops while mounting fuzzed btrfs image
2015-03-05 10:13 ` Eryu Guan
@ 2015-03-05 10:27 ` Liu Bo
2015-03-06 1:56 ` Qu Wenruo
0 siblings, 1 reply; 10+ messages in thread
From: Liu Bo @ 2015-03-05 10:27 UTC (permalink / raw)
To: Eryu Guan; +Cc: linux-btrfs
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
>
> Thanks,
> Eryu
> >
> > Thanks,
> >
> > -liubo
> >
> > >
> > > Thanks,
> > > Eryu Guan
> > >
> > > [ 309.200469] loop: module loaded
> > > [ 309.372689] BTRFS: device fsid 1c0ed5d6-550d-4010-b1b4-ce1828270713 devid 1 transid 4 /dev/loop0
> > > [ 309.384037] BTRFS: super block crcs don't match, older mkfs detected
> > > [ 309.385449] BTRFS info (device loop0): disk space caching is enabled
> > > [ 309.390429] divide error: 0000 [#1] SMP
> > > [ 309.390791] Modules linked in: loop btrfs xor raid6_pq ppdev parport_pc i2c_piix4 parport virtio_balloon pcspkr i2c_core serio_raw xfs sd_mod ata_generic pata_acpi virtio_pci virtio virtio_ring floppy ata_piix libata 8139too 8139cp mii
> > > [ 309.391373] CPU: 2 PID: 1855 Comm: mount Not tainted 3.19.0 #15
> > > [ 309.391373] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007
> > > [ 309.391373] task: ffff880035068d70 ti: ffff8800360f0000 task.ti: ffff8800360f0000
> > > [ 309.391373] RIP: 0010:[<ffffffffa03073a6>] [<ffffffffa03073a6>] __btrfs_map_block+0x176/0x1180 [btrfs]
> > > [ 309.391373] RSP: 0018:ffff8800360f38f8 EFLAGS: 00010206
> > > [ 309.391373] RAX: 0000000000020000 RBX: 0000000000020000 RCX: 000000d9000000a9
> > > [ 309.391373] RDX: 0000000000000000 RSI: 00000000c1400000 RDI: ffffffff8f018100
> > > [ 309.391373] RBP: ffff8800360f39e8 R08: 0000000000000000 R09: 0000000000000001
> > > [ 309.391373] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000020000
> > > [ 309.391373] R13: ffff8802157e56c0 R14: 0000000000020000 R15: 000000008f018100
> > > [ 309.391373] FS: 00007fcf592eb880(0000) GS:ffff88021fd00000(0000) knlGS:0000000000000000
> > > [ 309.391373] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > > [ 309.391373] CR2: 00007f9e367fc034 CR3: 0000000035e6e000 CR4: 00000000000006e0
> > > [ 309.391373] Stack:
> > > [ 309.391373] 0000000000001000 ffff880212fc6a68 0000000000000000 ffff880211a98040
> > > [ 309.391373] ffff8800360f3928 ffffffff812eb7be ffff8800360f3988 ffffffffa0300a82
> > > [ 309.391373] ffff8800360f3a50 ffff880035e7f000 0000000000000000 ffff880035e7ff60
> > > [ 309.391373] Call Trace:
> > > [ 309.391373] [<ffffffff812eb7be>] ? bio_add_page+0x5e/0x70
> > > [ 309.391373] [<ffffffffa0300a82>] ? submit_extent_page.isra.34+0xe2/0x1d0 [btrfs]
> > > [ 309.406845] [<ffffffffa0302a20>] ? btrfs_create_repair_bio+0x110/0x110 [btrfs]
> > > [ 309.406845] [<ffffffffa030d8d6>] btrfs_map_bio+0x96/0x550 [btrfs]
> > > [ 309.406845] [<ffffffff811d10b1>] ? kmem_cache_alloc+0x1a1/0x220
> > > [ 309.406845] [<ffffffffa02d9fca>] btree_submit_bio_hook+0x5a/0x100 [btrfs]
> > > [ 309.406845] [<ffffffffa02fcc38>] submit_one_bio+0x68/0xa0 [btrfs]
> > > [ 309.406845] [<ffffffffa0304ab0>] read_extent_buffer_pages+0x270/0x330 [btrfs]
> > > [ 309.406845] [<ffffffffa02d7120>] ? free_root_pointers+0x60/0x60 [btrfs]
> > > [ 309.406845] [<ffffffffa02d8393>] btree_read_extent_buffer_pages.constprop.52+0xb3/0x120 [btrfs]
> > > [ 309.406845] [<ffffffffa02da270>] read_tree_block+0x40/0x70 [btrfs]
> > > [ 309.406845] [<ffffffffa02ddcdc>] open_ctree+0x143c/0x2140 [btrfs]
> > > [ 309.406845] [<ffffffffa02b333e>] btrfs_mount+0x76e/0x900 [btrfs]
> > > [ 309.406845] [<ffffffff81197604>] ? pcpu_alloc+0x364/0x680
> > > [ 309.406845] [<ffffffff811f2e09>] mount_fs+0x39/0x1b0
> > > [ 309.406845] [<ffffffff81197955>] ? __alloc_percpu+0x15/0x20
> > > [ 309.406845] [<ffffffff8120ea0b>] vfs_kern_mount+0x6b/0x110
> > > [ 309.406845] [<ffffffff812117fc>] do_mount+0x22c/0xb60
> > > [ 309.406845] [<ffffffff811926e6>] ? memdup_user+0x46/0x80
> > > [ 309.406845] [<ffffffff81212472>] SyS_mount+0xa2/0x110
> > > [ 309.406845] [<ffffffff816b76e9>] system_call_fastpath+0x12/0x17
> > > [ 309.406845] Code: 23 10 00 00 48 81 c4 c8 00 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 45 89 c8 31 d2 41 29 c0 48 89 d8 4d 63 c0 4c 0f af c7 45 89 c2 <49> f7 f2 4c 0f af c0 f7 c1 f8 01 00 00 4c 89 85 70 ff ff ff 0f
> > > [ 309.406845] RIP [<ffffffffa03073a6>] __btrfs_map_block+0x176/0x1180 [btrfs]
> > > [ 309.406845] RSP <ffff8800360f38f8>
> > > --
> > > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> > > the body of a message to majordomo@vger.kernel.org
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: btrfs oops while mounting fuzzed btrfs image
2015-03-05 9:46 ` Liu Bo
2015-03-05 10:13 ` Eryu Guan
@ 2015-03-05 16:03 ` Eric Sandeen
1 sibling, 0 replies; 10+ messages in thread
From: Eric Sandeen @ 2015-03-05 16:03 UTC (permalink / raw)
To: bo.li.liu, Eryu Guan; +Cc: linux-btrfs
On 3/5/15 3:46 AM, 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?
All you need to reproduce the oops is the image Eryu provided.
fsfuzzer intentionally damages the filesystem, simulating what might happen
if hardware goes bad, disks fail, admins dd to the wrong disk, memory corrupts,
bugs happen, etc.
The point is that filesystems need to be robust in the face of unexpected data
on the disk, and Eryu has uncovered a case where btrfs is not. :)
-Eric
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: btrfs oops while mounting fuzzed btrfs image
2015-03-05 10:27 ` Liu Bo
@ 2015-03-06 1:56 ` Qu Wenruo
2015-03-06 10:01 ` Omar Sandoval
0 siblings, 1 reply; 10+ messages in thread
From: Qu Wenruo @ 2015-03-06 1:56 UTC (permalink / raw)
To: bo.li.liu, Eryu Guan; +Cc: linux-btrfs
-------- Original Message --------
Subject: Re: btrfs oops while mounting fuzzed btrfs image
From: Liu Bo <bo.li.liu@oracle.com>
To: Eryu Guan <guaneryu@gmail.com>
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
>
>>
>> Thanks,
>> Eryu
>>>
>>> Thanks,
>>>
>>> -liubo
>>>
>>>>
>>>> Thanks,
>>>> Eryu Guan
>>>>
>>>> [ 309.200469] loop: module loaded
>>>> [ 309.372689] BTRFS: device fsid 1c0ed5d6-550d-4010-b1b4-ce1828270713 devid 1 transid 4 /dev/loop0
>>>> [ 309.384037] BTRFS: super block crcs don't match, older mkfs detected
>>>> [ 309.385449] BTRFS info (device loop0): disk space caching is enabled
>>>> [ 309.390429] divide error: 0000 [#1] SMP
>>>> [ 309.390791] Modules linked in: loop btrfs xor raid6_pq ppdev parport_pc i2c_piix4 parport virtio_balloon pcspkr i2c_core serio_raw xfs sd_mod ata_generic pata_acpi virtio_pci virtio virtio_ring floppy ata_piix libata 8139too 8139cp mii
>>>> [ 309.391373] CPU: 2 PID: 1855 Comm: mount Not tainted 3.19.0 #15
>>>> [ 309.391373] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007
>>>> [ 309.391373] task: ffff880035068d70 ti: ffff8800360f0000 task.ti: ffff8800360f0000
>>>> [ 309.391373] RIP: 0010:[<ffffffffa03073a6>] [<ffffffffa03073a6>] __btrfs_map_block+0x176/0x1180 [btrfs]
>>>> [ 309.391373] RSP: 0018:ffff8800360f38f8 EFLAGS: 00010206
>>>> [ 309.391373] RAX: 0000000000020000 RBX: 0000000000020000 RCX: 000000d9000000a9
>>>> [ 309.391373] RDX: 0000000000000000 RSI: 00000000c1400000 RDI: ffffffff8f018100
>>>> [ 309.391373] RBP: ffff8800360f39e8 R08: 0000000000000000 R09: 0000000000000001
>>>> [ 309.391373] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000020000
>>>> [ 309.391373] R13: ffff8802157e56c0 R14: 0000000000020000 R15: 000000008f018100
>>>> [ 309.391373] FS: 00007fcf592eb880(0000) GS:ffff88021fd00000(0000) knlGS:0000000000000000
>>>> [ 309.391373] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
>>>> [ 309.391373] CR2: 00007f9e367fc034 CR3: 0000000035e6e000 CR4: 00000000000006e0
>>>> [ 309.391373] Stack:
>>>> [ 309.391373] 0000000000001000 ffff880212fc6a68 0000000000000000 ffff880211a98040
>>>> [ 309.391373] ffff8800360f3928 ffffffff812eb7be ffff8800360f3988 ffffffffa0300a82
>>>> [ 309.391373] ffff8800360f3a50 ffff880035e7f000 0000000000000000 ffff880035e7ff60
>>>> [ 309.391373] Call Trace:
>>>> [ 309.391373] [<ffffffff812eb7be>] ? bio_add_page+0x5e/0x70
>>>> [ 309.391373] [<ffffffffa0300a82>] ? submit_extent_page.isra.34+0xe2/0x1d0 [btrfs]
>>>> [ 309.406845] [<ffffffffa0302a20>] ? btrfs_create_repair_bio+0x110/0x110 [btrfs]
>>>> [ 309.406845] [<ffffffffa030d8d6>] btrfs_map_bio+0x96/0x550 [btrfs]
>>>> [ 309.406845] [<ffffffff811d10b1>] ? kmem_cache_alloc+0x1a1/0x220
>>>> [ 309.406845] [<ffffffffa02d9fca>] btree_submit_bio_hook+0x5a/0x100 [btrfs]
>>>> [ 309.406845] [<ffffffffa02fcc38>] submit_one_bio+0x68/0xa0 [btrfs]
>>>> [ 309.406845] [<ffffffffa0304ab0>] read_extent_buffer_pages+0x270/0x330 [btrfs]
>>>> [ 309.406845] [<ffffffffa02d7120>] ? free_root_pointers+0x60/0x60 [btrfs]
>>>> [ 309.406845] [<ffffffffa02d8393>] btree_read_extent_buffer_pages.constprop.52+0xb3/0x120 [btrfs]
>>>> [ 309.406845] [<ffffffffa02da270>] read_tree_block+0x40/0x70 [btrfs]
>>>> [ 309.406845] [<ffffffffa02ddcdc>] open_ctree+0x143c/0x2140 [btrfs]
>>>> [ 309.406845] [<ffffffffa02b333e>] btrfs_mount+0x76e/0x900 [btrfs]
>>>> [ 309.406845] [<ffffffff81197604>] ? pcpu_alloc+0x364/0x680
>>>> [ 309.406845] [<ffffffff811f2e09>] mount_fs+0x39/0x1b0
>>>> [ 309.406845] [<ffffffff81197955>] ? __alloc_percpu+0x15/0x20
>>>> [ 309.406845] [<ffffffff8120ea0b>] vfs_kern_mount+0x6b/0x110
>>>> [ 309.406845] [<ffffffff812117fc>] do_mount+0x22c/0xb60
>>>> [ 309.406845] [<ffffffff811926e6>] ? memdup_user+0x46/0x80
>>>> [ 309.406845] [<ffffffff81212472>] SyS_mount+0xa2/0x110
>>>> [ 309.406845] [<ffffffff816b76e9>] system_call_fastpath+0x12/0x17
>>>> [ 309.406845] Code: 23 10 00 00 48 81 c4 c8 00 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 45 89 c8 31 d2 41 29 c0 48 89 d8 4d 63 c0 4c 0f af c7 45 89 c2 <49> f7 f2 4c 0f af c0 f7 c1 f8 01 00 00 4c 89 85 70 ff ff ff 0f
>>>> [ 309.406845] RIP [<ffffffffa03073a6>] __btrfs_map_block+0x176/0x1180 [btrfs]
>>>> [ 309.406845] RSP <ffff8800360f38f8>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: btrfs oops while mounting fuzzed btrfs image
2015-03-06 1:56 ` Qu Wenruo
@ 2015-03-06 10:01 ` Omar Sandoval
2015-03-06 15:46 ` Eric Sandeen
2015-03-09 15:38 ` David Sterba
0 siblings, 2 replies; 10+ messages in thread
From: Omar Sandoval @ 2015-03-06 10:01 UTC (permalink / raw)
To: Qu Wenruo, Chris Mason, David Sterba; +Cc: bo.li.liu, Eryu Guan, linux-btrfs
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@oracle.com>
> To: Eryu Guan <guaneryu@gmail.com>
> 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@fusionio.com>
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@fusionio.com>
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
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: btrfs oops while mounting fuzzed btrfs image
2015-03-06 10:01 ` Omar Sandoval
@ 2015-03-06 15:46 ` Eric Sandeen
2015-03-09 0:48 ` Qu Wenruo
2015-03-09 15:38 ` David Sterba
1 sibling, 1 reply; 10+ messages in thread
From: Eric Sandeen @ 2015-03-06 15:46 UTC (permalink / raw)
To: Omar Sandoval, Qu Wenruo, Chris Mason, David Sterba
Cc: bo.li.liu, Eryu Guan, linux-btrfs
On 3/6/15 4:01 AM, Omar Sandoval wrote:
> 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.
(Semi-wild guess follows):
He may be using a hacked version of mangle which I had been using for
btrfsck testing; I had neutered it a lot because if I let it hit the front
of the filesystem, there was no hope at all for the repair, ever.
Qu, if you're using it for fsck testing, I'd eventually make the mangling
more severe, and go back to the upstream version of mangle.c.
(I keep meaning to make mangle.c and fsfuzzer in general more flexible
and useful, but for now I just have local hacks, sorry).
-Eric
> (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@fusionio.com>
> 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@fusionio.com>
>
> 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!
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: btrfs oops while mounting fuzzed btrfs image
2015-03-06 15:46 ` Eric Sandeen
@ 2015-03-09 0:48 ` Qu Wenruo
0 siblings, 0 replies; 10+ messages in thread
From: Qu Wenruo @ 2015-03-09 0:48 UTC (permalink / raw)
To: Eric Sandeen, Omar Sandoval, Chris Mason, David Sterba
Cc: bo.li.liu, Eryu Guan, linux-btrfs
-------- Original Message --------
Subject: Re: btrfs oops while mounting fuzzed btrfs image
From: Eric Sandeen <sandeen@redhat.com>
To: Omar Sandoval <osandov@osandov.com>, Qu Wenruo
<quwenruo@cn.fujitsu.com>, Chris Mason <clm@fb.com>, David Sterba
<dsterba@suse.cz>
Date: 2015年03月06日 23:46
> On 3/6/15 4:01 AM, Omar Sandoval wrote:
>
>> 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.
>
> (Semi-wild guess follows):
>
> He may be using a hacked version of mangle which I had been using for
> btrfsck testing; I had neutered it a lot because if I let it hit the front
> of the filesystem, there was no hope at all for the repair, ever.
>
> Qu, if you're using it for fsck testing, I'd eventually make the mangling
> more severe, and go back to the upstream version of mangle.c.
>
> (I keep meaning to make mangle.c and fsfuzzer in general more flexible
> and useful, but for now I just have local hacks, sorry).
>
> -Eric
Understood.
Thanks,
Qu
>
>> (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@fusionio.com>
>> 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@fusionio.com>
>>
>> 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!
>>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: btrfs oops while mounting fuzzed btrfs image
2015-03-06 10:01 ` Omar Sandoval
2015-03-06 15:46 ` Eric Sandeen
@ 2015-03-09 15:38 ` David Sterba
1 sibling, 0 replies; 10+ messages in thread
From: David Sterba @ 2015-03-09 15:38 UTC (permalink / raw)
To: Omar Sandoval; +Cc: Qu Wenruo, Chris Mason, bo.li.liu, Eryu Guan, linux-btrfs
On Fri, Mar 06, 2015 at 02:01:13AM -0800, Omar Sandoval wrote:
> +
> + if (ret && btrfs_super_generation(disk_sb) < 10) {
> + printk(KERN_WARNING "btrfs: super block crcs don't match, older mkfs detected\n");
> + ret = 0;
> + }
> 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?
We might remove the special case in the future. The superblock checks
were enhanced so the low generation number does not let an otherwise
heavily damaged superblock.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2015-03-09 15:38 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2015-03-05 7:09 btrfs oops while mounting fuzzed btrfs image Eryu Guan
2015-03-05 9:46 ` Liu Bo
2015-03-05 10:13 ` Eryu Guan
2015-03-05 10:27 ` Liu Bo
2015-03-06 1:56 ` Qu Wenruo
2015-03-06 10:01 ` Omar Sandoval
2015-03-06 15:46 ` Eric Sandeen
2015-03-09 0:48 ` Qu Wenruo
2015-03-09 15:38 ` David Sterba
2015-03-05 16:03 ` Eric Sandeen
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).