Re: BUG on 3.5.0
On Wed, Aug 08, 2012 at 01:58:33PM -0400, Chris Mason wrote: On Wed, Aug 08, 2012 at 11:56:06AM -0600, Lluís Batlle i Rossell wrote: On Wed, Aug 08, 2012 at 01:40:11PM -0400, Josef Bacik wrote: On Wed, Aug 08, 2012 at 11:36:45AM -0600, David Sterba wrote: according to assembly, owner is in R15, BTRFS_FIRST_FREE_OBJECTID is 256, so owner == 1 This is fixed already in btrfs-next. Thanks, Ok, thank you. Does it mean it will get into the next stable? Or it's for 3.6? Is it only 'balance' that triggers it? I'm bringing the fix in for my next pull request, so it will be available against both 3.5 and 3.6 Am I right that it is not in 3.5.1? Regards, Lluís. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG on 3.5.0
On 08/10/2012 07:49 PM, Lluís Batlle i Rossell wrote: Am I right that it is not in 3.5.1? I don't believe fixes can be considered for stable releases until they're in the mainline, so until Linus processes that last merge request from Chris it can't happen (and he's not done so yet). That said, there was one btrfs fix merged into 3.5.1: Chris Mason (1): Btrfs: call the ordered free operation without any locks held But I suspect that is not the fix you are looking for.. cheers, Chris -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG on 3.5.0
On Fri, Aug 10, 2012 at 06:49:10AM -0600, Chris Samuel wrote: On 08/10/2012 07:49 PM, Lluís Batlle i Rossell wrote: Am I right that it is not in 3.5.1? I don't believe fixes can be considered for stable releases until they're in the mainline, so until Linus processes that last merge request from Chris it can't happen (and he's not done so yet). That said, there was one btrfs fix merged into 3.5.1: Chris Mason (1): Btrfs: call the ordered free operation without any locks held But I suspect that is not the fix you are looking for.. Right, this fix was bigger than we could send to stable yet. For now you need to run my for-linus tree against 3.5 (or 3.5.1) for the fixes. -chris -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG on 3.5.0
Hi,
On Wed, Aug 08, 2012 at 06:18:19PM +0200, Lluís Batlle i Rossell wrote:
I attach dmesg.txt, and the disasm of insert_inline_extent_backref. That
disasm
was a bit tricky; my objdump does not seem to understand the btrfs.ko.
thanks, added a few bits to the picture
[ 6095.255745] [ cut here ]
[ 6095.255757] kernel BUG at fs/btrfs/extent-tree.c:1769!
[ 6095.255762] invalid opcode: [#1] SMP
[ 6095.255769] CPU 1
[ 6095.255772] Modules linked in:4[ 6095.255897] jbd ext2 mbcache
[ 6095.255904]
[ 6095.255910] Pid: 30286, comm: btrfs Tainted: P O 3.5.0 #1 System
manufacturer System Product Name/M4A79 Deluxe
[ 6095.255920] RIP: 0010:[a0191c9f] [a0191c9f]
insert_inline_extent_backref+0xef/0x100 [btrfs]
[ 6095.255965] RSP: 0018:880028723788 EFLAGS: 00010293
[ 6095.255970] RAX: RBX: 8801275b3510 RCX:
8800287237d0
[ 6095.255974] RDX: 8801275b3510 RSI: 0001 RDI:
[ 6095.255978] RBP: 880028723808 R08: 0bf2 R09:
880028723698
[ 6095.255981] R10: R11: R12:
880126918800
[ 6095.255985] R13: 88012afdd280 R14: R15:
0001
1753 static noinline_for_stack
1754 int insert_inline_extent_backref(struct btrfs_trans_handle *trans,
1755 struct btrfs_root *root,
1756 struct btrfs_path *path,
1757 u64 bytenr, u64 num_bytes, u64 parent,
1758 u64 root_objectid, u64 owner,
1759 u64 offset, int refs_to_add,
1760 struct btrfs_delayed_extent_op *extent_op)
1761 {
1762 struct btrfs_extent_inline_ref *iref;
1763 int ret;
1764
1765 ret = lookup_inline_extent_backref(trans, root, path, iref,
1766bytenr, num_bytes, parent,
1767root_objectid, owner, offset,
1);
1768 if (ret == 0) {
1769 BUG_ON(owner BTRFS_FIRST_FREE_OBJECTID);
15c17:49 81 ff ff 00 00 00 cmp $0xff,%r15
15c1e:76 7fjbe 0x15c9f
according to assembly, owner is in R15, BTRFS_FIRST_FREE_OBJECTID is
256, so owner == 1
[ 6095.255990] FS: 7fbdb0dbc740() GS:88012fc4()
knlGS:
[ 6095.255994] CS: 0010 DS: ES: CR0: 8005003b
[ 6095.255998] CR2: 006b3c60 CR3: 5e5df000 CR4:
07e0
[ 6095.256002] DR0: DR1: DR2:
[ 6095.256006] DR3: DR6: 0ff0 DR7:
0400
[ 6095.256011] Process btrfs (pid: 30286, threadinfo 880028722000, task
880080194440)
[ 6095.256013] Stack:
[ 6095.256016] 0005 0001
[ 6095.256025] 0001 880122fb37e0 880028723858
0090
[ 6095.256032] 880126918400 0be9 880126918400
8801275b3510
[ 6095.256040] Call Trace:
[ 6095.256079] [a0191d4f] __btrfs_inc_extent_ref+0x9f/0x1f0 [btrfs]
[ 6095.256117] [a0194cdd] ? btrfs_reduce_alloc_profile+0x5d/0x120
[btrfs]
[ 6095.256154] [a019874f] run_clustered_refs+0x93f/0xa00 [btrfs]
[ 6095.256190] [a01989b2] btrfs_run_delayed_refs+0x1a2/0x460
[btrfs]
[ 6095.256234] [a01f0875] ? drop_backref_node+0xa5/0xb0 [btrfs]
[ 6095.256243] [8114a5cf] ? kmem_cache_free+0x2f/0x110
[ 6095.256286] [a01f559d] ? relocate_tree_blocks+0x5ad/0x650
[btrfs]
[ 6095.256327] [a01aa561] __btrfs_end_transaction+0xd1/0x360
[btrfs]
[ 6095.256368] [a01aa848] btrfs_end_transaction_throttle+0x18/0x20
[btrfs]
[ 6095.256410] [a01f66ec] relocate_block_group+0x51c/0x650 [btrfs]
[ 6095.256452] [a01f69df] btrfs_relocate_block_group+0x1bf/0x2f0
[btrfs]
[ 6095.256495] [a01d31b5] btrfs_relocate_chunk.isra.53+0x75/0x730
[btrfs]
[ 6095.256505] [8107a673] ? __wake_up+0x53/0x70
[ 6095.256548] [a01cfb17] ? free_extent_buffer+0x37/0x90 [btrfs]
[ 6095.256590] [a01d7527] btrfs_balance+0x857/0xd10 [btrfs]
[ 6095.256633] [a01de8e4] btrfs_ioctl_balance+0x134/0x440 [btrfs]
[ 6095.256676] [a01e0d9f] btrfs_ioctl+0xb8f/0x1380 [btrfs]
[ 6095.256686] [810419d8] ? do_page_fault+0x1c8/0x460
[ 6095.256694] [811694e8] do_vfs_ioctl+0x98/0x550
[ 6095.256701] [8114a5cf] ? kmem_cache_free+0x2f/0x110
[ 6095.256708] [81169a31] sys_ioctl+0x91/0xa0
[ 6095.256717] [813e0d69] system_call_fastpath+0x16/0x1b
[ 6095.256720] Code: 48 89 da 4c 89 e6 4c 89 ef 4c 89 3c 24 48 89 44 24 18 8b
45 28 89 44 24 10 48 8b 45 20 48 89 44 24 08 e8 b5 eb ff ff 31 c0 eb a1 0f
0b
Re: BUG on 3.5.0
On Wed, Aug 08, 2012 at 11:36:45AM -0600, David Sterba wrote:
Hi,
On Wed, Aug 08, 2012 at 06:18:19PM +0200, Lluís Batlle i Rossell wrote:
I attach dmesg.txt, and the disasm of insert_inline_extent_backref. That
disasm
was a bit tricky; my objdump does not seem to understand the btrfs.ko.
thanks, added a few bits to the picture
[ 6095.255745] [ cut here ]
[ 6095.255757] kernel BUG at fs/btrfs/extent-tree.c:1769!
[ 6095.255762] invalid opcode: [#1] SMP
[ 6095.255769] CPU 1
[ 6095.255772] Modules linked in:4[ 6095.255897] jbd ext2 mbcache
[ 6095.255904]
[ 6095.255910] Pid: 30286, comm: btrfs Tainted: P O 3.5.0 #1
System manufacturer System Product Name/M4A79 Deluxe
[ 6095.255920] RIP: 0010:[a0191c9f] [a0191c9f]
insert_inline_extent_backref+0xef/0x100 [btrfs]
[ 6095.255965] RSP: 0018:880028723788 EFLAGS: 00010293
[ 6095.255970] RAX: RBX: 8801275b3510 RCX:
8800287237d0
[ 6095.255974] RDX: 8801275b3510 RSI: 0001 RDI:
[ 6095.255978] RBP: 880028723808 R08: 0bf2 R09:
880028723698
[ 6095.255981] R10: R11: R12:
880126918800
[ 6095.255985] R13: 88012afdd280 R14: R15:
0001
1753 static noinline_for_stack
1754 int insert_inline_extent_backref(struct btrfs_trans_handle *trans,
1755 struct btrfs_root *root,
1756 struct btrfs_path *path,
1757 u64 bytenr, u64 num_bytes, u64 parent,
1758 u64 root_objectid, u64 owner,
1759 u64 offset, int refs_to_add,
1760 struct btrfs_delayed_extent_op
*extent_op)
1761 {
1762 struct btrfs_extent_inline_ref *iref;
1763 int ret;
1764
1765 ret = lookup_inline_extent_backref(trans, root, path, iref,
1766bytenr, num_bytes, parent,
1767root_objectid, owner, offset,
1);
1768 if (ret == 0) {
1769 BUG_ON(owner BTRFS_FIRST_FREE_OBJECTID);
15c17:49 81 ff ff 00 00 00 cmp $0xff,%r15
15c1e:76 7fjbe 0x15c9f
according to assembly, owner is in R15, BTRFS_FIRST_FREE_OBJECTID is
256, so owner == 1
This is fixed already in btrfs-next. Thanks,
Josef
--
To unsubscribe from this list: send the line unsubscribe linux-btrfs in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG on 3.5.0
On Wed, Aug 08, 2012 at 01:40:11PM -0400, Josef Bacik wrote: On Wed, Aug 08, 2012 at 11:36:45AM -0600, David Sterba wrote: according to assembly, owner is in R15, BTRFS_FIRST_FREE_OBJECTID is 256, so owner == 1 This is fixed already in btrfs-next. Thanks, Ok, thank you. Does it mean it will get into the next stable? Or it's for 3.6? Is it only 'balance' that triggers it? Regards, Lluís. -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG on 3.5.0
On Wed, Aug 08, 2012 at 11:56:06AM -0600, Lluís Batlle i Rossell wrote: On Wed, Aug 08, 2012 at 01:40:11PM -0400, Josef Bacik wrote: On Wed, Aug 08, 2012 at 11:36:45AM -0600, David Sterba wrote: according to assembly, owner is in R15, BTRFS_FIRST_FREE_OBJECTID is 256, so owner == 1 This is fixed already in btrfs-next. Thanks, Ok, thank you. Does it mean it will get into the next stable? Or it's for 3.6? Is it only 'balance' that triggers it? I'm bringing the fix in for my next pull request, so it will be available against both 3.5 and 3.6 -chris -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
