* 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 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
* 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
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).