* kernel BUG at fs/btrfs/extent-tree.c:6164!
@ 2011-06-06 8:33 Tsutomu Itoh
2011-06-07 5:31 ` liubo
0 siblings, 1 reply; 19+ messages in thread
From: Tsutomu Itoh @ 2011-06-06 8:33 UTC (permalink / raw)
To: Linux Btrfs; +Cc: Chris Mason, liubo
Hi,
I encountered following panic using 'btrfs-unstable + for-linus'
kernel.
I ran "btrfs fi bal /test5" command, and mount option of /test5
is as follows:
/dev/sdc3 on /test5 type btrfs (rw,space_cache,compress=lzo,inode_cache)
Thanks,
Tsutomu
=================================================================
btrfs: relocating block group 23383244800 flags 20
btrfs: found 2959 extents
------------[ cut here ]------------
WARNING: at fs/btrfs/transaction.c:213 start_transaction+0x2a7/0x2b0 [btrfs]()
Hardware name: PRIMERGY
Modules linked in: autofs4 sunrpc 8021q garp stp llc cpufreq_ondemand acpi_cpufr
eq freq_table mperf ipv6 btrfs zlib_deflate crc32c libcrc32c ext3 jbd dm_mirror
dm_region_hash dm_log dm_mod kvm uinput ppdev parport_pc parport sg pcspkr i2c_i
801 i2c_core iTCO_wdt iTCO_vendor_support tg3 shpchp pci_hotplug i3000_edac edac
_core ext4 mbcache jbd2 crc16 sd_mod crc_t10dif sr_mod cdrom megaraid_sas pata_a
cpi ata_generic ata_piix libata scsi_mod floppy [last unloaded: microcode]
Pid: 23781, comm: btrfs Tainted: G W 2.6.39btrfs-test+ #4
Call Trace:
[<ffffffff8106004f>] warn_slowpath_common+0x7f/0xc0
[<ffffffff810600aa>] warn_slowpath_null+0x1a/0x20
[<ffffffffa0337047>] start_transaction+0x2a7/0x2b0 [btrfs]
[<ffffffffa035498d>] ? btrfs_wait_ordered_range+0x10d/0x160 [btrfs]
[<ffffffffa0337323>] btrfs_start_transaction+0x13/0x20 [btrfs]
[<ffffffffa033bbca>] btrfs_evict_inode+0x11a/0x260 [btrfs]
[<ffffffff811687f8>] evict+0x78/0x170
[<ffffffff81168c92>] iput+0xe2/0x1a0
[<ffffffffa031f171>] btrfs_remove_block_group+0x141/0x3c0 [btrfs]
[<ffffffffa035e6ea>] btrfs_relocate_chunk+0x54a/0x670 [btrfs]
[<ffffffffa0357668>] ? read_extent_buffer+0xd8/0x1d0 [btrfs]
[<ffffffffa031be51>] ? btrfs_previous_item+0xb1/0x150 [btrfs]
[<ffffffffa035f43a>] btrfs_balance+0x21a/0x2b0 [btrfs]
[<ffffffff8115dc41>] ? path_openat+0x101/0x3d0
[<ffffffffa03685bc>] btrfs_ioctl+0x51c/0xc40 [btrfs]
[<ffffffff8111e358>] ? handle_mm_fault+0x148/0x270
[<ffffffff814809e8>] ? do_page_fault+0x1d8/0x4b0
[<ffffffff81160d6a>] do_vfs_ioctl+0x9a/0x540
[<ffffffff811612b1>] sys_ioctl+0xa1/0xb0
[<ffffffff81484ec2>] system_call_fastpath+0x16/0x1b
---[ end trace e5c5cb2e98a3cd1a ]---
btrfs: relocating block group 20971520 flags 18
btrfs: relocating block group 34925969408 flags 18
btrfs: found 1 extents
------------[ cut here ]------------
kernel BUG at fs/btrfs/extent-tree.c:6164!
invalid opcode: 0000 [#1] SMP
last sysfs file: /sys/kernel/mm/ksm/run
CPU 0
Modules linked in: autofs4 sunrpc 8021q garp stp llc cpufreq_ondemand acpi_cpufreq freq_table mperf ipv6 btrfs zlib_deflate crc32c libcrc32c ext3 jbd dm_mirror dm_region_hash dm_log dm_mod kvm uinput ppdev parport_pc parport sg pcspkr i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support tg3 shpchp pci_hotplug i3000_edac edac_core ext4 mbcache jbd2 crc16 sd_mod crc_t10dif sr_mod cdrom megaraid_sas pata_acpi ata_generic ata_piix libata scsi_mod floppy [last unloaded: microcode]
Pid: 4109, comm: btrfs Tainted: G W 2.6.39btrfs-test+ #4 FUJITSU-SV PRIMERGY /D2399
RIP: 0010:[<ffffffffa0325b95>] [<ffffffffa0325b95>] walk_up_proc+0x375/0x420 [btrfs]
RSP: 0018:ffff8801801eb9c8 EFLAGS: 00010286
RAX: 0000000000000005 RBX: ffff880167a70140 RCX: fffffffffffffff8
RDX: ffff8801801ea000 RSI: ffff880000000000 RDI: ffff880194909fa8
RBP: ffff8801801eba18 R08: 0000000000000000 R09: 0000000000000005
R10: 0000000000000001 R11: ffff880194909fa8 R12: 0000000000000000
R13: ffff88013973d000 R14: ffff88015ad4d9a0 R15: ffff880042203920
FS: 00007fa86bcb9740(0000) GS:ffff88019fc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00000033cf60b0c0 CR3: 0000000181cf7000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process btrfs (pid: 4109, threadinfo ffff8801801ea000, task ffff88011a4914a0)
Stack:
ffff8801801eba18 ffff880194909fa8 ffff880100000000 ffffffffa03280e8
ffff8801801eba58 ffff88015ad4d9a0 0000000000000000 0000000000000000
ffff8801801ea000 ffff880167a70140 ffff8801801eba78 ffffffffa0325d71
Call Trace:
[<ffffffffa03280e8>] ? btrfs_run_delayed_refs+0xc8/0x210 [btrfs]
[<ffffffffa0325d71>] walk_up_tree+0x131/0x1b0 [btrfs]
[<ffffffffa03260b0>] btrfs_drop_snapshot+0x2c0/0x5c0 [btrfs]
[<ffffffffa03328b0>] ? btrfs_read_fs_root_no_name+0x1b0/0x280 [btrfs]
[<ffffffffa037b45f>] merge_reloc_roots+0xdf/0x150 [btrfs]
[<ffffffffa037f311>] relocate_block_group+0x481/0x660 [btrfs]
[<ffffffffa0334d15>] ? btrfs_clean_old_snapshots+0x35/0x150 [btrfs]
[<ffffffffa037f6a3>] btrfs_relocate_block_group+0x1b3/0x2e0 [btrfs]
[<ffffffffa0368d80>] ? btrfs_tree_unlock+0x50/0x50 [btrfs]
[<ffffffffa035e22b>] btrfs_relocate_chunk+0x8b/0x670 [btrfs]
[<ffffffffa031303d>] ? btrfs_set_path_blocking+0x3d/0x50 [btrfs]
[<ffffffffa0357668>] ? read_extent_buffer+0xd8/0x1d0 [btrfs]
[<ffffffffa031be51>] ? btrfs_previous_item+0xb1/0x150 [btrfs]
[<ffffffffa0357668>] ? read_extent_buffer+0xd8/0x1d0 [btrfs]
[<ffffffffa035f43a>] btrfs_balance+0x21a/0x2b0 [btrfs]
[<ffffffff8115dc41>] ? path_openat+0x101/0x3d0
[<ffffffffa03685bc>] btrfs_ioctl+0x51c/0xc40 [btrfs]
[<ffffffff8111e358>] ? handle_mm_fault+0x148/0x270
[<ffffffff814809e8>] ? do_page_fault+0x1d8/0x4b0
[<ffffffff81160d6a>] do_vfs_ioctl+0x9a/0x540
[<ffffffff811612b1>] sys_ioctl+0xa1/0xb0
[<ffffffff81484ec2>] system_call_fastpath+0x16/0x1b
Code: fe ff ff 0f 1f 00 4c 89 df 31 c9 4c 89 fa 4c 89 ee 44 89 55 c0 4c 89 5d b8 e8 c8 d5 ff ff 4c 8b 5d b8 44 8b 55 c0 e9 85 fe ff ff <0f> 0b eb fe 0f 1f 80 00 00 00 00 65 48 8b 14 25 c8 cc 00 00 48
RIP [<ffffffffa0325b95>] walk_up_proc+0x375/0x420 [btrfs]
RSP <ffff8801801eb9c8>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: kernel BUG at fs/btrfs/extent-tree.c:6164!
2011-06-06 8:33 kernel BUG at fs/btrfs/extent-tree.c:6164! Tsutomu Itoh
@ 2011-06-07 5:31 ` liubo
2011-06-07 5:59 ` Tsutomu Itoh
0 siblings, 1 reply; 19+ messages in thread
From: liubo @ 2011-06-07 5:31 UTC (permalink / raw)
To: Tsutomu Itoh; +Cc: Linux Btrfs, Chris Mason
On 06/06/2011 04:33 PM, Tsutomu Itoh wrote:
> Hi,
>
> I encountered following panic using 'btrfs-unstable + for-linus'
> kernel.
>
> I ran "btrfs fi bal /test5" command, and mount option of /test5
> is as follows:
>
> /dev/sdc3 on /test5 type btrfs (rw,space_cache,compress=lzo,inode_cache)
>
So, just a "btrfs fi bal" would lead to the bug?
I've figured out the warnings, but not reproduced the bug yet...
I used 'btrfs-unstable + for-linus" whose top commit is
commit aa0467d8d2a00e75b2bb6a56a4ee6d70c5d1928f
Author: David Sterba <dsterba@suse.cz>
Date: Fri Jun 3 16:29:08 2011 +0200
btrfs: fix uninitialized variable warning
and tried on 1) a single disk, 2) 2 disks and 3) 4 disks respectively,
but none of them leaded to the below bug.
I guess maybe I miss something to reproduce it?
thanks,
liubo
> Thanks,
> Tsutomu
>
> =================================================================
>
> btrfs: relocating block group 23383244800 flags 20
> btrfs: found 2959 extents
> ------------[ cut here ]------------
> WARNING: at fs/btrfs/transaction.c:213 start_transaction+0x2a7/0x2b0 [btrfs]()
> Hardware name: PRIMERGY
> Modules linked in: autofs4 sunrpc 8021q garp stp llc cpufreq_ondemand acpi_cpufr
> eq freq_table mperf ipv6 btrfs zlib_deflate crc32c libcrc32c ext3 jbd dm_mirror
> dm_region_hash dm_log dm_mod kvm uinput ppdev parport_pc parport sg pcspkr i2c_i
> 801 i2c_core iTCO_wdt iTCO_vendor_support tg3 shpchp pci_hotplug i3000_edac edac
> _core ext4 mbcache jbd2 crc16 sd_mod crc_t10dif sr_mod cdrom megaraid_sas pata_a
> cpi ata_generic ata_piix libata scsi_mod floppy [last unloaded: microcode]
> Pid: 23781, comm: btrfs Tainted: G W 2.6.39btrfs-test+ #4
> Call Trace:
> [<ffffffff8106004f>] warn_slowpath_common+0x7f/0xc0
> [<ffffffff810600aa>] warn_slowpath_null+0x1a/0x20
> [<ffffffffa0337047>] start_transaction+0x2a7/0x2b0 [btrfs]
> [<ffffffffa035498d>] ? btrfs_wait_ordered_range+0x10d/0x160 [btrfs]
> [<ffffffffa0337323>] btrfs_start_transaction+0x13/0x20 [btrfs]
> [<ffffffffa033bbca>] btrfs_evict_inode+0x11a/0x260 [btrfs]
> [<ffffffff811687f8>] evict+0x78/0x170
> [<ffffffff81168c92>] iput+0xe2/0x1a0
> [<ffffffffa031f171>] btrfs_remove_block_group+0x141/0x3c0 [btrfs]
> [<ffffffffa035e6ea>] btrfs_relocate_chunk+0x54a/0x670 [btrfs]
> [<ffffffffa0357668>] ? read_extent_buffer+0xd8/0x1d0 [btrfs]
> [<ffffffffa031be51>] ? btrfs_previous_item+0xb1/0x150 [btrfs]
> [<ffffffffa035f43a>] btrfs_balance+0x21a/0x2b0 [btrfs]
> [<ffffffff8115dc41>] ? path_openat+0x101/0x3d0
> [<ffffffffa03685bc>] btrfs_ioctl+0x51c/0xc40 [btrfs]
> [<ffffffff8111e358>] ? handle_mm_fault+0x148/0x270
> [<ffffffff814809e8>] ? do_page_fault+0x1d8/0x4b0
> [<ffffffff81160d6a>] do_vfs_ioctl+0x9a/0x540
> [<ffffffff811612b1>] sys_ioctl+0xa1/0xb0
> [<ffffffff81484ec2>] system_call_fastpath+0x16/0x1b
> ---[ end trace e5c5cb2e98a3cd1a ]---
> btrfs: relocating block group 20971520 flags 18
> btrfs: relocating block group 34925969408 flags 18
> btrfs: found 1 extents
> ------------[ cut here ]------------
> kernel BUG at fs/btrfs/extent-tree.c:6164!
> invalid opcode: 0000 [#1] SMP
> last sysfs file: /sys/kernel/mm/ksm/run
> CPU 0
> Modules linked in: autofs4 sunrpc 8021q garp stp llc cpufreq_ondemand acpi_cpufreq freq_table mperf ipv6 btrfs zlib_deflate crc32c libcrc32c ext3 jbd dm_mirror dm_region_hash dm_log dm_mod kvm uinput ppdev parport_pc parport sg pcspkr i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support tg3 shpchp pci_hotplug i3000_edac edac_core ext4 mbcache jbd2 crc16 sd_mod crc_t10dif sr_mod cdrom megaraid_sas pata_acpi ata_generic ata_piix libata scsi_mod floppy [last unloaded: microcode]
>
> Pid: 4109, comm: btrfs Tainted: G W 2.6.39btrfs-test+ #4 FUJITSU-SV PRIMERGY /D2399
> RIP: 0010:[<ffffffffa0325b95>] [<ffffffffa0325b95>] walk_up_proc+0x375/0x420 [btrfs]
> RSP: 0018:ffff8801801eb9c8 EFLAGS: 00010286
> RAX: 0000000000000005 RBX: ffff880167a70140 RCX: fffffffffffffff8
> RDX: ffff8801801ea000 RSI: ffff880000000000 RDI: ffff880194909fa8
> RBP: ffff8801801eba18 R08: 0000000000000000 R09: 0000000000000005
> R10: 0000000000000001 R11: ffff880194909fa8 R12: 0000000000000000
> R13: ffff88013973d000 R14: ffff88015ad4d9a0 R15: ffff880042203920
> FS: 00007fa86bcb9740(0000) GS:ffff88019fc00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 00000033cf60b0c0 CR3: 0000000181cf7000 CR4: 00000000000006f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process btrfs (pid: 4109, threadinfo ffff8801801ea000, task ffff88011a4914a0)
> Stack:
> ffff8801801eba18 ffff880194909fa8 ffff880100000000 ffffffffa03280e8
> ffff8801801eba58 ffff88015ad4d9a0 0000000000000000 0000000000000000
> ffff8801801ea000 ffff880167a70140 ffff8801801eba78 ffffffffa0325d71
> Call Trace:
> [<ffffffffa03280e8>] ? btrfs_run_delayed_refs+0xc8/0x210 [btrfs]
> [<ffffffffa0325d71>] walk_up_tree+0x131/0x1b0 [btrfs]
> [<ffffffffa03260b0>] btrfs_drop_snapshot+0x2c0/0x5c0 [btrfs]
> [<ffffffffa03328b0>] ? btrfs_read_fs_root_no_name+0x1b0/0x280 [btrfs]
> [<ffffffffa037b45f>] merge_reloc_roots+0xdf/0x150 [btrfs]
> [<ffffffffa037f311>] relocate_block_group+0x481/0x660 [btrfs]
> [<ffffffffa0334d15>] ? btrfs_clean_old_snapshots+0x35/0x150 [btrfs]
> [<ffffffffa037f6a3>] btrfs_relocate_block_group+0x1b3/0x2e0 [btrfs]
> [<ffffffffa0368d80>] ? btrfs_tree_unlock+0x50/0x50 [btrfs]
> [<ffffffffa035e22b>] btrfs_relocate_chunk+0x8b/0x670 [btrfs]
> [<ffffffffa031303d>] ? btrfs_set_path_blocking+0x3d/0x50 [btrfs]
> [<ffffffffa0357668>] ? read_extent_buffer+0xd8/0x1d0 [btrfs]
> [<ffffffffa031be51>] ? btrfs_previous_item+0xb1/0x150 [btrfs]
> [<ffffffffa0357668>] ? read_extent_buffer+0xd8/0x1d0 [btrfs]
> [<ffffffffa035f43a>] btrfs_balance+0x21a/0x2b0 [btrfs]
> [<ffffffff8115dc41>] ? path_openat+0x101/0x3d0
> [<ffffffffa03685bc>] btrfs_ioctl+0x51c/0xc40 [btrfs]
> [<ffffffff8111e358>] ? handle_mm_fault+0x148/0x270
> [<ffffffff814809e8>] ? do_page_fault+0x1d8/0x4b0
> [<ffffffff81160d6a>] do_vfs_ioctl+0x9a/0x540
> [<ffffffff811612b1>] sys_ioctl+0xa1/0xb0
> [<ffffffff81484ec2>] system_call_fastpath+0x16/0x1b
> Code: fe ff ff 0f 1f 00 4c 89 df 31 c9 4c 89 fa 4c 89 ee 44 89 55 c0 4c 89 5d b8 e8 c8 d5 ff ff 4c 8b 5d b8 44 8b 55 c0 e9 85 fe ff ff <0f> 0b eb fe 0f 1f 80 00 00 00 00 65 48 8b 14 25 c8 cc 00 00 48
> RIP [<ffffffffa0325b95>] walk_up_proc+0x375/0x420 [btrfs]
> RSP <ffff8801801eb9c8>
>
>
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: kernel BUG at fs/btrfs/extent-tree.c:6164!
2011-06-07 5:31 ` liubo
@ 2011-06-07 5:59 ` Tsutomu Itoh
2011-06-07 6:17 ` Tsutomu Itoh
0 siblings, 1 reply; 19+ messages in thread
From: Tsutomu Itoh @ 2011-06-07 5:59 UTC (permalink / raw)
To: liubo; +Cc: Linux Btrfs, Chris Mason
Hi liubo,
(2011/06/07 14:31), liubo wrote:
> On 06/06/2011 04:33 PM, Tsutomu Itoh wrote:
>> Hi,
>>
>> I encountered following panic using 'btrfs-unstable + for-linus'
>> kernel.
>>
>> I ran "btrfs fi bal /test5" command, and mount option of /test5
>> is as follows:
>>
>> /dev/sdc3 on /test5 type btrfs (rw,space_cache,compress=lzo,inode_cache)
>>
>
> So, just a "btrfs fi bal" would lead to the bug?
I think so.
>
> I've figured out the warnings, but not reproduced the bug yet...
> I used 'btrfs-unstable + for-linus" whose top commit is
>
> commit aa0467d8d2a00e75b2bb6a56a4ee6d70c5d1928f
> Author: David Sterba <dsterba@suse.cz>
> Date: Fri Jun 3 16:29:08 2011 +0200
>
> btrfs: fix uninitialized variable warning
It's same of my environment.
>
> and tried on 1) a single disk, 2) 2 disks and 3) 4 disks respectively,
> but none of them leaded to the below bug.
The test script and the volume composition that I am executing are
same as following mail.
http://marc.info/?l=linux-btrfs&m=130680171426371&w=2
and, in my environment, panic is done within almost 30 minutes when
test script is executed.
Thanks,
Tsutomu
>
> I guess maybe I miss something to reproduce it?
>
> thanks,
> liubo
>
>> Thanks,
>> Tsutomu
>>
>> =================================================================
>>
>> btrfs: relocating block group 23383244800 flags 20
>> btrfs: found 2959 extents
>> ------------[ cut here ]------------
>> WARNING: at fs/btrfs/transaction.c:213 start_transaction+0x2a7/0x2b0 [btrfs]()
>> Hardware name: PRIMERGY
>> Modules linked in: autofs4 sunrpc 8021q garp stp llc cpufreq_ondemand acpi_cpufr
>> eq freq_table mperf ipv6 btrfs zlib_deflate crc32c libcrc32c ext3 jbd dm_mirror
>> dm_region_hash dm_log dm_mod kvm uinput ppdev parport_pc parport sg pcspkr i2c_i
>> 801 i2c_core iTCO_wdt iTCO_vendor_support tg3 shpchp pci_hotplug i3000_edac edac
>> _core ext4 mbcache jbd2 crc16 sd_mod crc_t10dif sr_mod cdrom megaraid_sas pata_a
>> cpi ata_generic ata_piix libata scsi_mod floppy [last unloaded: microcode]
>> Pid: 23781, comm: btrfs Tainted: G W 2.6.39btrfs-test+ #4
>> Call Trace:
>> [<ffffffff8106004f>] warn_slowpath_common+0x7f/0xc0
>> [<ffffffff810600aa>] warn_slowpath_null+0x1a/0x20
>> [<ffffffffa0337047>] start_transaction+0x2a7/0x2b0 [btrfs]
>> [<ffffffffa035498d>] ? btrfs_wait_ordered_range+0x10d/0x160 [btrfs]
>> [<ffffffffa0337323>] btrfs_start_transaction+0x13/0x20 [btrfs]
>> [<ffffffffa033bbca>] btrfs_evict_inode+0x11a/0x260 [btrfs]
>> [<ffffffff811687f8>] evict+0x78/0x170
>> [<ffffffff81168c92>] iput+0xe2/0x1a0
>> [<ffffffffa031f171>] btrfs_remove_block_group+0x141/0x3c0 [btrfs]
>> [<ffffffffa035e6ea>] btrfs_relocate_chunk+0x54a/0x670 [btrfs]
>> [<ffffffffa0357668>] ? read_extent_buffer+0xd8/0x1d0 [btrfs]
>> [<ffffffffa031be51>] ? btrfs_previous_item+0xb1/0x150 [btrfs]
>> [<ffffffffa035f43a>] btrfs_balance+0x21a/0x2b0 [btrfs]
>> [<ffffffff8115dc41>] ? path_openat+0x101/0x3d0
>> [<ffffffffa03685bc>] btrfs_ioctl+0x51c/0xc40 [btrfs]
>> [<ffffffff8111e358>] ? handle_mm_fault+0x148/0x270
>> [<ffffffff814809e8>] ? do_page_fault+0x1d8/0x4b0
>> [<ffffffff81160d6a>] do_vfs_ioctl+0x9a/0x540
>> [<ffffffff811612b1>] sys_ioctl+0xa1/0xb0
>> [<ffffffff81484ec2>] system_call_fastpath+0x16/0x1b
>> ---[ end trace e5c5cb2e98a3cd1a ]---
>> btrfs: relocating block group 20971520 flags 18
>> btrfs: relocating block group 34925969408 flags 18
>> btrfs: found 1 extents
>> ------------[ cut here ]------------
>> kernel BUG at fs/btrfs/extent-tree.c:6164!
>> invalid opcode: 0000 [#1] SMP
>> last sysfs file: /sys/kernel/mm/ksm/run
>> CPU 0
>> Modules linked in: autofs4 sunrpc 8021q garp stp llc cpufreq_ondemand acpi_cpufreq freq_table mperf ipv6 btrfs zlib_deflate crc32c libcrc32c ext3 jbd dm_mirror dm_region_hash dm_log dm_mod kvm uinput ppdev parport_pc parport sg pcspkr i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support tg3 shpchp pci_hotplug i3000_edac edac_core ext4 mbcache jbd2 crc16 sd_mod crc_t10dif sr_mod cdrom megaraid_sas pata_acpi ata_generic ata_piix libata scsi_mod floppy [last unloaded: microcode]
>>
>> Pid: 4109, comm: btrfs Tainted: G W 2.6.39btrfs-test+ #4 FUJITSU-SV PRIMERGY /D2399
>> RIP: 0010:[<ffffffffa0325b95>] [<ffffffffa0325b95>] walk_up_proc+0x375/0x420 [btrfs]
>> RSP: 0018:ffff8801801eb9c8 EFLAGS: 00010286
>> RAX: 0000000000000005 RBX: ffff880167a70140 RCX: fffffffffffffff8
>> RDX: ffff8801801ea000 RSI: ffff880000000000 RDI: ffff880194909fa8
>> RBP: ffff8801801eba18 R08: 0000000000000000 R09: 0000000000000005
>> R10: 0000000000000001 R11: ffff880194909fa8 R12: 0000000000000000
>> R13: ffff88013973d000 R14: ffff88015ad4d9a0 R15: ffff880042203920
>> FS: 00007fa86bcb9740(0000) GS:ffff88019fc00000(0000) knlGS:0000000000000000
>> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>> CR2: 00000033cf60b0c0 CR3: 0000000181cf7000 CR4: 00000000000006f0
>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> Process btrfs (pid: 4109, threadinfo ffff8801801ea000, task ffff88011a4914a0)
>> Stack:
>> ffff8801801eba18 ffff880194909fa8 ffff880100000000 ffffffffa03280e8
>> ffff8801801eba58 ffff88015ad4d9a0 0000000000000000 0000000000000000
>> ffff8801801ea000 ffff880167a70140 ffff8801801eba78 ffffffffa0325d71
>> Call Trace:
>> [<ffffffffa03280e8>] ? btrfs_run_delayed_refs+0xc8/0x210 [btrfs]
>> [<ffffffffa0325d71>] walk_up_tree+0x131/0x1b0 [btrfs]
>> [<ffffffffa03260b0>] btrfs_drop_snapshot+0x2c0/0x5c0 [btrfs]
>> [<ffffffffa03328b0>] ? btrfs_read_fs_root_no_name+0x1b0/0x280 [btrfs]
>> [<ffffffffa037b45f>] merge_reloc_roots+0xdf/0x150 [btrfs]
>> [<ffffffffa037f311>] relocate_block_group+0x481/0x660 [btrfs]
>> [<ffffffffa0334d15>] ? btrfs_clean_old_snapshots+0x35/0x150 [btrfs]
>> [<ffffffffa037f6a3>] btrfs_relocate_block_group+0x1b3/0x2e0 [btrfs]
>> [<ffffffffa0368d80>] ? btrfs_tree_unlock+0x50/0x50 [btrfs]
>> [<ffffffffa035e22b>] btrfs_relocate_chunk+0x8b/0x670 [btrfs]
>> [<ffffffffa031303d>] ? btrfs_set_path_blocking+0x3d/0x50 [btrfs]
>> [<ffffffffa0357668>] ? read_extent_buffer+0xd8/0x1d0 [btrfs]
>> [<ffffffffa031be51>] ? btrfs_previous_item+0xb1/0x150 [btrfs]
>> [<ffffffffa0357668>] ? read_extent_buffer+0xd8/0x1d0 [btrfs]
>> [<ffffffffa035f43a>] btrfs_balance+0x21a/0x2b0 [btrfs]
>> [<ffffffff8115dc41>] ? path_openat+0x101/0x3d0
>> [<ffffffffa03685bc>] btrfs_ioctl+0x51c/0xc40 [btrfs]
>> [<ffffffff8111e358>] ? handle_mm_fault+0x148/0x270
>> [<ffffffff814809e8>] ? do_page_fault+0x1d8/0x4b0
>> [<ffffffff81160d6a>] do_vfs_ioctl+0x9a/0x540
>> [<ffffffff811612b1>] sys_ioctl+0xa1/0xb0
>> [<ffffffff81484ec2>] system_call_fastpath+0x16/0x1b
>> Code: fe ff ff 0f 1f 00 4c 89 df 31 c9 4c 89 fa 4c 89 ee 44 89 55 c0 4c 89 5d b8 e8 c8 d5 ff ff 4c 8b 5d b8 44 8b 55 c0 e9 85 fe ff ff <0f> 0b eb fe 0f 1f 80 00 00 00 00 65 48 8b 14 25 c8 cc 00 00 48
>> RIP [<ffffffffa0325b95>] walk_up_proc+0x375/0x420 [btrfs]
>> RSP <ffff8801801eb9c8>
>>
>>
>>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: kernel BUG at fs/btrfs/extent-tree.c:6164!
2011-06-07 5:59 ` Tsutomu Itoh
@ 2011-06-07 6:17 ` Tsutomu Itoh
2011-06-07 8:24 ` Tsutomu Itoh
0 siblings, 1 reply; 19+ messages in thread
From: Tsutomu Itoh @ 2011-06-07 6:17 UTC (permalink / raw)
To: liubo; +Cc: Linux Btrfs, Chris Mason
(2011/06/07 14:59), Tsutomu Itoh wrote:
> Hi liubo,
>
> (2011/06/07 14:31), liubo wrote:
>> On 06/06/2011 04:33 PM, Tsutomu Itoh wrote:
>>> Hi,
>>>
>>> I encountered following panic using 'btrfs-unstable + for-linus'
>>> kernel.
>>>
>>> I ran "btrfs fi bal /test5" command, and mount option of /test5
>>> is as follows:
>>>
>>> /dev/sdc3 on /test5 type btrfs (rw,space_cache,compress=lzo,inode_cache)
>>>
>>
>> So, just a "btrfs fi bal" would lead to the bug?
>
> I think so.
>
>>
>> I've figured out the warnings, but not reproduced the bug yet...
>> I used 'btrfs-unstable + for-linus" whose top commit is
>>
>> commit aa0467d8d2a00e75b2bb6a56a4ee6d70c5d1928f
>> Author: David Sterba <dsterba@suse.cz>
>> Date: Fri Jun 3 16:29:08 2011 +0200
>>
>> btrfs: fix uninitialized variable warning
>
> It's same of my environment.
>
>>
>> and tried on 1) a single disk, 2) 2 disks and 3) 4 disks respectively,
>> but none of them leaded to the below bug.
>
> The test script and the volume composition that I am executing are
> same as following mail.
>
> http://marc.info/?l=linux-btrfs&m=130680171426371&w=2
>
> and, in my environment, panic is done within almost 30 minutes when
> test script is executed.
Another panic occurred when I executed it again.
device fsid 794aee8608a3c563-e4baafe1f4d8eba5 devid 5 transid 4 /dev/sdc8
device fsid 794aee8608a3c563-e4baafe1f4d8eba5 devid 1 transid 7 /dev/sdc3
btrfs: enabling disk space caching
btrfs: use lzo compression
btrfs: enabling inode map caching
device fsid 624604c4bdf670bb-1c9404b53abaa6a3 devid 1 transid 7 /dev/sdd4
btrfs: disk space caching is enabled
btrfs: relocating block group 1103101952 flags 9
btrfs: found 540 extents
btrfs: found 540 extents
------------[ cut here ]------------
kernel BUG at fs/btrfs/extent-tree.c:1424!
invalid opcode: 0000 [#1] SMP
last sysfs file: /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:03.0/host4/target4:2:3/4:2:3:0/block/sdd/sdd4/alignment_offset
CPU 0
Modules linked in: autofs4 sunrpc 8021q garp stp llc cpufreq_ondemand acpi_cpufreq freq_table mperf ipv6 btrfs zlib_deflate crc32c libcrc32c ext3 jbd dm_mirror dm_region_hash dm_log dm_mod kvm uinput ppdev parport_pc parport sg pcspkr i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support tg3 shpchp pci_hotplug i3000_edac edac_core ext4 mbcache jbd2 crc16 sd_mod crc_t10dif sr_mod cdrom megaraid_sas pata_acpi ata_generic ata_piix libata scsi_mod floppy [last unloaded: microcode]
Pid: 3849, comm: btrfs Not tainted 2.6.39btrfs-test+ #4 FUJITSU-SV PRIMERGY /D2399
RIP: 0010:[<ffffffffa0325422>] [<ffffffffa0325422>] lookup_inline_extent_backref+0x2d2/0x3f0 [btrfs]
RSP: 0018:ffff880156d2d7b8 EFLAGS: 00010202
RAX: 0000000000000001 RBX: ffff8801947f3e20 RCX: ffff880156d2c000
RDX: 0000000000000008 RSI: ffff880000000000 RDI: 0000000000000000
RBP: ffff880156d2d858 R08: 0000000000000000 R09: 0000000000000283
R10: 0000000000000000 R11: 0000000000000015 R12: 00000000000000b2
R13: ffff88019474b4f8 R14: 0000000000000001 R15: 00000000ffffffff
FS: 00007faaf3753740(0000) GS:ffff88019fc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00000000017bfea0 CR3: 0000000156e53000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process btrfs (pid: 3849, threadinfo ffff880156d2c000, task ffff880192a04ab0)
Stack:
ffff880193893000 0000000000001000 ffff880156d2d808 ffff880156d2d920
ffff880156d2d808 0000000181f61000 0000000000000000 ffff880193893000
0000000000000001 ffff880156d2da18 0000000181f61000 00000000009000a8
Call Trace:
[<ffffffffa03271d6>] __btrfs_free_extent+0xd6/0x730 [btrfs]
[<ffffffffa0356960>] ? map_extent_buffer+0xb0/0xc0 [btrfs]
[<ffffffffa0326d19>] ? update_block_group+0xd9/0x2a0 [btrfs]
[<ffffffffa0327ed8>] run_clustered_refs+0x6a8/0x7f0 [btrfs]
[<ffffffffa03280e8>] btrfs_run_delayed_refs+0xc8/0x210 [btrfs]
[<ffffffffa033638d>] btrfs_commit_transaction+0x7d/0x790 [btrfs]
[<ffffffffa0335ac5>] ? join_transaction+0x25/0x250 [btrfs]
[<ffffffff81081de0>] ? wake_up_bit+0x40/0x40
[<ffffffffa037f377>] relocate_block_group+0x4e7/0x660 [btrfs]
[<ffffffffa0334d15>] ? btrfs_clean_old_snapshots+0x35/0x150 [btrfs]
[<ffffffffa037f6a3>] btrfs_relocate_block_group+0x1b3/0x2e0 [btrfs]
[<ffffffffa0368d80>] ? btrfs_tree_unlock+0x50/0x50 [btrfs]
[<ffffffffa035e22b>] btrfs_relocate_chunk+0x8b/0x670 [btrfs]
[<ffffffffa031303d>] ? btrfs_set_path_blocking+0x3d/0x50 [btrfs]
[<ffffffffa0357668>] ? read_extent_buffer+0xd8/0x1d0 [btrfs]
[<ffffffffa031be51>] ? btrfs_previous_item+0xb1/0x150 [btrfs]
[<ffffffffa0357668>] ? read_extent_buffer+0xd8/0x1d0 [btrfs]
[<ffffffffa035f43a>] btrfs_balance+0x21a/0x2b0 [btrfs]
[<ffffffff8115dc41>] ? path_openat+0x101/0x3d0
[<ffffffffa03685bc>] btrfs_ioctl+0x51c/0xc40 [btrfs]
[<ffffffff8111e358>] ? handle_mm_fault+0x148/0x270
[<ffffffff814809e8>] ? do_page_fault+0x1d8/0x4b0
[<ffffffff81160d6a>] do_vfs_ioctl+0x9a/0x540
[<ffffffff811612b1>] sys_ioctl+0xa1/0xb0
[<ffffffff81484ec2>] system_call_fastpath+0x16/0x1b
Code: 48 8b 75 20 48 89 c3 48 8b 7d 18 e8 c9 bd ff ff 48 39 d8 77 26 b8 1d 00 00 00 e9 15 ff ff ff a8 01 0f 85 8c fe ff ff 0f 0b eb fe <0f> 0b eb fe 0f 0b 0f 1f 84 00 00 00 00 00 eb f6 4c 89 fb 44 8b
RIP [<ffffffffa0325422>] lookup_inline_extent_backref+0x2d2/0x3f0 [btrfs]
RSP <ffff880156d2d7b8>
>
> Thanks,
> Tsutomu
>
>>
>> I guess maybe I miss something to reproduce it?
>>
>> thanks,
>> liubo
>>
>>> Thanks,
>>> Tsutomu
>>>
>>> =================================================================
>>>
>>> btrfs: relocating block group 23383244800 flags 20
>>> btrfs: found 2959 extents
>>> ------------[ cut here ]------------
>>> WARNING: at fs/btrfs/transaction.c:213 start_transaction+0x2a7/0x2b0 [btrfs]()
>>> Hardware name: PRIMERGY
>>> Modules linked in: autofs4 sunrpc 8021q garp stp llc cpufreq_ondemand acpi_cpufr
>>> eq freq_table mperf ipv6 btrfs zlib_deflate crc32c libcrc32c ext3 jbd dm_mirror
>>> dm_region_hash dm_log dm_mod kvm uinput ppdev parport_pc parport sg pcspkr i2c_i
>>> 801 i2c_core iTCO_wdt iTCO_vendor_support tg3 shpchp pci_hotplug i3000_edac edac
>>> _core ext4 mbcache jbd2 crc16 sd_mod crc_t10dif sr_mod cdrom megaraid_sas pata_a
>>> cpi ata_generic ata_piix libata scsi_mod floppy [last unloaded: microcode]
>>> Pid: 23781, comm: btrfs Tainted: G W 2.6.39btrfs-test+ #4
>>> Call Trace:
>>> [<ffffffff8106004f>] warn_slowpath_common+0x7f/0xc0
>>> [<ffffffff810600aa>] warn_slowpath_null+0x1a/0x20
>>> [<ffffffffa0337047>] start_transaction+0x2a7/0x2b0 [btrfs]
>>> [<ffffffffa035498d>] ? btrfs_wait_ordered_range+0x10d/0x160 [btrfs]
>>> [<ffffffffa0337323>] btrfs_start_transaction+0x13/0x20 [btrfs]
>>> [<ffffffffa033bbca>] btrfs_evict_inode+0x11a/0x260 [btrfs]
>>> [<ffffffff811687f8>] evict+0x78/0x170
>>> [<ffffffff81168c92>] iput+0xe2/0x1a0
>>> [<ffffffffa031f171>] btrfs_remove_block_group+0x141/0x3c0 [btrfs]
>>> [<ffffffffa035e6ea>] btrfs_relocate_chunk+0x54a/0x670 [btrfs]
>>> [<ffffffffa0357668>] ? read_extent_buffer+0xd8/0x1d0 [btrfs]
>>> [<ffffffffa031be51>] ? btrfs_previous_item+0xb1/0x150 [btrfs]
>>> [<ffffffffa035f43a>] btrfs_balance+0x21a/0x2b0 [btrfs]
>>> [<ffffffff8115dc41>] ? path_openat+0x101/0x3d0
>>> [<ffffffffa03685bc>] btrfs_ioctl+0x51c/0xc40 [btrfs]
>>> [<ffffffff8111e358>] ? handle_mm_fault+0x148/0x270
>>> [<ffffffff814809e8>] ? do_page_fault+0x1d8/0x4b0
>>> [<ffffffff81160d6a>] do_vfs_ioctl+0x9a/0x540
>>> [<ffffffff811612b1>] sys_ioctl+0xa1/0xb0
>>> [<ffffffff81484ec2>] system_call_fastpath+0x16/0x1b
>>> ---[ end trace e5c5cb2e98a3cd1a ]---
>>> btrfs: relocating block group 20971520 flags 18
>>> btrfs: relocating block group 34925969408 flags 18
>>> btrfs: found 1 extents
>>> ------------[ cut here ]------------
>>> kernel BUG at fs/btrfs/extent-tree.c:6164!
>>> invalid opcode: 0000 [#1] SMP
>>> last sysfs file: /sys/kernel/mm/ksm/run
>>> CPU 0
>>> Modules linked in: autofs4 sunrpc 8021q garp stp llc cpufreq_ondemand acpi_cpufreq freq_table mperf ipv6 btrfs zlib_deflate crc32c libcrc32c ext3 jbd dm_mirror dm_region_hash dm_log dm_mod kvm uinput ppdev parport_pc parport sg pcspkr i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support tg3 shpchp pci_hotplug i3000_edac edac_core ext4 mbcache jbd2 crc16 sd_mod crc_t10dif sr_mod cdrom megaraid_sas pata_acpi ata_generic ata_piix libata scsi_mod floppy [last unloaded: microcode]
>>>
>>> Pid: 4109, comm: btrfs Tainted: G W 2.6.39btrfs-test+ #4 FUJITSU-SV PRIMERGY /D2399
>>> RIP: 0010:[<ffffffffa0325b95>] [<ffffffffa0325b95>] walk_up_proc+0x375/0x420 [btrfs]
>>> RSP: 0018:ffff8801801eb9c8 EFLAGS: 00010286
>>> RAX: 0000000000000005 RBX: ffff880167a70140 RCX: fffffffffffffff8
>>> RDX: ffff8801801ea000 RSI: ffff880000000000 RDI: ffff880194909fa8
>>> RBP: ffff8801801eba18 R08: 0000000000000000 R09: 0000000000000005
>>> R10: 0000000000000001 R11: ffff880194909fa8 R12: 0000000000000000
>>> R13: ffff88013973d000 R14: ffff88015ad4d9a0 R15: ffff880042203920
>>> FS: 00007fa86bcb9740(0000) GS:ffff88019fc00000(0000) knlGS:0000000000000000
>>> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>>> CR2: 00000033cf60b0c0 CR3: 0000000181cf7000 CR4: 00000000000006f0
>>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>>> Process btrfs (pid: 4109, threadinfo ffff8801801ea000, task ffff88011a4914a0)
>>> Stack:
>>> ffff8801801eba18 ffff880194909fa8 ffff880100000000 ffffffffa03280e8
>>> ffff8801801eba58 ffff88015ad4d9a0 0000000000000000 0000000000000000
>>> ffff8801801ea000 ffff880167a70140 ffff8801801eba78 ffffffffa0325d71
>>> Call Trace:
>>> [<ffffffffa03280e8>] ? btrfs_run_delayed_refs+0xc8/0x210 [btrfs]
>>> [<ffffffffa0325d71>] walk_up_tree+0x131/0x1b0 [btrfs]
>>> [<ffffffffa03260b0>] btrfs_drop_snapshot+0x2c0/0x5c0 [btrfs]
>>> [<ffffffffa03328b0>] ? btrfs_read_fs_root_no_name+0x1b0/0x280 [btrfs]
>>> [<ffffffffa037b45f>] merge_reloc_roots+0xdf/0x150 [btrfs]
>>> [<ffffffffa037f311>] relocate_block_group+0x481/0x660 [btrfs]
>>> [<ffffffffa0334d15>] ? btrfs_clean_old_snapshots+0x35/0x150 [btrfs]
>>> [<ffffffffa037f6a3>] btrfs_relocate_block_group+0x1b3/0x2e0 [btrfs]
>>> [<ffffffffa0368d80>] ? btrfs_tree_unlock+0x50/0x50 [btrfs]
>>> [<ffffffffa035e22b>] btrfs_relocate_chunk+0x8b/0x670 [btrfs]
>>> [<ffffffffa031303d>] ? btrfs_set_path_blocking+0x3d/0x50 [btrfs]
>>> [<ffffffffa0357668>] ? read_extent_buffer+0xd8/0x1d0 [btrfs]
>>> [<ffffffffa031be51>] ? btrfs_previous_item+0xb1/0x150 [btrfs]
>>> [<ffffffffa0357668>] ? read_extent_buffer+0xd8/0x1d0 [btrfs]
>>> [<ffffffffa035f43a>] btrfs_balance+0x21a/0x2b0 [btrfs]
>>> [<ffffffff8115dc41>] ? path_openat+0x101/0x3d0
>>> [<ffffffffa03685bc>] btrfs_ioctl+0x51c/0xc40 [btrfs]
>>> [<ffffffff8111e358>] ? handle_mm_fault+0x148/0x270
>>> [<ffffffff814809e8>] ? do_page_fault+0x1d8/0x4b0
>>> [<ffffffff81160d6a>] do_vfs_ioctl+0x9a/0x540
>>> [<ffffffff811612b1>] sys_ioctl+0xa1/0xb0
>>> [<ffffffff81484ec2>] system_call_fastpath+0x16/0x1b
>>> Code: fe ff ff 0f 1f 00 4c 89 df 31 c9 4c 89 fa 4c 89 ee 44 89 55 c0 4c 89 5d b8 e8 c8 d5 ff ff 4c 8b 5d b8 44 8b 55 c0 e9 85 fe ff ff <0f> 0b eb fe 0f 1f 80 00 00 00 00 65 48 8b 14 25 c8 cc 00 00 48
>>> RIP [<ffffffffa0325b95>] walk_up_proc+0x375/0x420 [btrfs]
>>> RSP <ffff8801801eb9c8>
>>>
>>>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: kernel BUG at fs/btrfs/extent-tree.c:6164!
2011-06-07 6:17 ` Tsutomu Itoh
@ 2011-06-07 8:24 ` Tsutomu Itoh
2011-06-07 8:36 ` liubo
0 siblings, 1 reply; 19+ messages in thread
From: Tsutomu Itoh @ 2011-06-07 8:24 UTC (permalink / raw)
To: liubo; +Cc: Linux Btrfs, Chris Mason
(2011/06/07 15:17), Tsutomu Itoh wrote:
> (2011/06/07 14:59), Tsutomu Itoh wrote:
>> Hi liubo,
>>
>> (2011/06/07 14:31), liubo wrote:
>>> On 06/06/2011 04:33 PM, Tsutomu Itoh wrote:
>>>> Hi,
>>>>
>>>> I encountered following panic using 'btrfs-unstable + for-linus'
>>>> kernel.
>>>>
>>>> I ran "btrfs fi bal /test5" command, and mount option of /test5
>>>> is as follows:
>>>>
>>>> /dev/sdc3 on /test5 type btrfs (rw,space_cache,compress=lzo,inode_cache)
>>>>
>>>
>>> So, just a "btrfs fi bal" would lead to the bug?
>>
>> I think so.
>>
>>>
>>> I've figured out the warnings, but not reproduced the bug yet...
>>> I used 'btrfs-unstable + for-linus" whose top commit is
>>>
>>> commit aa0467d8d2a00e75b2bb6a56a4ee6d70c5d1928f
>>> Author: David Sterba <dsterba@suse.cz>
>>> Date: Fri Jun 3 16:29:08 2011 +0200
>>>
>>> btrfs: fix uninitialized variable warning
>>
>> It's same of my environment.
>>
>>>
>>> and tried on 1) a single disk, 2) 2 disks and 3) 4 disks respectively,
>>> but none of them leaded to the below bug.
>>
>> The test script and the volume composition that I am executing are
>> same as following mail.
>>
>> http://marc.info/?l=linux-btrfs&m=130680171426371&w=2
>>
>> and, in my environment, panic is done within almost 30 minutes when
>> test script is executed.
I forgot to write.
I am adding '-o inode_cache' to the mount option in my test script.
>
> Another panic occurred when I executed it again.
>
I rebuilt the kernel with 3.0-rc2. but, same problem occurred.
<4>[ 131.708325] WARNING: at fs/btrfs/transaction.c:213 start_transaction+0x74/0x259 [btrfs]()
<4>[ 131.708329] Hardware name: PRIMERGY
<4>[ 131.708330] Modules linked in: autofs4 sunrpc 8021q garp stp llc cpufreq_ondemand acpi_cpufreq freq_table mperf ipv6 btrfs zlib_deflate crc32c libcrc32c ext3 jbd dm_mirror dm_region_hash dm_log dm_mod kvm uinput ppdev parport_pc parport sg pcspkr i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support tg3 shpchp pci_hotplug i3000_edac edac_core ext4 mbcache jbd2 crc16 sd_mod crc_t10dif sr_mod cdrom megaraid_sas pata_acpi ata_generic ata_piix libata scsi_mod floppy [last unloaded: microcode]
<4>[ 131.708378] Pid: 3041, comm: btrfs Not tainted 3.0.0-rc2test #1
<4>[ 131.708381] Call Trace:
<4>[ 131.708388] [<ffffffff8104514a>] warn_slowpath_common+0x85/0x9d
<4>[ 131.708392] [<ffffffff8104517c>] warn_slowpath_null+0x1a/0x1c
<4>[ 131.708410] [<ffffffffa02a6f8b>] start_transaction+0x74/0x259 [btrfs]
<4>[ 131.708430] [<ffffffffa02bf965>] ? btrfs_wait_ordered_range+0xf9/0x11d [btrfs]
<4>[ 131.708448] [<ffffffffa02a73ed>] btrfs_start_transaction+0x13/0x15 [btrfs]
<4>[ 131.708467] [<ffffffffa02aec08>] btrfs_evict_inode+0x113/0x22d [btrfs]
<4>[ 131.708471] [<ffffffff81123a98>] evict+0x77/0x118
<4>[ 131.708475] [<ffffffff81123ec1>] iput+0x13d/0x146
<4>[ 131.708489] [<ffffffffa02939c9>] btrfs_remove_block_group+0x14d/0x35b [btrfs]
<4>[ 131.708508] [<ffffffffa02c6ff7>] btrfs_relocate_chunk+0x464/0x50d [btrfs]
<4>[ 131.708527] [<ffffffffa02c54ce>] ? btrfs_item_key_to_cpu+0x2a/0x46 [btrfs]
<4>[ 131.708545] [<ffffffffa02c7672>] btrfs_balance+0x1ca/0x219 [btrfs]
<4>[ 131.708563] [<ffffffffa02cfbfd>] btrfs_ioctl+0x890/0xb87 [btrfs]
<4>[ 131.708567] [<ffffffff810e87c8>] ? handle_mm_fault+0x233/0x24a
<4>[ 131.708572] [<ffffffff813a6e25>] ? do_page_fault+0x340/0x3b2
<4>[ 131.708577] [<ffffffff8111d6f8>] do_vfs_ioctl+0x474/0x4c3
<4>[ 131.708581] [<ffffffff810ffd25>] ? virt_to_head_page+0xe/0x31
<4>[ 131.708585] [<ffffffff81100fcc>] ? kmem_cache_free+0x20/0xae
<4>[ 131.708588] [<ffffffff8111d79d>] sys_ioctl+0x56/0x79
<4>[ 131.708592] [<ffffffff813aa542>] system_call_fastpath+0x16/0x1b
<4>[ 131.708595] ---[ end trace 5f962f46d3ba5425 ]---
<6>[ 131.708777] btrfs: relocating block group 29360128 flags 20
<6>[ 132.385682] btrfs: found 85 extents
<0>[ 132.798892] ------------[ cut here ]------------
<2>[ 132.799014] kernel BUG at fs/btrfs/extent-tree.c:1424!
<0>[ 132.799014] invalid opcode: 0000 [#1] SMP
<4>[ 132.799014] CPU 0
<4>[ 132.799014] Modules linked in: autofs4 sunrpc 8021q garp stp llc cpufreq_ondemand acpi_cpufreq freq_table mperf ipv6 btrfs zlib_deflate crc32c libcrc32c ext3 jbd dm_mirror dm_region_hash dm_log dm_mod kvm uinput ppdev parport_pc parport sg pcspkr i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support tg3 shpchp pci_hotplug i3000_edac edac_core ext4 mbcache jbd2 crc16 sd_mod crc_t10dif sr_mod cdrom megaraid_sas pata_acpi ata_generic ata_piix libata scsi_mod floppy [last unloaded: microcode]
<4>[ 132.799014]
<4>[ 132.799014] Pid: 3041, comm: btrfs Tainted: G W 3.0.0-rc2test #1 FUJITSU-SV PRIMERGY /D2399
<4>[ 132.799014] RIP: 0010:[<ffffffffa0296c86>] [<ffffffffa0296c86>] lookup_inline_extent_backref+0xe3/0x3a9 [btrfs]
<4>[ 132.799014] RSP: 0018:ffff880193aa5808 EFLAGS: 00010202
<4>[ 132.799014] RAX: 0000000000000001 RBX: ffff880192fac000 RCX: 0000000000000002
<4>[ 132.799014] RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000
<4>[ 132.799014] RBP: ffff880193aa58a8 R08: 000000000000029c R09: ffff880193aa56f0
<4>[ 132.799014] R10: ffff880193aa5648 R11: c2d107e744029d66 R12: 00000000000000b2
<4>[ 132.799014] R13: ffff880195075b88 R14: 0000000000000001 R15: 0000000000000000
<4>[ 132.799014] FS: 00007faaaf421740(0000) GS:ffff88019fc00000(0000) knlGS:0000000000000000
<4>[ 132.799014] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
<4>[ 132.799014] CR2: 00000033cfeda340 CR3: 00000001946b5000 CR4: 00000000000006f0
<4>[ 132.799014] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
<4>[ 132.799014] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
<4>[ 132.799014] Process btrfs (pid: 3041, threadinfo ffff880193aa4000, task ffff88019463ad80)
<0>[ 132.799014] Stack:
<4>[ 132.799014] ffff880192a0fa00 0000000000001000 ffff880194640000 ffff880193aa5950
<4>[ 132.799014] ffff880193aa5848 0000000181f65000 ffff880193aa5848 ffff880193e24000
<4>[ 132.799014] ffffffff93aa5898 ffffffff81101372 0000000181f65000 00000000009000a8
<0>[ 132.799014] Call Trace:
<4>[ 132.799014] [<ffffffff81101372>] ? kmem_cache_alloc+0x27/0xee
<4>[ 132.799014] [<ffffffffa0299a58>] __btrfs_free_extent+0xc8/0x57f [btrfs]
<4>[ 132.799014] [<ffffffff81100f64>] ? kfree+0xbd/0xdd
<4>[ 132.799014] [<ffffffffa029a5a9>] run_clustered_refs+0x69a/0x6fa [btrfs]
<4>[ 132.799014] [<ffffffffa029a6d7>] btrfs_run_delayed_refs+0xce/0x17c [btrfs]
<4>[ 132.799014] [<ffffffffa02a66ac>] btrfs_commit_transaction+0x7e/0x674 [btrfs]
<4>[ 132.799014] [<ffffffffa02a5fb0>] ? join_transaction+0x24/0x213 [btrfs]
<4>[ 132.799014] [<ffffffff8106085d>] ? wake_up_bit+0x2a/0x2a
<4>[ 132.799014] [<ffffffffa02e1b3f>] relocate_block_group+0x4f3/0x51a [btrfs]
<4>[ 132.799014] [<ffffffffa02a544d>] ? btrfs_clean_old_snapshots+0x35/0x127 [btrfs]
<4>[ 132.799014] [<ffffffffa02e1cb1>] btrfs_relocate_block_group+0x14b/0x282 [btrfs]
<4>[ 132.799014] [<ffffffffa02c7037>] ? btrfs_relocate_chunk+0x4a4/0x50d [btrfs]
<4>[ 132.799014] [<ffffffffa02c6bfc>] btrfs_relocate_chunk+0x69/0x50d [btrfs]
<4>[ 132.799014] [<ffffffffa028b3e1>] ? btrfs_item_key_to_cpu+0x1a/0x36 [btrfs]
<4>[ 132.799014] [<ffffffffa02c0bc3>] ? read_extent_buffer+0xba/0xf6 [btrfs]
<4>[ 132.799014] [<ffffffffa02c54ce>] ? btrfs_item_key_to_cpu+0x2a/0x46 [btrfs]
<4>[ 132.799014] [<ffffffffa02c7672>] btrfs_balance+0x1ca/0x219 [btrfs]
<4>[ 132.799014] [<ffffffffa02cfbfd>] btrfs_ioctl+0x890/0xb87 [btrfs]
<4>[ 132.799014] [<ffffffff810e87c8>] ? handle_mm_fault+0x233/0x24a
<4>[ 132.799014] [<ffffffff813a6e25>] ? do_page_fault+0x340/0x3b2
<4>[ 132.799014] [<ffffffff8111d6f8>] do_vfs_ioctl+0x474/0x4c3
<4>[ 132.799014] [<ffffffff810ffd25>] ? virt_to_head_page+0xe/0x31
<4>[ 132.799014] [<ffffffff81100fcc>] ? kmem_cache_free+0x20/0xae
<4>[ 132.799014] [<ffffffff8111d79d>] sys_ioctl+0x56/0x79
<4>[ 132.799014] [<ffffffff813aa542>] system_call_fastpath+0x16/0x1b
<0>[ 132.799014] Code: 44 8b 45 a4 48 8b 75 98 48 8d 55 b0 41 b9 01 00 00 00 48 89 d9 4c 89 ef e8 54 96 ff ff 83 f8 00 41 89 c6 0f 8c 94 02 00 00 74 04 <0f> 0b eb fe 4c 8b 33 8b 73 40 4c 89 f7 e8 9d ea ff ff 41 89 c7
<1>[ 132.799014] RIP [<ffffffffa0296c86>] lookup_inline_extent_backref+0xe3/0x3a9 [btrfs]
<4>[ 132.799014] RSP <ffff880193aa5808>
RSP <ffff880193aa5808>
>
> device fsid 794aee8608a3c563-e4baafe1f4d8eba5 devid 5 transid 4 /dev/sdc8
> device fsid 794aee8608a3c563-e4baafe1f4d8eba5 devid 1 transid 7 /dev/sdc3
> btrfs: enabling disk space caching
> btrfs: use lzo compression
> btrfs: enabling inode map caching
> device fsid 624604c4bdf670bb-1c9404b53abaa6a3 devid 1 transid 7 /dev/sdd4
> btrfs: disk space caching is enabled
> btrfs: relocating block group 1103101952 flags 9
> btrfs: found 540 extents
> btrfs: found 540 extents
> ------------[ cut here ]------------
> kernel BUG at fs/btrfs/extent-tree.c:1424!
> invalid opcode: 0000 [#1] SMP
> last sysfs file: /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:03.0/host4/target4:2:3/4:2:3:0/block/sdd/sdd4/alignment_offset
> CPU 0
> Modules linked in: autofs4 sunrpc 8021q garp stp llc cpufreq_ondemand acpi_cpufreq freq_table mperf ipv6 btrfs zlib_deflate crc32c libcrc32c ext3 jbd dm_mirror dm_region_hash dm_log dm_mod kvm uinput ppdev parport_pc parport sg pcspkr i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support tg3 shpchp pci_hotplug i3000_edac edac_core ext4 mbcache jbd2 crc16 sd_mod crc_t10dif sr_mod cdrom megaraid_sas pata_acpi ata_generic ata_piix libata scsi_mod floppy [last unloaded: microcode]
>
> Pid: 3849, comm: btrfs Not tainted 2.6.39btrfs-test+ #4 FUJITSU-SV PRIMERGY /D2399
> RIP: 0010:[<ffffffffa0325422>] [<ffffffffa0325422>] lookup_inline_extent_backref+0x2d2/0x3f0 [btrfs]
> RSP: 0018:ffff880156d2d7b8 EFLAGS: 00010202
> RAX: 0000000000000001 RBX: ffff8801947f3e20 RCX: ffff880156d2c000
> RDX: 0000000000000008 RSI: ffff880000000000 RDI: 0000000000000000
> RBP: ffff880156d2d858 R08: 0000000000000000 R09: 0000000000000283
> R10: 0000000000000000 R11: 0000000000000015 R12: 00000000000000b2
> R13: ffff88019474b4f8 R14: 0000000000000001 R15: 00000000ffffffff
> FS: 00007faaf3753740(0000) GS:ffff88019fc00000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 00000000017bfea0 CR3: 0000000156e53000 CR4: 00000000000006f0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process btrfs (pid: 3849, threadinfo ffff880156d2c000, task ffff880192a04ab0)
> Stack:
> ffff880193893000 0000000000001000 ffff880156d2d808 ffff880156d2d920
> ffff880156d2d808 0000000181f61000 0000000000000000 ffff880193893000
> 0000000000000001 ffff880156d2da18 0000000181f61000 00000000009000a8
> Call Trace:
> [<ffffffffa03271d6>] __btrfs_free_extent+0xd6/0x730 [btrfs]
> [<ffffffffa0356960>] ? map_extent_buffer+0xb0/0xc0 [btrfs]
> [<ffffffffa0326d19>] ? update_block_group+0xd9/0x2a0 [btrfs]
> [<ffffffffa0327ed8>] run_clustered_refs+0x6a8/0x7f0 [btrfs]
> [<ffffffffa03280e8>] btrfs_run_delayed_refs+0xc8/0x210 [btrfs]
> [<ffffffffa033638d>] btrfs_commit_transaction+0x7d/0x790 [btrfs]
> [<ffffffffa0335ac5>] ? join_transaction+0x25/0x250 [btrfs]
> [<ffffffff81081de0>] ? wake_up_bit+0x40/0x40
> [<ffffffffa037f377>] relocate_block_group+0x4e7/0x660 [btrfs]
> [<ffffffffa0334d15>] ? btrfs_clean_old_snapshots+0x35/0x150 [btrfs]
> [<ffffffffa037f6a3>] btrfs_relocate_block_group+0x1b3/0x2e0 [btrfs]
> [<ffffffffa0368d80>] ? btrfs_tree_unlock+0x50/0x50 [btrfs]
> [<ffffffffa035e22b>] btrfs_relocate_chunk+0x8b/0x670 [btrfs]
> [<ffffffffa031303d>] ? btrfs_set_path_blocking+0x3d/0x50 [btrfs]
> [<ffffffffa0357668>] ? read_extent_buffer+0xd8/0x1d0 [btrfs]
> [<ffffffffa031be51>] ? btrfs_previous_item+0xb1/0x150 [btrfs]
> [<ffffffffa0357668>] ? read_extent_buffer+0xd8/0x1d0 [btrfs]
> [<ffffffffa035f43a>] btrfs_balance+0x21a/0x2b0 [btrfs]
> [<ffffffff8115dc41>] ? path_openat+0x101/0x3d0
> [<ffffffffa03685bc>] btrfs_ioctl+0x51c/0xc40 [btrfs]
> [<ffffffff8111e358>] ? handle_mm_fault+0x148/0x270
> [<ffffffff814809e8>] ? do_page_fault+0x1d8/0x4b0
> [<ffffffff81160d6a>] do_vfs_ioctl+0x9a/0x540
> [<ffffffff811612b1>] sys_ioctl+0xa1/0xb0
> [<ffffffff81484ec2>] system_call_fastpath+0x16/0x1b
> Code: 48 8b 75 20 48 89 c3 48 8b 7d 18 e8 c9 bd ff ff 48 39 d8 77 26 b8 1d 00 00 00 e9 15 ff ff ff a8 01 0f 85 8c fe ff ff 0f 0b eb fe <0f> 0b eb fe 0f 0b 0f 1f 84 00 00 00 00 00 eb f6 4c 89 fb 44 8b
> RIP [<ffffffffa0325422>] lookup_inline_extent_backref+0x2d2/0x3f0 [btrfs]
> RSP <ffff880156d2d7b8>
>
>>
>> Thanks,
>> Tsutomu
>>
>>>
>>> I guess maybe I miss something to reproduce it?
>>>
>>> thanks,
>>> liubo
>>>
>>>> Thanks,
>>>> Tsutomu
>>>>
>>>> =================================================================
>>>>
>>>> btrfs: relocating block group 23383244800 flags 20
>>>> btrfs: found 2959 extents
>>>> ------------[ cut here ]------------
>>>> WARNING: at fs/btrfs/transaction.c:213 start_transaction+0x2a7/0x2b0 [btrfs]()
>>>> Hardware name: PRIMERGY
>>>> Modules linked in: autofs4 sunrpc 8021q garp stp llc cpufreq_ondemand acpi_cpufr
>>>> eq freq_table mperf ipv6 btrfs zlib_deflate crc32c libcrc32c ext3 jbd dm_mirror
>>>> dm_region_hash dm_log dm_mod kvm uinput ppdev parport_pc parport sg pcspkr i2c_i
>>>> 801 i2c_core iTCO_wdt iTCO_vendor_support tg3 shpchp pci_hotplug i3000_edac edac
>>>> _core ext4 mbcache jbd2 crc16 sd_mod crc_t10dif sr_mod cdrom megaraid_sas pata_a
>>>> cpi ata_generic ata_piix libata scsi_mod floppy [last unloaded: microcode]
>>>> Pid: 23781, comm: btrfs Tainted: G W 2.6.39btrfs-test+ #4
>>>> Call Trace:
>>>> [<ffffffff8106004f>] warn_slowpath_common+0x7f/0xc0
>>>> [<ffffffff810600aa>] warn_slowpath_null+0x1a/0x20
>>>> [<ffffffffa0337047>] start_transaction+0x2a7/0x2b0 [btrfs]
>>>> [<ffffffffa035498d>] ? btrfs_wait_ordered_range+0x10d/0x160 [btrfs]
>>>> [<ffffffffa0337323>] btrfs_start_transaction+0x13/0x20 [btrfs]
>>>> [<ffffffffa033bbca>] btrfs_evict_inode+0x11a/0x260 [btrfs]
>>>> [<ffffffff811687f8>] evict+0x78/0x170
>>>> [<ffffffff81168c92>] iput+0xe2/0x1a0
>>>> [<ffffffffa031f171>] btrfs_remove_block_group+0x141/0x3c0 [btrfs]
>>>> [<ffffffffa035e6ea>] btrfs_relocate_chunk+0x54a/0x670 [btrfs]
>>>> [<ffffffffa0357668>] ? read_extent_buffer+0xd8/0x1d0 [btrfs]
>>>> [<ffffffffa031be51>] ? btrfs_previous_item+0xb1/0x150 [btrfs]
>>>> [<ffffffffa035f43a>] btrfs_balance+0x21a/0x2b0 [btrfs]
>>>> [<ffffffff8115dc41>] ? path_openat+0x101/0x3d0
>>>> [<ffffffffa03685bc>] btrfs_ioctl+0x51c/0xc40 [btrfs]
>>>> [<ffffffff8111e358>] ? handle_mm_fault+0x148/0x270
>>>> [<ffffffff814809e8>] ? do_page_fault+0x1d8/0x4b0
>>>> [<ffffffff81160d6a>] do_vfs_ioctl+0x9a/0x540
>>>> [<ffffffff811612b1>] sys_ioctl+0xa1/0xb0
>>>> [<ffffffff81484ec2>] system_call_fastpath+0x16/0x1b
>>>> ---[ end trace e5c5cb2e98a3cd1a ]---
>>>> btrfs: relocating block group 20971520 flags 18
>>>> btrfs: relocating block group 34925969408 flags 18
>>>> btrfs: found 1 extents
>>>> ------------[ cut here ]------------
>>>> kernel BUG at fs/btrfs/extent-tree.c:6164!
>>>> invalid opcode: 0000 [#1] SMP
>>>> last sysfs file: /sys/kernel/mm/ksm/run
>>>> CPU 0
>>>> Modules linked in: autofs4 sunrpc 8021q garp stp llc cpufreq_ondemand acpi_cpufreq freq_table mperf ipv6 btrfs zlib_deflate crc32c libcrc32c ext3 jbd dm_mirror dm_region_hash dm_log dm_mod kvm uinput ppdev parport_pc parport sg pcspkr i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support tg3 shpchp pci_hotplug i3000_edac edac_core ext4 mbcache jbd2 crc16 sd_mod crc_t10dif sr_mod cdrom megaraid_sas pata_acpi ata_generic ata_piix libata scsi_mod floppy [last unloaded: microcode]
>>>>
>>>> Pid: 4109, comm: btrfs Tainted: G W 2.6.39btrfs-test+ #4 FUJITSU-SV PRIMERGY /D2399
>>>> RIP: 0010:[<ffffffffa0325b95>] [<ffffffffa0325b95>] walk_up_proc+0x375/0x420 [btrfs]
>>>> RSP: 0018:ffff8801801eb9c8 EFLAGS: 00010286
>>>> RAX: 0000000000000005 RBX: ffff880167a70140 RCX: fffffffffffffff8
>>>> RDX: ffff8801801ea000 RSI: ffff880000000000 RDI: ffff880194909fa8
>>>> RBP: ffff8801801eba18 R08: 0000000000000000 R09: 0000000000000005
>>>> R10: 0000000000000001 R11: ffff880194909fa8 R12: 0000000000000000
>>>> R13: ffff88013973d000 R14: ffff88015ad4d9a0 R15: ffff880042203920
>>>> FS: 00007fa86bcb9740(0000) GS:ffff88019fc00000(0000) knlGS:0000000000000000
>>>> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>>>> CR2: 00000033cf60b0c0 CR3: 0000000181cf7000 CR4: 00000000000006f0
>>>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>>>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>>>> Process btrfs (pid: 4109, threadinfo ffff8801801ea000, task ffff88011a4914a0)
>>>> Stack:
>>>> ffff8801801eba18 ffff880194909fa8 ffff880100000000 ffffffffa03280e8
>>>> ffff8801801eba58 ffff88015ad4d9a0 0000000000000000 0000000000000000
>>>> ffff8801801ea000 ffff880167a70140 ffff8801801eba78 ffffffffa0325d71
>>>> Call Trace:
>>>> [<ffffffffa03280e8>] ? btrfs_run_delayed_refs+0xc8/0x210 [btrfs]
>>>> [<ffffffffa0325d71>] walk_up_tree+0x131/0x1b0 [btrfs]
>>>> [<ffffffffa03260b0>] btrfs_drop_snapshot+0x2c0/0x5c0 [btrfs]
>>>> [<ffffffffa03328b0>] ? btrfs_read_fs_root_no_name+0x1b0/0x280 [btrfs]
>>>> [<ffffffffa037b45f>] merge_reloc_roots+0xdf/0x150 [btrfs]
>>>> [<ffffffffa037f311>] relocate_block_group+0x481/0x660 [btrfs]
>>>> [<ffffffffa0334d15>] ? btrfs_clean_old_snapshots+0x35/0x150 [btrfs]
>>>> [<ffffffffa037f6a3>] btrfs_relocate_block_group+0x1b3/0x2e0 [btrfs]
>>>> [<ffffffffa0368d80>] ? btrfs_tree_unlock+0x50/0x50 [btrfs]
>>>> [<ffffffffa035e22b>] btrfs_relocate_chunk+0x8b/0x670 [btrfs]
>>>> [<ffffffffa031303d>] ? btrfs_set_path_blocking+0x3d/0x50 [btrfs]
>>>> [<ffffffffa0357668>] ? read_extent_buffer+0xd8/0x1d0 [btrfs]
>>>> [<ffffffffa031be51>] ? btrfs_previous_item+0xb1/0x150 [btrfs]
>>>> [<ffffffffa0357668>] ? read_extent_buffer+0xd8/0x1d0 [btrfs]
>>>> [<ffffffffa035f43a>] btrfs_balance+0x21a/0x2b0 [btrfs]
>>>> [<ffffffff8115dc41>] ? path_openat+0x101/0x3d0
>>>> [<ffffffffa03685bc>] btrfs_ioctl+0x51c/0xc40 [btrfs]
>>>> [<ffffffff8111e358>] ? handle_mm_fault+0x148/0x270
>>>> [<ffffffff814809e8>] ? do_page_fault+0x1d8/0x4b0
>>>> [<ffffffff81160d6a>] do_vfs_ioctl+0x9a/0x540
>>>> [<ffffffff811612b1>] sys_ioctl+0xa1/0xb0
>>>> [<ffffffff81484ec2>] system_call_fastpath+0x16/0x1b
>>>> Code: fe ff ff 0f 1f 00 4c 89 df 31 c9 4c 89 fa 4c 89 ee 44 89 55 c0 4c 89 5d b8 e8 c8 d5 ff ff 4c 8b 5d b8 44 8b 55 c0 e9 85 fe ff ff <0f> 0b eb fe 0f 1f 80 00 00 00 00 65 48 8b 14 25 c8 cc 00 00 48
>>>> RIP [<ffffffffa0325b95>] walk_up_proc+0x375/0x420 [btrfs]
>>>> RSP <ffff8801801eb9c8>
>>>>
>>>>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: kernel BUG at fs/btrfs/extent-tree.c:6164!
2011-06-07 8:24 ` Tsutomu Itoh
@ 2011-06-07 8:36 ` liubo
2011-06-07 15:46 ` Chris Mason
0 siblings, 1 reply; 19+ messages in thread
From: liubo @ 2011-06-07 8:36 UTC (permalink / raw)
To: Tsutomu Itoh; +Cc: Linux Btrfs, Chris Mason
On 06/07/2011 04:24 PM, Tsutomu Itoh wrote:
> (2011/06/07 15:17), Tsutomu Itoh wrote:
>> (2011/06/07 14:59), Tsutomu Itoh wrote:
>>> Hi liubo,
>>>
>>> (2011/06/07 14:31), liubo wrote:
>>>> On 06/06/2011 04:33 PM, Tsutomu Itoh wrote:
>>>>> Hi,
>>>>>
>>>>> I encountered following panic using 'btrfs-unstable + for-linus'
>>>>> kernel.
>>>>>
>>>>> I ran "btrfs fi bal /test5" command, and mount option of /test5
>>>>> is as follows:
>>>>>
>>>>> /dev/sdc3 on /test5 type btrfs (rw,space_cache,compress=lzo,inode_cache)
>>>>>
>>>> So, just a "btrfs fi bal" would lead to the bug?
>>> I think so.
>>>
>>>> I've figured out the warnings, but not reproduced the bug yet...
>>>> I used 'btrfs-unstable + for-linus" whose top commit is
>>>>
>>>> commit aa0467d8d2a00e75b2bb6a56a4ee6d70c5d1928f
>>>> Author: David Sterba <dsterba@suse.cz>
>>>> Date: Fri Jun 3 16:29:08 2011 +0200
>>>>
>>>> btrfs: fix uninitialized variable warning
>>> It's same of my environment.
>>>
>>>>
>>>> and tried on 1) a single disk, 2) 2 disks and 3) 4 disks respectively,
>>>> but none of them leaded to the below bug.
>>> The test script and the volume composition that I am executing are
>>> same as following mail.
>>>
>>> http://marc.info/?l=linux-btrfs&m=130680171426371&w=2
>>>
>>> and, in my environment, panic is done within almost 30 minutes when
>>> test script is executed.
>
> I forgot to write.
> I am adding '-o inode_cache' to the mount option in my test script.
>
Yep, I've added this and reproduced it.
Seems that there are several bugs.
Anyway, thanks for the report. I'm trying to work it out. :)
thanks,
liubo
>> Another panic occurred when I executed it again.
>>
>
> I rebuilt the kernel with 3.0-rc2. but, same problem occurred.
>
>
> <4>[ 131.708325] WARNING: at fs/btrfs/transaction.c:213 start_transaction+0x74/0x259 [btrfs]()
> <4>[ 131.708329] Hardware name: PRIMERGY
> <4>[ 131.708330] Modules linked in: autofs4 sunrpc 8021q garp stp llc cpufreq_ondemand acpi_cpufreq freq_table mperf ipv6 btrfs zlib_deflate crc32c libcrc32c ext3 jbd dm_mirror dm_region_hash dm_log dm_mod kvm uinput ppdev parport_pc parport sg pcspkr i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support tg3 shpchp pci_hotplug i3000_edac edac_core ext4 mbcache jbd2 crc16 sd_mod crc_t10dif sr_mod cdrom megaraid_sas pata_acpi ata_generic ata_piix libata scsi_mod floppy [last unloaded: microcode]
> <4>[ 131.708378] Pid: 3041, comm: btrfs Not tainted 3.0.0-rc2test #1
> <4>[ 131.708381] Call Trace:
> <4>[ 131.708388] [<ffffffff8104514a>] warn_slowpath_common+0x85/0x9d
> <4>[ 131.708392] [<ffffffff8104517c>] warn_slowpath_null+0x1a/0x1c
> <4>[ 131.708410] [<ffffffffa02a6f8b>] start_transaction+0x74/0x259 [btrfs]
> <4>[ 131.708430] [<ffffffffa02bf965>] ? btrfs_wait_ordered_range+0xf9/0x11d [btrfs]
> <4>[ 131.708448] [<ffffffffa02a73ed>] btrfs_start_transaction+0x13/0x15 [btrfs]
> <4>[ 131.708467] [<ffffffffa02aec08>] btrfs_evict_inode+0x113/0x22d [btrfs]
> <4>[ 131.708471] [<ffffffff81123a98>] evict+0x77/0x118
> <4>[ 131.708475] [<ffffffff81123ec1>] iput+0x13d/0x146
> <4>[ 131.708489] [<ffffffffa02939c9>] btrfs_remove_block_group+0x14d/0x35b [btrfs]
> <4>[ 131.708508] [<ffffffffa02c6ff7>] btrfs_relocate_chunk+0x464/0x50d [btrfs]
> <4>[ 131.708527] [<ffffffffa02c54ce>] ? btrfs_item_key_to_cpu+0x2a/0x46 [btrfs]
> <4>[ 131.708545] [<ffffffffa02c7672>] btrfs_balance+0x1ca/0x219 [btrfs]
> <4>[ 131.708563] [<ffffffffa02cfbfd>] btrfs_ioctl+0x890/0xb87 [btrfs]
> <4>[ 131.708567] [<ffffffff810e87c8>] ? handle_mm_fault+0x233/0x24a
> <4>[ 131.708572] [<ffffffff813a6e25>] ? do_page_fault+0x340/0x3b2
> <4>[ 131.708577] [<ffffffff8111d6f8>] do_vfs_ioctl+0x474/0x4c3
> <4>[ 131.708581] [<ffffffff810ffd25>] ? virt_to_head_page+0xe/0x31
> <4>[ 131.708585] [<ffffffff81100fcc>] ? kmem_cache_free+0x20/0xae
> <4>[ 131.708588] [<ffffffff8111d79d>] sys_ioctl+0x56/0x79
> <4>[ 131.708592] [<ffffffff813aa542>] system_call_fastpath+0x16/0x1b
> <4>[ 131.708595] ---[ end trace 5f962f46d3ba5425 ]---
> <6>[ 131.708777] btrfs: relocating block group 29360128 flags 20
> <6>[ 132.385682] btrfs: found 85 extents
> <0>[ 132.798892] ------------[ cut here ]------------
> <2>[ 132.799014] kernel BUG at fs/btrfs/extent-tree.c:1424!
> <0>[ 132.799014] invalid opcode: 0000 [#1] SMP
> <4>[ 132.799014] CPU 0
> <4>[ 132.799014] Modules linked in: autofs4 sunrpc 8021q garp stp llc cpufreq_ondemand acpi_cpufreq freq_table mperf ipv6 btrfs zlib_deflate crc32c libcrc32c ext3 jbd dm_mirror dm_region_hash dm_log dm_mod kvm uinput ppdev parport_pc parport sg pcspkr i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support tg3 shpchp pci_hotplug i3000_edac edac_core ext4 mbcache jbd2 crc16 sd_mod crc_t10dif sr_mod cdrom megaraid_sas pata_acpi ata_generic ata_piix libata scsi_mod floppy [last unloaded: microcode]
> <4>[ 132.799014]
> <4>[ 132.799014] Pid: 3041, comm: btrfs Tainted: G W 3.0.0-rc2test #1 FUJITSU-SV PRIMERGY /D2399
> <4>[ 132.799014] RIP: 0010:[<ffffffffa0296c86>] [<ffffffffa0296c86>] lookup_inline_extent_backref+0xe3/0x3a9 [btrfs]
> <4>[ 132.799014] RSP: 0018:ffff880193aa5808 EFLAGS: 00010202
> <4>[ 132.799014] RAX: 0000000000000001 RBX: ffff880192fac000 RCX: 0000000000000002
> <4>[ 132.799014] RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000
> <4>[ 132.799014] RBP: ffff880193aa58a8 R08: 000000000000029c R09: ffff880193aa56f0
> <4>[ 132.799014] R10: ffff880193aa5648 R11: c2d107e744029d66 R12: 00000000000000b2
> <4>[ 132.799014] R13: ffff880195075b88 R14: 0000000000000001 R15: 0000000000000000
> <4>[ 132.799014] FS: 00007faaaf421740(0000) GS:ffff88019fc00000(0000) knlGS:0000000000000000
> <4>[ 132.799014] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> <4>[ 132.799014] CR2: 00000033cfeda340 CR3: 00000001946b5000 CR4: 00000000000006f0
> <4>[ 132.799014] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> <4>[ 132.799014] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> <4>[ 132.799014] Process btrfs (pid: 3041, threadinfo ffff880193aa4000, task ffff88019463ad80)
> <0>[ 132.799014] Stack:
> <4>[ 132.799014] ffff880192a0fa00 0000000000001000 ffff880194640000 ffff880193aa5950
> <4>[ 132.799014] ffff880193aa5848 0000000181f65000 ffff880193aa5848 ffff880193e24000
> <4>[ 132.799014] ffffffff93aa5898 ffffffff81101372 0000000181f65000 00000000009000a8
> <0>[ 132.799014] Call Trace:
> <4>[ 132.799014] [<ffffffff81101372>] ? kmem_cache_alloc+0x27/0xee
> <4>[ 132.799014] [<ffffffffa0299a58>] __btrfs_free_extent+0xc8/0x57f [btrfs]
> <4>[ 132.799014] [<ffffffff81100f64>] ? kfree+0xbd/0xdd
> <4>[ 132.799014] [<ffffffffa029a5a9>] run_clustered_refs+0x69a/0x6fa [btrfs]
> <4>[ 132.799014] [<ffffffffa029a6d7>] btrfs_run_delayed_refs+0xce/0x17c [btrfs]
> <4>[ 132.799014] [<ffffffffa02a66ac>] btrfs_commit_transaction+0x7e/0x674 [btrfs]
> <4>[ 132.799014] [<ffffffffa02a5fb0>] ? join_transaction+0x24/0x213 [btrfs]
> <4>[ 132.799014] [<ffffffff8106085d>] ? wake_up_bit+0x2a/0x2a
> <4>[ 132.799014] [<ffffffffa02e1b3f>] relocate_block_group+0x4f3/0x51a [btrfs]
> <4>[ 132.799014] [<ffffffffa02a544d>] ? btrfs_clean_old_snapshots+0x35/0x127 [btrfs]
> <4>[ 132.799014] [<ffffffffa02e1cb1>] btrfs_relocate_block_group+0x14b/0x282 [btrfs]
> <4>[ 132.799014] [<ffffffffa02c7037>] ? btrfs_relocate_chunk+0x4a4/0x50d [btrfs]
> <4>[ 132.799014] [<ffffffffa02c6bfc>] btrfs_relocate_chunk+0x69/0x50d [btrfs]
> <4>[ 132.799014] [<ffffffffa028b3e1>] ? btrfs_item_key_to_cpu+0x1a/0x36 [btrfs]
> <4>[ 132.799014] [<ffffffffa02c0bc3>] ? read_extent_buffer+0xba/0xf6 [btrfs]
> <4>[ 132.799014] [<ffffffffa02c54ce>] ? btrfs_item_key_to_cpu+0x2a/0x46 [btrfs]
> <4>[ 132.799014] [<ffffffffa02c7672>] btrfs_balance+0x1ca/0x219 [btrfs]
> <4>[ 132.799014] [<ffffffffa02cfbfd>] btrfs_ioctl+0x890/0xb87 [btrfs]
> <4>[ 132.799014] [<ffffffff810e87c8>] ? handle_mm_fault+0x233/0x24a
> <4>[ 132.799014] [<ffffffff813a6e25>] ? do_page_fault+0x340/0x3b2
> <4>[ 132.799014] [<ffffffff8111d6f8>] do_vfs_ioctl+0x474/0x4c3
> <4>[ 132.799014] [<ffffffff810ffd25>] ? virt_to_head_page+0xe/0x31
> <4>[ 132.799014] [<ffffffff81100fcc>] ? kmem_cache_free+0x20/0xae
> <4>[ 132.799014] [<ffffffff8111d79d>] sys_ioctl+0x56/0x79
> <4>[ 132.799014] [<ffffffff813aa542>] system_call_fastpath+0x16/0x1b
> <0>[ 132.799014] Code: 44 8b 45 a4 48 8b 75 98 48 8d 55 b0 41 b9 01 00 00 00 48 89 d9 4c 89 ef e8 54 96 ff ff 83 f8 00 41 89 c6 0f 8c 94 02 00 00 74 04 <0f> 0b eb fe 4c 8b 33 8b 73 40 4c 89 f7 e8 9d ea ff ff 41 89 c7
> <1>[ 132.799014] RIP [<ffffffffa0296c86>] lookup_inline_extent_backref+0xe3/0x3a9 [btrfs]
> <4>[ 132.799014] RSP <ffff880193aa5808>
> RSP <ffff880193aa5808>
>
>
>> device fsid 794aee8608a3c563-e4baafe1f4d8eba5 devid 5 transid 4 /dev/sdc8
>> device fsid 794aee8608a3c563-e4baafe1f4d8eba5 devid 1 transid 7 /dev/sdc3
>> btrfs: enabling disk space caching
>> btrfs: use lzo compression
>> btrfs: enabling inode map caching
>> device fsid 624604c4bdf670bb-1c9404b53abaa6a3 devid 1 transid 7 /dev/sdd4
>> btrfs: disk space caching is enabled
>> btrfs: relocating block group 1103101952 flags 9
>> btrfs: found 540 extents
>> btrfs: found 540 extents
>> ------------[ cut here ]------------
>> kernel BUG at fs/btrfs/extent-tree.c:1424!
>> invalid opcode: 0000 [#1] SMP
>> last sysfs file: /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/0000:02:03.0/host4/target4:2:3/4:2:3:0/block/sdd/sdd4/alignment_offset
>> CPU 0
>> Modules linked in: autofs4 sunrpc 8021q garp stp llc cpufreq_ondemand acpi_cpufreq freq_table mperf ipv6 btrfs zlib_deflate crc32c libcrc32c ext3 jbd dm_mirror dm_region_hash dm_log dm_mod kvm uinput ppdev parport_pc parport sg pcspkr i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support tg3 shpchp pci_hotplug i3000_edac edac_core ext4 mbcache jbd2 crc16 sd_mod crc_t10dif sr_mod cdrom megaraid_sas pata_acpi ata_generic ata_piix libata scsi_mod floppy [last unloaded: microcode]
>>
>> Pid: 3849, comm: btrfs Not tainted 2.6.39btrfs-test+ #4 FUJITSU-SV PRIMERGY /D2399
>> RIP: 0010:[<ffffffffa0325422>] [<ffffffffa0325422>] lookup_inline_extent_backref+0x2d2/0x3f0 [btrfs]
>> RSP: 0018:ffff880156d2d7b8 EFLAGS: 00010202
>> RAX: 0000000000000001 RBX: ffff8801947f3e20 RCX: ffff880156d2c000
>> RDX: 0000000000000008 RSI: ffff880000000000 RDI: 0000000000000000
>> RBP: ffff880156d2d858 R08: 0000000000000000 R09: 0000000000000283
>> R10: 0000000000000000 R11: 0000000000000015 R12: 00000000000000b2
>> R13: ffff88019474b4f8 R14: 0000000000000001 R15: 00000000ffffffff
>> FS: 00007faaf3753740(0000) GS:ffff88019fc00000(0000) knlGS:0000000000000000
>> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>> CR2: 00000000017bfea0 CR3: 0000000156e53000 CR4: 00000000000006f0
>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>> Process btrfs (pid: 3849, threadinfo ffff880156d2c000, task ffff880192a04ab0)
>> Stack:
>> ffff880193893000 0000000000001000 ffff880156d2d808 ffff880156d2d920
>> ffff880156d2d808 0000000181f61000 0000000000000000 ffff880193893000
>> 0000000000000001 ffff880156d2da18 0000000181f61000 00000000009000a8
>> Call Trace:
>> [<ffffffffa03271d6>] __btrfs_free_extent+0xd6/0x730 [btrfs]
>> [<ffffffffa0356960>] ? map_extent_buffer+0xb0/0xc0 [btrfs]
>> [<ffffffffa0326d19>] ? update_block_group+0xd9/0x2a0 [btrfs]
>> [<ffffffffa0327ed8>] run_clustered_refs+0x6a8/0x7f0 [btrfs]
>> [<ffffffffa03280e8>] btrfs_run_delayed_refs+0xc8/0x210 [btrfs]
>> [<ffffffffa033638d>] btrfs_commit_transaction+0x7d/0x790 [btrfs]
>> [<ffffffffa0335ac5>] ? join_transaction+0x25/0x250 [btrfs]
>> [<ffffffff81081de0>] ? wake_up_bit+0x40/0x40
>> [<ffffffffa037f377>] relocate_block_group+0x4e7/0x660 [btrfs]
>> [<ffffffffa0334d15>] ? btrfs_clean_old_snapshots+0x35/0x150 [btrfs]
>> [<ffffffffa037f6a3>] btrfs_relocate_block_group+0x1b3/0x2e0 [btrfs]
>> [<ffffffffa0368d80>] ? btrfs_tree_unlock+0x50/0x50 [btrfs]
>> [<ffffffffa035e22b>] btrfs_relocate_chunk+0x8b/0x670 [btrfs]
>> [<ffffffffa031303d>] ? btrfs_set_path_blocking+0x3d/0x50 [btrfs]
>> [<ffffffffa0357668>] ? read_extent_buffer+0xd8/0x1d0 [btrfs]
>> [<ffffffffa031be51>] ? btrfs_previous_item+0xb1/0x150 [btrfs]
>> [<ffffffffa0357668>] ? read_extent_buffer+0xd8/0x1d0 [btrfs]
>> [<ffffffffa035f43a>] btrfs_balance+0x21a/0x2b0 [btrfs]
>> [<ffffffff8115dc41>] ? path_openat+0x101/0x3d0
>> [<ffffffffa03685bc>] btrfs_ioctl+0x51c/0xc40 [btrfs]
>> [<ffffffff8111e358>] ? handle_mm_fault+0x148/0x270
>> [<ffffffff814809e8>] ? do_page_fault+0x1d8/0x4b0
>> [<ffffffff81160d6a>] do_vfs_ioctl+0x9a/0x540
>> [<ffffffff811612b1>] sys_ioctl+0xa1/0xb0
>> [<ffffffff81484ec2>] system_call_fastpath+0x16/0x1b
>> Code: 48 8b 75 20 48 89 c3 48 8b 7d 18 e8 c9 bd ff ff 48 39 d8 77 26 b8 1d 00 00 00 e9 15 ff ff ff a8 01 0f 85 8c fe ff ff 0f 0b eb fe <0f> 0b eb fe 0f 0b 0f 1f 84 00 00 00 00 00 eb f6 4c 89 fb 44 8b
>> RIP [<ffffffffa0325422>] lookup_inline_extent_backref+0x2d2/0x3f0 [btrfs]
>> RSP <ffff880156d2d7b8>
>>
>>> Thanks,
>>> Tsutomu
>>>
>>>> I guess maybe I miss something to reproduce it?
>>>>
>>>> thanks,
>>>> liubo
>>>>
>>>>> Thanks,
>>>>> Tsutomu
>>>>>
>>>>> =================================================================
>>>>>
>>>>> btrfs: relocating block group 23383244800 flags 20
>>>>> btrfs: found 2959 extents
>>>>> ------------[ cut here ]------------
>>>>> WARNING: at fs/btrfs/transaction.c:213 start_transaction+0x2a7/0x2b0 [btrfs]()
>>>>> Hardware name: PRIMERGY
>>>>> Modules linked in: autofs4 sunrpc 8021q garp stp llc cpufreq_ondemand acpi_cpufr
>>>>> eq freq_table mperf ipv6 btrfs zlib_deflate crc32c libcrc32c ext3 jbd dm_mirror
>>>>> dm_region_hash dm_log dm_mod kvm uinput ppdev parport_pc parport sg pcspkr i2c_i
>>>>> 801 i2c_core iTCO_wdt iTCO_vendor_support tg3 shpchp pci_hotplug i3000_edac edac
>>>>> _core ext4 mbcache jbd2 crc16 sd_mod crc_t10dif sr_mod cdrom megaraid_sas pata_a
>>>>> cpi ata_generic ata_piix libata scsi_mod floppy [last unloaded: microcode]
>>>>> Pid: 23781, comm: btrfs Tainted: G W 2.6.39btrfs-test+ #4
>>>>> Call Trace:
>>>>> [<ffffffff8106004f>] warn_slowpath_common+0x7f/0xc0
>>>>> [<ffffffff810600aa>] warn_slowpath_null+0x1a/0x20
>>>>> [<ffffffffa0337047>] start_transaction+0x2a7/0x2b0 [btrfs]
>>>>> [<ffffffffa035498d>] ? btrfs_wait_ordered_range+0x10d/0x160 [btrfs]
>>>>> [<ffffffffa0337323>] btrfs_start_transaction+0x13/0x20 [btrfs]
>>>>> [<ffffffffa033bbca>] btrfs_evict_inode+0x11a/0x260 [btrfs]
>>>>> [<ffffffff811687f8>] evict+0x78/0x170
>>>>> [<ffffffff81168c92>] iput+0xe2/0x1a0
>>>>> [<ffffffffa031f171>] btrfs_remove_block_group+0x141/0x3c0 [btrfs]
>>>>> [<ffffffffa035e6ea>] btrfs_relocate_chunk+0x54a/0x670 [btrfs]
>>>>> [<ffffffffa0357668>] ? read_extent_buffer+0xd8/0x1d0 [btrfs]
>>>>> [<ffffffffa031be51>] ? btrfs_previous_item+0xb1/0x150 [btrfs]
>>>>> [<ffffffffa035f43a>] btrfs_balance+0x21a/0x2b0 [btrfs]
>>>>> [<ffffffff8115dc41>] ? path_openat+0x101/0x3d0
>>>>> [<ffffffffa03685bc>] btrfs_ioctl+0x51c/0xc40 [btrfs]
>>>>> [<ffffffff8111e358>] ? handle_mm_fault+0x148/0x270
>>>>> [<ffffffff814809e8>] ? do_page_fault+0x1d8/0x4b0
>>>>> [<ffffffff81160d6a>] do_vfs_ioctl+0x9a/0x540
>>>>> [<ffffffff811612b1>] sys_ioctl+0xa1/0xb0
>>>>> [<ffffffff81484ec2>] system_call_fastpath+0x16/0x1b
>>>>> ---[ end trace e5c5cb2e98a3cd1a ]---
>>>>> btrfs: relocating block group 20971520 flags 18
>>>>> btrfs: relocating block group 34925969408 flags 18
>>>>> btrfs: found 1 extents
>>>>> ------------[ cut here ]------------
>>>>> kernel BUG at fs/btrfs/extent-tree.c:6164!
>>>>> invalid opcode: 0000 [#1] SMP
>>>>> last sysfs file: /sys/kernel/mm/ksm/run
>>>>> CPU 0
>>>>> Modules linked in: autofs4 sunrpc 8021q garp stp llc cpufreq_ondemand acpi_cpufreq freq_table mperf ipv6 btrfs zlib_deflate crc32c libcrc32c ext3 jbd dm_mirror dm_region_hash dm_log dm_mod kvm uinput ppdev parport_pc parport sg pcspkr i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support tg3 shpchp pci_hotplug i3000_edac edac_core ext4 mbcache jbd2 crc16 sd_mod crc_t10dif sr_mod cdrom megaraid_sas pata_acpi ata_generic ata_piix libata scsi_mod floppy [last unloaded: microcode]
>>>>>
>>>>> Pid: 4109, comm: btrfs Tainted: G W 2.6.39btrfs-test+ #4 FUJITSU-SV PRIMERGY /D2399
>>>>> RIP: 0010:[<ffffffffa0325b95>] [<ffffffffa0325b95>] walk_up_proc+0x375/0x420 [btrfs]
>>>>> RSP: 0018:ffff8801801eb9c8 EFLAGS: 00010286
>>>>> RAX: 0000000000000005 RBX: ffff880167a70140 RCX: fffffffffffffff8
>>>>> RDX: ffff8801801ea000 RSI: ffff880000000000 RDI: ffff880194909fa8
>>>>> RBP: ffff8801801eba18 R08: 0000000000000000 R09: 0000000000000005
>>>>> R10: 0000000000000001 R11: ffff880194909fa8 R12: 0000000000000000
>>>>> R13: ffff88013973d000 R14: ffff88015ad4d9a0 R15: ffff880042203920
>>>>> FS: 00007fa86bcb9740(0000) GS:ffff88019fc00000(0000) knlGS:0000000000000000
>>>>> CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
>>>>> CR2: 00000033cf60b0c0 CR3: 0000000181cf7000 CR4: 00000000000006f0
>>>>> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
>>>>> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
>>>>> Process btrfs (pid: 4109, threadinfo ffff8801801ea000, task ffff88011a4914a0)
>>>>> Stack:
>>>>> ffff8801801eba18 ffff880194909fa8 ffff880100000000 ffffffffa03280e8
>>>>> ffff8801801eba58 ffff88015ad4d9a0 0000000000000000 0000000000000000
>>>>> ffff8801801ea000 ffff880167a70140 ffff8801801eba78 ffffffffa0325d71
>>>>> Call Trace:
>>>>> [<ffffffffa03280e8>] ? btrfs_run_delayed_refs+0xc8/0x210 [btrfs]
>>>>> [<ffffffffa0325d71>] walk_up_tree+0x131/0x1b0 [btrfs]
>>>>> [<ffffffffa03260b0>] btrfs_drop_snapshot+0x2c0/0x5c0 [btrfs]
>>>>> [<ffffffffa03328b0>] ? btrfs_read_fs_root_no_name+0x1b0/0x280 [btrfs]
>>>>> [<ffffffffa037b45f>] merge_reloc_roots+0xdf/0x150 [btrfs]
>>>>> [<ffffffffa037f311>] relocate_block_group+0x481/0x660 [btrfs]
>>>>> [<ffffffffa0334d15>] ? btrfs_clean_old_snapshots+0x35/0x150 [btrfs]
>>>>> [<ffffffffa037f6a3>] btrfs_relocate_block_group+0x1b3/0x2e0 [btrfs]
>>>>> [<ffffffffa0368d80>] ? btrfs_tree_unlock+0x50/0x50 [btrfs]
>>>>> [<ffffffffa035e22b>] btrfs_relocate_chunk+0x8b/0x670 [btrfs]
>>>>> [<ffffffffa031303d>] ? btrfs_set_path_blocking+0x3d/0x50 [btrfs]
>>>>> [<ffffffffa0357668>] ? read_extent_buffer+0xd8/0x1d0 [btrfs]
>>>>> [<ffffffffa031be51>] ? btrfs_previous_item+0xb1/0x150 [btrfs]
>>>>> [<ffffffffa0357668>] ? read_extent_buffer+0xd8/0x1d0 [btrfs]
>>>>> [<ffffffffa035f43a>] btrfs_balance+0x21a/0x2b0 [btrfs]
>>>>> [<ffffffff8115dc41>] ? path_openat+0x101/0x3d0
>>>>> [<ffffffffa03685bc>] btrfs_ioctl+0x51c/0xc40 [btrfs]
>>>>> [<ffffffff8111e358>] ? handle_mm_fault+0x148/0x270
>>>>> [<ffffffff814809e8>] ? do_page_fault+0x1d8/0x4b0
>>>>> [<ffffffff81160d6a>] do_vfs_ioctl+0x9a/0x540
>>>>> [<ffffffff811612b1>] sys_ioctl+0xa1/0xb0
>>>>> [<ffffffff81484ec2>] system_call_fastpath+0x16/0x1b
>>>>> Code: fe ff ff 0f 1f 00 4c 89 df 31 c9 4c 89 fa 4c 89 ee 44 89 55 c0 4c 89 5d b8 e8 c8 d5 ff ff 4c 8b 5d b8 44 8b 55 c0 e9 85 fe ff ff <0f> 0b eb fe 0f 1f 80 00 00 00 00 65 48 8b 14 25 c8 cc 00 00 48
>>>>> RIP [<ffffffffa0325b95>] walk_up_proc+0x375/0x420 [btrfs]
>>>>> RSP <ffff8801801eb9c8>
>>>>>
>>>>>
>
> --
> 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] 19+ messages in thread
* Re: kernel BUG at fs/btrfs/extent-tree.c:6164!
2011-06-07 8:36 ` liubo
@ 2011-06-07 15:46 ` Chris Mason
2011-06-08 5:12 ` Tsutomu Itoh
0 siblings, 1 reply; 19+ messages in thread
From: Chris Mason @ 2011-06-07 15:46 UTC (permalink / raw)
To: liubo; +Cc: Tsutomu Itoh, Linux Btrfs
Excerpts from liubo's message of 2011-06-07 04:36:56 -0400:
> On 06/07/2011 04:24 PM, Tsutomu Itoh wrote:
> > (2011/06/07 15:17), Tsutomu Itoh wrote:
> >> (2011/06/07 14:59), Tsutomu Itoh wrote:
> >>> Hi liubo,
> >>>
> >>> (2011/06/07 14:31), liubo wrote:
> >>>> On 06/06/2011 04:33 PM, Tsutomu Itoh wrote:
> >>>>> Hi,
> >>>>>
> >>>>> I encountered following panic using 'btrfs-unstable + for-linus'
> >>>>> kernel.
> >>>>>
> >>>>> I ran "btrfs fi bal /test5" command, and mount option of /test5
> >>>>> is as follows:
> >>>>>
> >>>>> /dev/sdc3 on /test5 type btrfs (rw,space_cache,compress=lzo,inode_cache)
> >>>>>
> >>>> So, just a "btrfs fi bal" would lead to the bug?
> >>> I think so.
It should be specific to the inode caching code. The balancing code is
finding the inode map cache extents, but it doesn't know how to relocate
them.
I think we need to switch the inode map cache over to regular extents
that are not preallocated. It will fix the overflow problem and it will
fix the balancing.
There are a lot of special cases for the free extent cache that don't
apply to the inode map cache, and I think sharing the extent
preallocation is hurting us.
-chris
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: kernel BUG at fs/btrfs/extent-tree.c:6164!
2011-06-07 15:46 ` Chris Mason
@ 2011-06-08 5:12 ` Tsutomu Itoh
2011-06-13 7:13 ` bug caused by removal of trans_mutex? (Was: Re: kernel BUG at fs/btrfs/extent-tree.c:6164!) Li Zefan
0 siblings, 1 reply; 19+ messages in thread
From: Tsutomu Itoh @ 2011-06-08 5:12 UTC (permalink / raw)
To: Chris Mason; +Cc: liubo, Linux Btrfs
(2011/06/08 0:46), Chris Mason wrote:
> Excerpts from liubo's message of 2011-06-07 04:36:56 -0400:
>> On 06/07/2011 04:24 PM, Tsutomu Itoh wrote:
>>> (2011/06/07 15:17), Tsutomu Itoh wrote:
>>>> (2011/06/07 14:59), Tsutomu Itoh wrote:
>>>>> Hi liubo,
>>>>>
>>>>> (2011/06/07 14:31), liubo wrote:
>>>>>> On 06/06/2011 04:33 PM, Tsutomu Itoh wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I encountered following panic using 'btrfs-unstable + for-linus'
>>>>>>> kernel.
>>>>>>>
>>>>>>> I ran "btrfs fi bal /test5" command, and mount option of /test5
>>>>>>> is as follows:
>>>>>>>
>>>>>>> /dev/sdc3 on /test5 type btrfs (rw,space_cache,compress=lzo,inode_cache)
>>>>>>>
>>>>>> So, just a "btrfs fi bal" would lead to the bug?
>>>>> I think so.
>
> It should be specific to the inode caching code. The balancing code is
> finding the inode map cache extents, but it doesn't know how to relocate
> them.
However, the panic has occurred even if inode_cahce is turned off.
Is this another problem?
---
Tsutomu
====================================================================
device fsid a46d03b5cb35c93-4713fead8acc709e devid 1 transid 7 /dev/sdc3
btrfs: enabling disk space caching
btrfs: use lzo compression
device fsid 914b303425ef9825-e448135c0d20babe devid 1 transid 7 /dev/sdd4
btrfs: disk space caching is enabled
btrfs: relocating block group 1103101952 flags 9
btrfs: found 540 extents
btrfs: found 540 extents
------------[ cut here ]------------
kernel BUG at fs/btrfs/extent-tree.c:1424!
invalid opcode: 0000 [#1] SMP
last sysfs file: /sys/kernel/mm/ksm/run
CPU 0
Modules linked in: autofs4 sunrpc 8021q garp stp llc cpufreq_ondemand acpi_cpufreq freq_table mperf ipv6 btrfs zlib_deflate crc32c libcrc32c ext3 jbd dm_mirror dm_region_hash dm_log dm_mod kvm uinput ppdev parport_pc parport sg pcspkr i2c_i801 i2c_core iTCO_wdt iTCO_vendor_support tg3 shpchp pci_hotplug i3000_edac edac_core ext4 mbcache jbd2 crc16 sd_mod crc_t10dif sr_mod cdrom megaraid_sas pata_acpi ata_generic ata_piix libata scsi_mod floppy [last unloaded: microcode]
Pid: 26884, comm: btrfs Not tainted 2.6.39btrfs-test+ #4 FUJITSU-SV PRIMERGY /D2399
RIP: 0010:[<ffffffffa0325422>] [<ffffffffa0325422>] lookup_inline_extent_backref+0x2d2/0x3f0 [btrfs]
RSP: 0018:ffff8801475db748 EFLAGS: 00010202
RAX: 0000000000000001 RBX: ffff880141d1a6d0 RCX: ffff8801475da000
RDX: 0000000000000008 RSI: ffff880000000000 RDI: 0000000000000000
RBP: ffff8801475db7e8 R08: 0000000000000001 R09: 6db6db6db6db6db7
R10: 0000000000000001 R11: 0000000000000014 R12: 00000000000000b8
R13: ffff880142bc8a08 R14: 0000000000000001 R15: 000000000000000d
FS: 00007fbbaa8b0740(0000) GS:ffff88019fc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00000033cfeda340 CR3: 0000000145c04000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process btrfs (pid: 26884, threadinfo ffff8801475da000, task ffff880160806ab0)
Stack:
ffff8801475db778 ffffffffa0331ca6 ffff88018c1087c8 ffff8801475db830
0000000000000821 0000000181f43000 ffff8801475db7e8 ffff88012cc27800
000000000000082e 00000794475db9a9 0000000181f43000 00000000004000a8
Call Trace:
[<ffffffffa0331ca6>] ? btrfs_mark_buffer_dirty+0xb6/0x130 [btrfs]
[<ffffffffa03255a9>] insert_inline_extent_backref+0x69/0x100 [btrfs]
[<ffffffff81140376>] ? kmem_cache_alloc+0x186/0x190
[<ffffffffa03256e3>] __btrfs_inc_extent_ref+0xa3/0x1e0 [btrfs]
[<ffffffffa0326d19>] ? update_block_group+0xd9/0x2a0 [btrfs]
[<ffffffffa0327e94>] run_clustered_refs+0x664/0x7f0 [btrfs]
[<ffffffffa03280e8>] btrfs_run_delayed_refs+0xc8/0x210 [btrfs]
[<ffffffffa033638d>] btrfs_commit_transaction+0x7d/0x790 [btrfs]
[<ffffffff81081de0>] ? wake_up_bit+0x40/0x40
[<ffffffffa037922d>] prepare_to_merge+0x1fd/0x230 [btrfs]
[<ffffffffa037f306>] relocate_block_group+0x476/0x660 [btrfs]
[<ffffffffa0334d15>] ? btrfs_clean_old_snapshots+0x35/0x150 [btrfs]
[<ffffffffa037f6a3>] btrfs_relocate_block_group+0x1b3/0x2e0 [btrfs]
[<ffffffffa0368d80>] ? btrfs_tree_unlock+0x50/0x50 [btrfs]
[<ffffffffa035e22b>] btrfs_relocate_chunk+0x8b/0x670 [btrfs]
[<ffffffffa031303d>] ? btrfs_set_path_blocking+0x3d/0x50 [btrfs]
[<ffffffffa0357668>] ? read_extent_buffer+0xd8/0x1d0 [btrfs]
[<ffffffffa031be51>] ? btrfs_previous_item+0xb1/0x150 [btrfs]
[<ffffffffa0357668>] ? read_extent_buffer+0xd8/0x1d0 [btrfs]
[<ffffffffa035f43a>] btrfs_balance+0x21a/0x2b0 [btrfs]
[<ffffffff8115dc41>] ? path_openat+0x101/0x3d0
[<ffffffffa03685bc>] btrfs_ioctl+0x51c/0xc40 [btrfs]
[<ffffffff8111e358>] ? handle_mm_fault+0x148/0x270
[<ffffffff814809e8>] ? do_page_fault+0x1d8/0x4b0
[<ffffffff81160d6a>] do_vfs_ioctl+0x9a/0x540
[<ffffffff811612b1>] sys_ioctl+0xa1/0xb0
[<ffffffff81484ec2>] system_call_fastpath+0x16/0x1b
Code: 48 8b 75 20 48 89 c3 48 8b 7d 18 e8 c9 bd ff ff 48 39 d8 77 26 b8 1d 00 00 00 e9 15 ff ff ff a8 01 0f 85 8c fe ff ff 0f 0b eb fe <0f> 0b eb fe 0f 0b 0f 1f 84 00 00 00 00 00 eb f6 4c 89 fb 44 8b
RIP [<ffffffffa0325422>] lookup_inline_extent_backref+0x2d2/0x3f0 [btrfs]
RSP <ffff8801475db748>
>
> I think we need to switch the inode map cache over to regular extents
> that are not preallocated. It will fix the overflow problem and it will
> fix the balancing.
>
> There are a lot of special cases for the free extent cache that don't
> apply to the inode map cache, and I think sharing the extent
> preallocation is hurting us.
>
> -chris
>
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* bug caused by removal of trans_mutex? (Was: Re: kernel BUG at fs/btrfs/extent-tree.c:6164!)
2011-06-08 5:12 ` Tsutomu Itoh
@ 2011-06-13 7:13 ` Li Zefan
2011-06-13 7:49 ` Yan, Zheng
` (3 more replies)
0 siblings, 4 replies; 19+ messages in thread
From: Li Zefan @ 2011-06-13 7:13 UTC (permalink / raw)
To: Tsutomu Itoh; +Cc: Chris Mason, liubo, Linux Btrfs, Josef Bacik
Cc: Josef
>>>>>>>> I encountered following panic using 'btrfs-unstable + for-linus'
>>>>>>>> kernel.
>>>>>>>>
>>>>>>>> I ran "btrfs fi bal /test5" command, and mount option of /test5
>>>>>>>> is as follows:
>>>>>>>>
>>>>>>>> /dev/sdc3 on /test5 type btrfs (rw,space_cache,compress=lzo,inode_cache)
>>>>>>>>
>>>>>>> So, just a "btrfs fi bal" would lead to the bug?
>>>>>> I think so.
>>
>> It should be specific to the inode caching code. The balancing code is
>> finding the inode map cache extents, but it doesn't know how to relocate
>> them.
>
> However, the panic has occurred even if inode_cahce is turned off.
> Is this another problem?
>
I don't think free inode cache isthe cause of the bug here (even if inode_cache
is turned on).
What I have found out is:
1. git checkout a4abeea41adfa3c143c289045f4625dfaeba2212
So the top commit is the removal of trans_mutex and no delayed_inode patch
or free inode cache patchset in the tree, and bug can be triggered.
2. git checkout 2a1eb4614d984d5cd4c928784e9afcf5c07f93be
So the top commit is the one before trans_mutex removal, and no bug triggered.
3. test linus' tree
bug triggered.
4. revert that suspicoius commit manually from linus' tree
no bug.
so either that commit is buggy or it reveals some bugs covered by the trans_mutex.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: bug caused by removal of trans_mutex? (Was: Re: kernel BUG at fs/btrfs/extent-tree.c:6164!)
2011-06-13 7:13 ` bug caused by removal of trans_mutex? (Was: Re: kernel BUG at fs/btrfs/extent-tree.c:6164!) Li Zefan
@ 2011-06-13 7:49 ` Yan, Zheng
2011-06-13 8:26 ` Li Zefan
2011-06-13 13:12 ` Chris Mason
` (2 subsequent siblings)
3 siblings, 1 reply; 19+ messages in thread
From: Yan, Zheng @ 2011-06-13 7:49 UTC (permalink / raw)
To: Li Zefan; +Cc: Tsutomu Itoh, Chris Mason, liubo, Linux Btrfs, Josef Bacik
Add a mutex to btrfs_init_reloc_root() to prevent the reloc tree
creation from concurrent execution.
On Mon, Jun 13, 2011 at 3:13 PM, Li Zefan <lizf@cn.fujitsu.com> wrote:
> Cc: Josef
>
>>>>>>>>> I encountered following panic using 'btrfs-unstable + for-lin=
us'
>>>>>>>>> kernel.
>>>>>>>>>
>>>>>>>>> I ran "btrfs fi bal /test5" command, and mount option of /tes=
t5
>>>>>>>>> is as follows:
>>>>>>>>>
>>>>>>>>> =A0/dev/sdc3 on /test5 type btrfs (rw,space_cache,compress=3D=
lzo,inode_cache)
>>>>>>>>>
>>>>>>>> So, just a "btrfs fi bal" would lead to the bug?
>>>>>>> I think so.
>>>
>>> It should be specific to the inode caching code. =A0The balancing c=
ode is
>>> finding the inode map cache extents, but it doesn't know how to rel=
ocate
>>> them.
>>
>> However, the panic has occurred even if inode_cahce is turned off.
>> Is this another problem?
>>
>
> I don't think free inode cache isthe cause of the bug here (even if i=
node_cache
> is turned on).
>
> What I have found out is:
>
> 1. git checkout a4abeea41adfa3c143c289045f4625dfaeba2212
>
> So the top commit is the removal of trans_mutex and no delayed_inode =
patch
> or free inode cache patchset in the tree, and bug can be triggered.
>
> 2. git checkout 2a1eb4614d984d5cd4c928784e9afcf5c07f93be
>
> So the top commit is the one before trans_mutex removal, and no bug t=
riggered.
>
> 3. test linus' tree
>
> bug triggered.
>
> 4. revert that suspicoius commit manually from linus' tree
>
> no bug.
>
> so either that commit is buggy or it reveals some bugs covered by the=
trans_mutex.
>
> --
> 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 =A0http://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] 19+ messages in thread
* Re: bug caused by removal of trans_mutex? (Was: Re: kernel BUG at fs/btrfs/extent-tree.c:6164!)
2011-06-13 7:49 ` Yan, Zheng
@ 2011-06-13 8:26 ` Li Zefan
0 siblings, 0 replies; 19+ messages in thread
From: Li Zefan @ 2011-06-13 8:26 UTC (permalink / raw)
To: Yan, Zheng ; +Cc: Tsutomu Itoh, Chris Mason, liubo, Linux Btrfs, Josef Bacik
Yan, Zheng wrote:
> Add a mutex to btrfs_init_reloc_root() to prevent the reloc tree
> creation from concurrent execution.
Thanks!
Unfortunately I can still encounter BUG() in difference places in
each run:
kernel BUG at fs/btrfs/extent-tree.c:6173!
kernel BUG at fs/btrfs/volumes.c:2567!
>
> On Mon, Jun 13, 2011 at 3:13 PM, Li Zefan <lizf@cn.fujitsu.com> wrote:
>> Cc: Josef
>>
>>>>>>>>>> I encountered following panic using 'btrfs-unstable + for-linus'
>>>>>>>>>> kernel.
>>>>>>>>>>
>>>>>>>>>> I ran "btrfs fi bal /test5" command, and mount option of /test5
>>>>>>>>>> is as follows:
>>>>>>>>>>
>>>>>>>>>> /dev/sdc3 on /test5 type btrfs (rw,space_cache,compress=lzo,inode_cache)
>>>>>>>>>>
>>>>>>>>> So, just a "btrfs fi bal" would lead to the bug?
>>>>>>>> I think so.
>>>>
>>>> It should be specific to the inode caching code. The balancing code is
>>>> finding the inode map cache extents, but it doesn't know how to relocate
>>>> them.
>>>
>>> However, the panic has occurred even if inode_cahce is turned off.
>>> Is this another problem?
>>>
>>
>> I don't think free inode cache isthe cause of the bug here (even if inode_cache
>> is turned on).
>>
>> What I have found out is:
>>
>> 1. git checkout a4abeea41adfa3c143c289045f4625dfaeba2212
>>
>> So the top commit is the removal of trans_mutex and no delayed_inode patch
>> or free inode cache patchset in the tree, and bug can be triggered.
>>
>> 2. git checkout 2a1eb4614d984d5cd4c928784e9afcf5c07f93be
>>
>> So the top commit is the one before trans_mutex removal, and no bug triggered.
>>
>> 3. test linus' tree
>>
>> bug triggered.
>>
>> 4. revert that suspicoius commit manually from linus' tree
>>
>> no bug.
>>
>> so either that commit is buggy or it reveals some bugs covered by the trans_mutex.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: bug caused by removal of trans_mutex? (Was: Re: kernel BUG at fs/btrfs/extent-tree.c:6164!)
2011-06-13 7:13 ` bug caused by removal of trans_mutex? (Was: Re: kernel BUG at fs/btrfs/extent-tree.c:6164!) Li Zefan
2011-06-13 7:49 ` Yan, Zheng
@ 2011-06-13 13:12 ` Chris Mason
2011-06-13 15:18 ` Chris Mason
2011-06-13 14:58 ` Yan, Zheng
2011-06-14 6:53 ` Yan, Zheng
3 siblings, 1 reply; 19+ messages in thread
From: Chris Mason @ 2011-06-13 13:12 UTC (permalink / raw)
To: Li Zefan; +Cc: Tsutomu Itoh, liubo, Linux Btrfs, Josef Bacik
Excerpts from Li Zefan's message of 2011-06-13 03:13:13 -0400:
> Cc: Josef
>
> >>>>>>>> I encountered following panic using 'btrfs-unstable + for-linus'
> >>>>>>>> kernel.
> >>>>>>>>
> >>>>>>>> I ran "btrfs fi bal /test5" command, and mount option of /test5
> >>>>>>>> is as follows:
> >>>>>>>>
> >>>>>>>> /dev/sdc3 on /test5 type btrfs (rw,space_cache,compress=lzo,inode_cache)
> >>>>>>>>
> >>>>>>> So, just a "btrfs fi bal" would lead to the bug?
> >>>>>> I think so.
> >>
> >> It should be specific to the inode caching code. The balancing code is
> >> finding the inode map cache extents, but it doesn't know how to relocate
> >> them.
> >
> > However, the panic has occurred even if inode_cahce is turned off.
> > Is this another problem?
> >
>
> I don't think free inode cache isthe cause of the bug here (even if inode_cache
> is turned on).
>
> What I have found out is:
>
> 1. git checkout a4abeea41adfa3c143c289045f4625dfaeba2212
>
> So the top commit is the removal of trans_mutex and no delayed_inode patch
> or free inode cache patchset in the tree, and bug can be triggered.
>
> 2. git checkout 2a1eb4614d984d5cd4c928784e9afcf5c07f93be
>
> So the top commit is the one before trans_mutex removal, and no bug triggered.
>
> 3. test linus' tree
>
> bug triggered.
>
> 4. revert that suspicoius commit manually from linus' tree
>
> no bug.
>
> so either that commit is buggy or it reveals some bugs covered by the trans_mutex.
Ok, what dataset are you balancing?
What are you doing concurrently with the balance?
I haven't been able to trigger this here.
-chris
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: bug caused by removal of trans_mutex? (Was: Re: kernel BUG at fs/btrfs/extent-tree.c:6164!)
2011-06-13 7:13 ` bug caused by removal of trans_mutex? (Was: Re: kernel BUG at fs/btrfs/extent-tree.c:6164!) Li Zefan
2011-06-13 7:49 ` Yan, Zheng
2011-06-13 13:12 ` Chris Mason
@ 2011-06-13 14:58 ` Yan, Zheng
2011-06-13 15:09 ` Chris Mason
2011-06-13 19:55 ` Chris Mason
2011-06-14 6:53 ` Yan, Zheng
3 siblings, 2 replies; 19+ messages in thread
From: Yan, Zheng @ 2011-06-13 14:58 UTC (permalink / raw)
To: Li Zefan; +Cc: Tsutomu Itoh, Chris Mason, liubo, Linux Btrfs, Josef Bacik
The usage of trans_mutex in relocation code is subtle. It controls
interaction of relocation
with transaction start, transaction commit and snapshot creation.
Simple replacing
trans_mutex with trans_lock is wrong.
On Mon, Jun 13, 2011 at 3:13 PM, Li Zefan <lizf@cn.fujitsu.com> wrote:
> Cc: Josef
>
>>>>>>>>> I encountered following panic using 'btrfs-unstable + for-lin=
us'
>>>>>>>>> kernel.
>>>>>>>>>
>>>>>>>>> I ran "btrfs fi bal /test5" command, and mount option of /tes=
t5
>>>>>>>>> is as follows:
>>>>>>>>>
>>>>>>>>> =A0/dev/sdc3 on /test5 type btrfs (rw,space_cache,compress=3D=
lzo,inode_cache)
>>>>>>>>>
>>>>>>>> So, just a "btrfs fi bal" would lead to the bug?
>>>>>>> I think so.
>>>
>>> It should be specific to the inode caching code. =A0The balancing c=
ode is
>>> finding the inode map cache extents, but it doesn't know how to rel=
ocate
>>> them.
>>
>> However, the panic has occurred even if inode_cahce is turned off.
>> Is this another problem?
>>
>
> I don't think free inode cache isthe cause of the bug here (even if i=
node_cache
> is turned on).
>
> What I have found out is:
>
> 1. git checkout a4abeea41adfa3c143c289045f4625dfaeba2212
>
> So the top commit is the removal of trans_mutex and no delayed_inode =
patch
> or free inode cache patchset in the tree, and bug can be triggered.
>
> 2. git checkout 2a1eb4614d984d5cd4c928784e9afcf5c07f93be
>
> So the top commit is the one before trans_mutex removal, and no bug t=
riggered.
>
> 3. test linus' tree
>
> bug triggered.
>
> 4. revert that suspicoius commit manually from linus' tree
>
> no bug.
>
> so either that commit is buggy or it reveals some bugs covered by the=
trans_mutex.
>
> --
> 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 =A0http://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] 19+ messages in thread
* Re: bug caused by removal of trans_mutex? (Was: Re: kernel BUG at fs/btrfs/extent-tree.c:6164!)
2011-06-13 14:58 ` Yan, Zheng
@ 2011-06-13 15:09 ` Chris Mason
2011-06-13 19:55 ` Chris Mason
1 sibling, 0 replies; 19+ messages in thread
From: Chris Mason @ 2011-06-13 15:09 UTC (permalink / raw)
To: Yan, Zheng; +Cc: Li Zefan, Tsutomu Itoh, liubo, Linux Btrfs, Josef Bacik
Excerpts from Yan, Zheng's message of 2011-06-13 10:58:35 -0400:
> The usage of trans_mutex in relocation code is subtle. It controls
> interaction of relocation
> with transaction start, transaction commit and snapshot creation.
> Simple replacing
> trans_mutex with trans_lock is wrong.
What requirements of the relocation stuff are we currently missing? I'=
d
rather add extra waiting for relocation than go back to the mutex.
-chris
>=20
> On Mon, Jun 13, 2011 at 3:13 PM, Li Zefan <lizf@cn.fujitsu.com> wrote=
:
> > Cc: Josef
> >
> >>>>>>>>> I encountered following panic using 'btrfs-unstable + for-l=
inus'
> >>>>>>>>> kernel.
> >>>>>>>>>
> >>>>>>>>> I ran "btrfs fi bal /test5" command, and mount option of /t=
est5
> >>>>>>>>> is as follows:
> >>>>>>>>>
> >>>>>>>>> =C2=A0/dev/sdc3 on /test5 type btrfs (rw,space_cache,compre=
ss=3Dlzo,inode_cache)
> >>>>>>>>>
> >>>>>>>> So, just a "btrfs fi bal" would lead to the bug?
> >>>>>>> I think so.
> >>>
> >>> It should be specific to the inode caching code. =C2=A0The balanc=
ing code is
> >>> finding the inode map cache extents, but it doesn't know how to r=
elocate
> >>> them.
> >>
> >> However, the panic has occurred even if inode_cahce is turned off.
> >> Is this another problem?
> >>
> >
> > I don't think free inode cache isthe cause of the bug here (even if=
inode_cache
> > is turned on).
> >
> > What I have found out is:
> >
> > 1. git checkout a4abeea41adfa3c143c289045f4625dfaeba2212
> >
> > So the top commit is the removal of trans_mutex and no delayed_inod=
e patch
> > or free inode cache patchset in the tree, and bug can be triggered.
> >
> > 2. git checkout 2a1eb4614d984d5cd4c928784e9afcf5c07f93be
> >
> > So the top commit is the one before trans_mutex removal, and no bug=
triggered.
> >
> > 3. test linus' tree
> >
> > bug triggered.
> >
> > 4. revert that suspicoius commit manually from linus' tree
> >
> > no bug.
> >
> > so either that commit is buggy or it reveals some bugs covered by t=
he trans_mutex.
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-btr=
fs" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at =C2=A0http://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] 19+ messages in thread
* Re: bug caused by removal of trans_mutex? (Was: Re: kernel BUG at fs/btrfs/extent-tree.c:6164!)
2011-06-13 13:12 ` Chris Mason
@ 2011-06-13 15:18 ` Chris Mason
0 siblings, 0 replies; 19+ messages in thread
From: Chris Mason @ 2011-06-13 15:18 UTC (permalink / raw)
To: Chris Mason; +Cc: Li Zefan, Tsutomu Itoh, liubo, Linux Btrfs, Josef Bacik
Excerpts from Chris Mason's message of 2011-06-13 09:12:06 -0400:
> Excerpts from Li Zefan's message of 2011-06-13 03:13:13 -0400:
> > Cc: Josef
> >
> > >>>>>>>> I encountered following panic using 'btrfs-unstable + for-linus'
> > >>>>>>>> kernel.
> > >>>>>>>>
> > >>>>>>>> I ran "btrfs fi bal /test5" command, and mount option of /test5
> > >>>>>>>> is as follows:
> > >>>>>>>>
> > >>>>>>>> /dev/sdc3 on /test5 type btrfs (rw,space_cache,compress=lzo,inode_cache)
> > >>>>>>>>
> > >>>>>>> So, just a "btrfs fi bal" would lead to the bug?
> > >>>>>> I think so.
> > >>
> > >> It should be specific to the inode caching code. The balancing code is
> > >> finding the inode map cache extents, but it doesn't know how to relocate
> > >> them.
> > >
> > > However, the panic has occurred even if inode_cahce is turned off.
> > > Is this another problem?
> > >
> >
> > I don't think free inode cache isthe cause of the bug here (even if inode_cache
> > is turned on).
> >
> > What I have found out is:
> >
> > 1. git checkout a4abeea41adfa3c143c289045f4625dfaeba2212
> >
> > So the top commit is the removal of trans_mutex and no delayed_inode patch
> > or free inode cache patchset in the tree, and bug can be triggered.
> >
> > 2. git checkout 2a1eb4614d984d5cd4c928784e9afcf5c07f93be
> >
> > So the top commit is the one before trans_mutex removal, and no bug triggered.
> >
> > 3. test linus' tree
> >
> > bug triggered.
> >
> > 4. revert that suspicoius commit manually from linus' tree
> >
> > no bug.
> >
> > so either that commit is buggy or it reveals some bugs covered by the trans_mutex.
>
> Ok, what dataset are you balancing?
>
> What are you doing concurrently with the balance?
>
> I haven't been able to trigger this here.
There we go. It took about two hours but I hit this with the balancing
exerciser that was posted.
-chris
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: bug caused by removal of trans_mutex? (Was: Re: kernel BUG at fs/btrfs/extent-tree.c:6164!)
2011-06-13 14:58 ` Yan, Zheng
2011-06-13 15:09 ` Chris Mason
@ 2011-06-13 19:55 ` Chris Mason
2011-06-14 3:24 ` Yan, Zheng
1 sibling, 1 reply; 19+ messages in thread
From: Chris Mason @ 2011-06-13 19:55 UTC (permalink / raw)
To: Yan, Zheng; +Cc: Li Zefan, Tsutomu Itoh, liubo, Linux Btrfs, Josef Bacik
Excerpts from Yan, Zheng's message of 2011-06-13 10:58:35 -0400:
> The usage of trans_mutex in relocation code is subtle. It controls
> interaction of relocation
> with transaction start, transaction commit and snapshot creation.
> Simple replacing
> trans_mutex with trans_lock is wrong.
So, I've got a mutex around the reloc_root here and that was almost but
not quite enough. It looks like the biggest problem is that we need to
wait in btrfs_record_root_in_trans for anyone inside merge_reloc_roots.
I'm surviving much longer with a patch in place that synchronizes
btrfs_record_root_in_trans better.
Zheng if you have other comments on the locking please let me know.
-chris
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: bug caused by removal of trans_mutex? (Was: Re: kernel BUG at fs/btrfs/extent-tree.c:6164!)
2011-06-13 19:55 ` Chris Mason
@ 2011-06-14 3:24 ` Yan, Zheng
2011-06-14 5:44 ` Li Zefan
0 siblings, 1 reply; 19+ messages in thread
From: Yan, Zheng @ 2011-06-14 3:24 UTC (permalink / raw)
To: Chris Mason; +Cc: Li Zefan, Tsutomu Itoh, liubo, Linux Btrfs, Josef Bacik
On Tue, Jun 14, 2011 at 3:55 AM, Chris Mason <chris.mason@oracle.com> w=
rote:
> Excerpts from Yan, Zheng's message of 2011-06-13 10:58:35 -0400:
>> The usage of trans_mutex in relocation code is subtle. It controls
>> interaction of relocation
>> with transaction start, transaction commit and snapshot creation.
>> Simple replacing
>> trans_mutex with trans_lock is wrong.
>
> So, I've got a mutex around the reloc_root here and that was almost b=
ut
> not quite enough. =A0It looks like the biggest problem is that we nee=
d to
> wait in btrfs_record_root_in_trans for anyone inside merge_reloc_root=
s.
>
> I'm surviving much longer with a patch in place that synchronizes
> btrfs_record_root_in_trans better.
>
> Zheng if you have other comments on the locking please let me know.
>
following untested patch may help.
---
diff --git a/fs/btrfs/ctree.h b/fs/btrfs/ctree.h
index 378b5b4..0b20dda 100644
--- a/fs/btrfs/ctree.h
+++ b/fs/btrfs/ctree.h
@@ -951,6 +951,7 @@ struct btrfs_fs_info {
struct mutex cleaner_mutex;
struct mutex chunk_mutex;
struct mutex volume_mutex;
+ struct mutex reloc_mutex;
/*
* this protects the ordered operations list only while we are
* processing all of the entries on it. This way we make
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 9f68c68..28f8b11 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -1714,6 +1714,7 @@ struct btrfs_root *open_ctree(struct super_block =
*sb,
mutex_init(&fs_info->transaction_kthread_mutex);
mutex_init(&fs_info->cleaner_mutex);
mutex_init(&fs_info->volume_mutex);
+ mutex_init(&fs_info->reloc_mutex);
init_rwsem(&fs_info->extent_commit_sem);
init_rwsem(&fs_info->cleanup_work_sem);
init_rwsem(&fs_info->subvol_sem);
diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index b1ef27c..620e4af 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -1330,18 +1330,20 @@ int btrfs_init_reloc_root(struct
btrfs_trans_handle *trans,
struct btrfs_root *root)
{
struct btrfs_root *reloc_root;
- struct reloc_control *rc =3D root->fs_info->reloc_ctl;
+ struct reloc_control *rc;
int clear_rsv =3D 0;
+ mutex_lock(&root->fs_info->reloc_mutex);
if (root->reloc_root) {
reloc_root =3D root->reloc_root;
reloc_root->last_trans =3D trans->transid;
- return 0;
+ goto unlock;
}
+ rc =3D root->fs_info->reloc_ctl;
if (!rc || !rc->create_reloc_tree ||
root->root_key.objectid =3D=3D BTRFS_TREE_RELOC_OBJECTID)
- return 0;
+ goto unlock;
if (!trans->block_rsv) {
trans->block_rsv =3D rc->block_rsv;
@@ -1353,6 +1355,8 @@ int btrfs_init_reloc_root(struct
btrfs_trans_handle *trans,
__add_reloc_root(reloc_root);
root->reloc_root =3D reloc_root;
+unlock:
+ mutex_unlock(&root->fs_info->reloc_mutex);
return 0;
}
@@ -1367,8 +1371,9 @@ int btrfs_update_reloc_root(struct
btrfs_trans_handle *trans,
int del =3D 0;
int ret;
+ mutex_lock(&root->fs_info->reloc_mutex);
if (!root->reloc_root)
- return 0;
+ goto unlock;
reloc_root =3D root->reloc_root;
root_item =3D &reloc_root->root_item;
@@ -1390,6 +1395,8 @@ int btrfs_update_reloc_root(struct
btrfs_trans_handle *trans,
ret =3D btrfs_update_root(trans, root->fs_info->tree_root,
&reloc_root->root_key, root_item);
BUG_ON(ret);
+unlock:
+ mutex_unlock(&root->fs_info->reloc_mutex);
return 0;
}
@@ -2142,10 +2149,10 @@ int prepare_to_merge(struct reloc_control *rc, =
int err)
u64 num_bytes =3D 0;
int ret;
- spin_lock(&root->fs_info->trans_lock);
+ mutex_lock(&root->fs_info->reloc_mutex);
rc->merging_rsv_size +=3D root->nodesize * (BTRFS_MAX_LEVEL - 1) * 2;
rc->merging_rsv_size +=3D rc->nodes_relocated * 2;
- spin_unlock(&root->fs_info->trans_lock);
+ mutex_unlock(&root->fs_info->reloc_mutex);
again:
if (!err) {
num_bytes =3D rc->merging_rsv_size;
@@ -2214,9 +2221,9 @@ int merge_reloc_roots(struct reloc_control *rc)
int ret;
again:
root =3D rc->extent_root;
- spin_lock(&root->fs_info->trans_lock);
+ mutex_lock(&root->fs_info->reloc_mutex);
list_splice_init(&rc->reloc_roots, &reloc_roots);
- spin_unlock(&root->fs_info->trans_lock);
+ mutex_unlock(&root->fs_info->reloc_mutex);
while (!list_empty(&reloc_roots)) {
found =3D 1;
@@ -3590,17 +3597,17 @@ next:
static void set_reloc_control(struct reloc_control *rc)
{
struct btrfs_fs_info *fs_info =3D rc->extent_root->fs_info;
- spin_lock(&fs_info->trans_lock);
+ mutex_lock(&fs_info->reloc_mutex);
fs_info->reloc_ctl =3D rc;
- spin_unlock(&fs_info->trans_lock);
+ mutex_unlock(&fs_info->reloc_mutex);
}
static void unset_reloc_control(struct reloc_control *rc)
{
struct btrfs_fs_info *fs_info =3D rc->extent_root->fs_info;
- spin_lock(&fs_info->trans_lock);
+ mutex_lock(&fs_info->reloc_mutex);
fs_info->reloc_ctl =3D NULL;
- spin_unlock(&fs_info->trans_lock);
+ mutex_unlock(&fs_info->reloc_mutex);
}
static int check_extent_flags(u64 flags)
@@ -4335,16 +4342,16 @@ void btrfs_reloc_pre_snapshot(struct
btrfs_trans_handle *trans,
struct btrfs_pending_snapshot *pending,
u64 *bytes_to_reserve)
{
- struct btrfs_root *root;
+ struct btrfs_root *root =3D pending->root;
struct reloc_control *rc;
- root =3D pending->root;
+ mutex_lock(&root->fs_info->reloc_mutex);
if (!root->reloc_root)
- return;
+ goto unlock;
rc =3D root->fs_info->reloc_ctl;
if (!rc->merge_reloc_tree)
- return;
+ goto unlock;
root =3D root->reloc_root;
BUG_ON(btrfs_root_refs(&root->root_item) =3D=3D 0);
@@ -4359,6 +4366,8 @@ void btrfs_reloc_pre_snapshot(struct
btrfs_trans_handle *trans,
* reserve extra space.
*/
*bytes_to_reserve +=3D rc->nodes_relocated;
+unlock:
+ mutex_unlock(&root->fs_info->reloc_mutex);
}
/*
@@ -4374,8 +4383,9 @@ void btrfs_reloc_post_snapshot(struct
btrfs_trans_handle *trans,
struct reloc_control *rc;
int ret;
+ mutex_lock(&root->fs_info->reloc_mutex);
if (!root->reloc_root)
- return;
+ goto unlock;
rc =3D root->fs_info->reloc_ctl;
rc->merging_rsv_size +=3D rc->nodes_relocated;
@@ -4398,4 +4408,6 @@ void btrfs_reloc_post_snapshot(struct
btrfs_trans_handle *trans,
ret =3D clone_backref_node(trans, rc, root, reloc_root);
BUG_ON(ret);
}
+unlock:
+ mutex_unlock(&root->fs_info->reloc_mutex);
}
--
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 related [flat|nested] 19+ messages in thread
* Re: bug caused by removal of trans_mutex? (Was: Re: kernel BUG at fs/btrfs/extent-tree.c:6164!)
2011-06-14 3:24 ` Yan, Zheng
@ 2011-06-14 5:44 ` Li Zefan
0 siblings, 0 replies; 19+ messages in thread
From: Li Zefan @ 2011-06-14 5:44 UTC (permalink / raw)
To: Yan, Zheng ; +Cc: Chris Mason, Tsutomu Itoh, liubo, Linux Btrfs, Josef Bacik
Yan, Zheng wrote:
> On Tue, Jun 14, 2011 at 3:55 AM, Chris Mason <chris.mason@oracle.com> wrote:
>> Excerpts from Yan, Zheng's message of 2011-06-13 10:58:35 -0400:
>>> The usage of trans_mutex in relocation code is subtle. It controls
>>> interaction of relocation
>>> with transaction start, transaction commit and snapshot creation.
>>> Simple replacing
>>> trans_mutex with trans_lock is wrong.
>>
>> So, I've got a mutex around the reloc_root here and that was almost but
>> not quite enough. It looks like the biggest problem is that we need to
>> wait in btrfs_record_root_in_trans for anyone inside merge_reloc_roots.
>>
>> I'm surviving much longer with a patch in place that synchronizes
>> btrfs_record_root_in_trans better.
>>
>> Zheng if you have other comments on the locking please let me know.
>>
>
> following untested patch may help.
I've tested this patch, and the bug was triggered in minutes as usual.
Also I've tested a patch in an offline email from Chris, which survived
the test.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: bug caused by removal of trans_mutex? (Was: Re: kernel BUG at fs/btrfs/extent-tree.c:6164!)
2011-06-13 7:13 ` bug caused by removal of trans_mutex? (Was: Re: kernel BUG at fs/btrfs/extent-tree.c:6164!) Li Zefan
` (2 preceding siblings ...)
2011-06-13 14:58 ` Yan, Zheng
@ 2011-06-14 6:53 ` Yan, Zheng
3 siblings, 0 replies; 19+ messages in thread
From: Yan, Zheng @ 2011-06-14 6:53 UTC (permalink / raw)
To: Li Zefan; +Cc: Tsutomu Itoh, Chris Mason, liubo, Linux Btrfs, Josef Bacik
I found another bug. There are codes (btrfs_save_ino_cache) that
modify fs trees after
create_pending_snapshots is called. This can corrupt your fs.
On Mon, Jun 13, 2011 at 3:13 PM, Li Zefan <lizf@cn.fujitsu.com> wrote:
> Cc: Josef
>
>>>>>>>>> I encountered following panic using 'btrfs-unstable + for-lin=
us'
>>>>>>>>> kernel.
>>>>>>>>>
>>>>>>>>> I ran "btrfs fi bal /test5" command, and mount option of /tes=
t5
>>>>>>>>> is as follows:
>>>>>>>>>
>>>>>>>>> =A0/dev/sdc3 on /test5 type btrfs (rw,space_cache,compress=3D=
lzo,inode_cache)
>>>>>>>>>
>>>>>>>> So, just a "btrfs fi bal" would lead to the bug?
>>>>>>> I think so.
>>>
>>> It should be specific to the inode caching code. =A0The balancing c=
ode is
>>> finding the inode map cache extents, but it doesn't know how to rel=
ocate
>>> them.
>>
>> However, the panic has occurred even if inode_cahce is turned off.
>> Is this another problem?
>>
>
> I don't think free inode cache isthe cause of the bug here (even if i=
node_cache
> is turned on).
>
> What I have found out is:
>
> 1. git checkout a4abeea41adfa3c143c289045f4625dfaeba2212
>
> So the top commit is the removal of trans_mutex and no delayed_inode =
patch
> or free inode cache patchset in the tree, and bug can be triggered.
>
> 2. git checkout 2a1eb4614d984d5cd4c928784e9afcf5c07f93be
>
> So the top commit is the one before trans_mutex removal, and no bug t=
riggered.
>
> 3. test linus' tree
>
> bug triggered.
>
> 4. revert that suspicoius commit manually from linus' tree
>
> no bug.
>
> so either that commit is buggy or it reveals some bugs covered by the=
trans_mutex.
>
> --
> 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 =A0http://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] 19+ messages in thread
end of thread, other threads:[~2011-06-14 6:53 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-06-06 8:33 kernel BUG at fs/btrfs/extent-tree.c:6164! Tsutomu Itoh
2011-06-07 5:31 ` liubo
2011-06-07 5:59 ` Tsutomu Itoh
2011-06-07 6:17 ` Tsutomu Itoh
2011-06-07 8:24 ` Tsutomu Itoh
2011-06-07 8:36 ` liubo
2011-06-07 15:46 ` Chris Mason
2011-06-08 5:12 ` Tsutomu Itoh
2011-06-13 7:13 ` bug caused by removal of trans_mutex? (Was: Re: kernel BUG at fs/btrfs/extent-tree.c:6164!) Li Zefan
2011-06-13 7:49 ` Yan, Zheng
2011-06-13 8:26 ` Li Zefan
2011-06-13 13:12 ` Chris Mason
2011-06-13 15:18 ` Chris Mason
2011-06-13 14:58 ` Yan, Zheng
2011-06-13 15:09 ` Chris Mason
2011-06-13 19:55 ` Chris Mason
2011-06-14 3:24 ` Yan, Zheng
2011-06-14 5:44 ` Li Zefan
2011-06-14 6:53 ` Yan, Zheng
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).