All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 00/42] Cleanup error handling in relocation
@ 2020-11-12 21:18 Josef Bacik
  2020-11-12 21:18 ` [PATCH 01/42] btrfs: allow error injection for btrfs_search_slot and btrfs_cow_block Josef Bacik
                   ` (42 more replies)
  0 siblings, 43 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:18 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

Hello,

Relocation is the last place that is not able to handle errors at all, which
results in all sorts of lovely panics if you encounter corruptions or IO errors.
I'm going to start cleaning up relocation, but before I move code around I want
the error handling to be somewhat sane, so I'm not changing behavior and error
handling at the same time.

These patches are purely about error handling, there is no behavior changing
other than returning errors up the chain properly.  There is a lot of room for
follow up cleanups, which will happen next.  However I wanted to get this series
done today and out so we could get it merged ASAP, and then the follow up
cleanups can happen later as they are less important and less critical.

The only exception to the above is the patch to add the error injection sites
for btrfs_cow_block and btrfs_search_slot, and a lockdep fix that I discovered
while running my tests, those are the first two patches in the series.

I tested this with my error injection stress test, where I keep track of all
stack traces that have been tested and only inject errors when we have a new
stack trace, which means I should have covered all of the various error
conditions.  With this patchset I'm no longer panicing while stressing the error
conditions.  Thanks,

Josef

Josef Bacik (42):
  btrfs: allow error injection for btrfs_search_slot and btrfs_cow_block
  btrfs: fix lockdep splat in btrfs_recover_relocation
  btrfs: convert some BUG_ON()'s to ASSERT()'s in do_relocation
  btrfs: convert BUG_ON()'s in relocate_tree_block
  btrfs: return an error from btrfs_record_root_in_trans
  btrfs: handle errors from select_reloc_root()
  btrfs: convert BUG_ON()'s in select_reloc_root() to proper errors
  btrfs: check record_root_in_trans related failures in
    select_reloc_root
  btrfs: do proper error handling in record_reloc_root_in_trans
  btrfs: handle btrfs_record_root_in_trans failure in
    btrfs_rename_exchange
  btrfs: handle btrfs_record_root_in_trans failure in btrfs_rename
  btrfs: handle btrfs_record_root_in_trans failure in
    btrfs_delete_subvolume
  btrfs: handle btrfs_record_root_in_trans failure in
    btrfs_recover_log_trees
  btrfs: handle btrfs_record_root_in_trans failure in create_subvol
  btrfs: btrfs: handle btrfs_record_root_in_trans failure in
    relocate_tree_block
  btrfs: handle btrfs_record_root_in_trans failure in start_transaction
  btrfs: handle record_root_in_trans failure in qgroup_account_snapshot
  btrfs: handle record_root_in_trans failure in
    btrfs_record_root_in_trans
  btrfs: handle record_root_in_trans failure in create_pending_snapshot
  btrfs: do not panic in __add_reloc_root
  btrfs: have proper error handling in btrfs_init_reloc_root
  btrfs: do proper error handling in create_reloc_root
  btrfs: handle btrfs_update_reloc_root failure in commit_fs_roots
  btrfs: change insert_dirty_subvol to return errors
  btrfs: handle btrfs_update_reloc_root failure in insert_dirty_subvol
  btrfs: handle btrfs_update_reloc_root failure in prepare_to_merge
  btrfs: do proper error handling in btrfs_update_reloc_root
  btrfs: convert logic BUG_ON()'s in replace_path to ASSERT()'s
  btrfs: handle initial btrfs_cow_block error in replace_path
  btrfs: handle the loop btrfs_cow_block error in replace_path
  btrfs: handle btrfs_search_slot failure in replace_path
  btrfs: handle errors in reference count manipulation in replace_path
  btrfs: handle extent reference errors in do_relocation
  btrfs: check for BTRFS_BLOCK_FLAG_FULL_BACKREF being set improperly
  btrfs: remove the extent item sanity checks in relocate_block_group
  btrfs: do proper error handling in create_reloc_inode
  btrfs: handle __add_reloc_root failure in btrfs_recover_relocation
  btrfs: handle __add_reloc_root failure in btrfs_reloc_post_snapshot
  btrfs: cleanup error handling in prepare_to_merge
  btrfs: handle extent corruption with select_one_root properly
  btrfs: do proper error handling in merge_reloc_roots
  btrfs: check return value of btrfs_commit_transaction in relocation

 fs/btrfs/ctree.c        |   2 +
 fs/btrfs/inode.c        |  21 ++-
 fs/btrfs/ioctl.c        |   6 +-
 fs/btrfs/relocation.c   | 372 ++++++++++++++++++++++++++++++----------
 fs/btrfs/transaction.c  |  37 ++--
 fs/btrfs/tree-checker.c |   5 +
 fs/btrfs/tree-log.c     |   8 +-
 fs/btrfs/volumes.c      |   2 +
 8 files changed, 342 insertions(+), 111 deletions(-)

-- 
2.26.2


^ permalink raw reply	[flat|nested] 49+ messages in thread

* [PATCH 01/42] btrfs: allow error injection for btrfs_search_slot and btrfs_cow_block
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
@ 2020-11-12 21:18 ` Josef Bacik
  2020-11-13  0:02   ` Qu Wenruo
  2020-11-12 21:18 ` [PATCH 02/42] btrfs: fix lockdep splat in btrfs_recover_relocation Josef Bacik
                   ` (41 subsequent siblings)
  42 siblings, 1 reply; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:18 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

The following patches are going to address error handling in relocation,
in order to test those patches I need to be able to inject errors in
btrfs_search_slot and btrfs_cow_block, as we call both of these pretty
often in different cases during relocation.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/ctree.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
index d2d5854d51a7..a51e761bf00f 100644
--- a/fs/btrfs/ctree.c
+++ b/fs/btrfs/ctree.c
@@ -1493,6 +1493,7 @@ noinline int btrfs_cow_block(struct btrfs_trans_handle *trans,
 
 	return ret;
 }
+ALLOW_ERROR_INJECTION(btrfs_cow_block, ERRNO);
 
 /*
  * helper function for defrag to decide if two blocks pointed to by a
@@ -2870,6 +2871,7 @@ int btrfs_search_slot(struct btrfs_trans_handle *trans, struct btrfs_root *root,
 		btrfs_release_path(p);
 	return ret;
 }
+ALLOW_ERROR_INJECTION(btrfs_search_slot, ERRNO);
 
 /*
  * Like btrfs_search_slot, this looks for a key in the given tree. It uses the
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 02/42] btrfs: fix lockdep splat in btrfs_recover_relocation
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
  2020-11-12 21:18 ` [PATCH 01/42] btrfs: allow error injection for btrfs_search_slot and btrfs_cow_block Josef Bacik
@ 2020-11-12 21:18 ` Josef Bacik
  2020-11-12 21:18 ` [PATCH 03/42] btrfs: convert some BUG_ON()'s to ASSERT()'s in do_relocation Josef Bacik
                   ` (40 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:18 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

While testing the error paths of relocation I hit the following lockdep
splat

======================================================
WARNING: possible circular locking dependency detected
5.10.0-rc2-btrfs-next-71 #1 Not tainted
------------------------------------------------------
find/324157 is trying to acquire lock:
ffff8ebc48d293a0 (btrfs-tree-01#2/3){++++}-{3:3}, at: __btrfs_tree_read_lock+0x32/0x1a0 [btrfs]

but task is already holding lock:
ffff8eb9932c5088 (btrfs-tree-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x32/0x1a0 [btrfs]

which lock already depends on the new lock.

the existing dependency chain (in reverse order) is:

-> #1 (btrfs-tree-00){++++}-{3:3}:
       lock_acquire+0xd8/0x490
       down_write_nested+0x44/0x120
       __btrfs_tree_lock+0x27/0x120 [btrfs]
       btrfs_search_slot+0x2a3/0xc50 [btrfs]
       btrfs_insert_empty_items+0x58/0xa0 [btrfs]
       insert_with_overflow+0x44/0x110 [btrfs]
       btrfs_insert_xattr_item+0xb8/0x1d0 [btrfs]
       btrfs_setxattr+0xd6/0x4c0 [btrfs]
       btrfs_setxattr_trans+0x68/0x100 [btrfs]
       __vfs_setxattr+0x66/0x80
       __vfs_setxattr_noperm+0x70/0x200
       vfs_setxattr+0x6b/0x120
       setxattr+0x125/0x240
       path_setxattr+0xba/0xd0
       __x64_sys_setxattr+0x27/0x30
       do_syscall_64+0x33/0x80
       entry_SYSCALL_64_after_hwframe+0x44/0xa9

-> #0 (btrfs-tree-01#2/3){++++}-{3:3}:
       check_prev_add+0x91/0xc60
       __lock_acquire+0x1689/0x3130
       lock_acquire+0xd8/0x490
       down_read_nested+0x45/0x220
       __btrfs_tree_read_lock+0x32/0x1a0 [btrfs]
       btrfs_next_old_leaf+0x27d/0x580 [btrfs]
       btrfs_real_readdir+0x1e3/0x4b0 [btrfs]
       iterate_dir+0x170/0x1c0
       __x64_sys_getdents64+0x83/0x140
       do_syscall_64+0x33/0x80
       entry_SYSCALL_64_after_hwframe+0x44/0xa9

other info that might help us debug this:

 Possible unsafe locking scenario:

       CPU0                    CPU1
       ----                    ----
  lock(btrfs-tree-00);
                               lock(btrfs-tree-01#2/3);
                               lock(btrfs-tree-00);
  lock(btrfs-tree-01#2/3);

 *** DEADLOCK ***

5 locks held by find/324157:
 #0: ffff8ebc502c6e00 (&f->f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0x4d/0x60
 #1: ffff8eb97f689980 (&type->i_mutex_dir_key#10){++++}-{3:3}, at: iterate_dir+0x52/0x1c0
 #2: ffff8ebaec00ca58 (btrfs-tree-02#2){++++}-{3:3}, at: __btrfs_tree_read_lock+0x32/0x1a0 [btrfs]
 #3: ffff8eb98f986f78 (btrfs-tree-01#2){++++}-{3:3}, at: __btrfs_tree_read_lock+0x32/0x1a0 [btrfs]
 #4: ffff8eb9932c5088 (btrfs-tree-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x32/0x1a0 [btrfs]

stack backtrace:
CPU: 2 PID: 324157 Comm: find Not tainted 5.10.0-rc2-btrfs-next-71 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
Call Trace:
 dump_stack+0x8d/0xb5
 check_noncircular+0xff/0x110
 ? mark_lock.part.0+0x468/0xe90
 check_prev_add+0x91/0xc60
 __lock_acquire+0x1689/0x3130
 ? kvm_clock_read+0x14/0x30
 ? kvm_sched_clock_read+0x5/0x10
 lock_acquire+0xd8/0x490
 ? __btrfs_tree_read_lock+0x32/0x1a0 [btrfs]
 down_read_nested+0x45/0x220
 ? __btrfs_tree_read_lock+0x32/0x1a0 [btrfs]
 __btrfs_tree_read_lock+0x32/0x1a0 [btrfs]
 btrfs_next_old_leaf+0x27d/0x580 [btrfs]
 btrfs_real_readdir+0x1e3/0x4b0 [btrfs]
 iterate_dir+0x170/0x1c0
 __x64_sys_getdents64+0x83/0x140
 ? filldir+0x1d0/0x1d0
 do_syscall_64+0x33/0x80
 entry_SYSCALL_64_after_hwframe+0x44/0xa9

This is thankfully straightforward to fix, simply release the path
before we setup the reloc_ctl.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/volumes.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
index c927dc597550..a364d37d972e 100644
--- a/fs/btrfs/volumes.c
+++ b/fs/btrfs/volumes.c
@@ -4283,6 +4283,8 @@ int btrfs_recover_balance(struct btrfs_fs_info *fs_info)
 		btrfs_warn(fs_info,
 	"balance: cannot set exclusive op status, resume manually");
 
+	btrfs_release_path(path);
+
 	mutex_lock(&fs_info->balance_mutex);
 	BUG_ON(fs_info->balance_ctl);
 	spin_lock(&fs_info->balance_lock);
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 03/42] btrfs: convert some BUG_ON()'s to ASSERT()'s in do_relocation
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
  2020-11-12 21:18 ` [PATCH 01/42] btrfs: allow error injection for btrfs_search_slot and btrfs_cow_block Josef Bacik
  2020-11-12 21:18 ` [PATCH 02/42] btrfs: fix lockdep splat in btrfs_recover_relocation Josef Bacik
@ 2020-11-12 21:18 ` Josef Bacik
  2020-11-12 21:18 ` [PATCH 04/42] btrfs: convert BUG_ON()'s in relocate_tree_block Josef Bacik
                   ` (39 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:18 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

A few of these are checking for correctness, and won't be triggered by
corrupted file systems, so convert them to ASSERT() instead of BUG_ON()
and add a comment explaining their existence.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/relocation.c | 19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 0b3ccf464c3d..6c9bba61bfde 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -2215,7 +2215,11 @@ static int do_relocation(struct btrfs_trans_handle *trans,
 	int ret;
 	int err = 0;
 
-	BUG_ON(lowest && node->eb);
+	/*
+	 * If we are lowest then this is the first time we're processing this
+	 * block, and thus shouldn't have an eb associated with it yet.
+	 */
+	ASSERT(!lowest || !node->eb);
 
 	path->lowest_level = node->level + 1;
 	rc->backref_cache.path[node->level] = node;
@@ -2316,7 +2320,11 @@ static int do_relocation(struct btrfs_trans_handle *trans,
 				err = ret;
 				goto next;
 			}
-			BUG_ON(node->eb != eb);
+			/*
+			 * We've just cow'ed this block, it should have updated
+			 * the correct backref node entry.
+			 */
+			ASSERT(node->eb == eb);
 		} else {
 			btrfs_set_node_blockptr(upper->eb, slot,
 						node->eb->start);
@@ -2352,7 +2360,12 @@ static int do_relocation(struct btrfs_trans_handle *trans,
 	}
 
 	path->lowest_level = 0;
-	BUG_ON(err == -ENOSPC);
+
+	/*
+	 * We should have allocated all of our space in the block rsv and thus
+	 * shouldn't ENOSPC.
+	 */
+	ASSERT(err != -ENOSPC);
 	return err;
 }
 
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 04/42] btrfs: convert BUG_ON()'s in relocate_tree_block
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (2 preceding siblings ...)
  2020-11-12 21:18 ` [PATCH 03/42] btrfs: convert some BUG_ON()'s to ASSERT()'s in do_relocation Josef Bacik
@ 2020-11-12 21:18 ` Josef Bacik
  2020-11-12 21:18 ` [PATCH 05/42] btrfs: return an error from btrfs_record_root_in_trans Josef Bacik
                   ` (38 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:18 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

We have a couple of BUG_ON()'s in relocate_tree_block() that can be
tripped if we have file system corruption.  Convert these to ASSERT()'s
so developers still get yelled at when they break the backref code, but
error out nicely for users so the whole box doesn't go down.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/relocation.c | 24 ++++++++++++++++++++++--
 1 file changed, 22 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 6c9bba61bfde..bc598eb014fd 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -2504,8 +2504,28 @@ static int relocate_tree_block(struct btrfs_trans_handle *trans,
 
 	if (root) {
 		if (test_bit(BTRFS_ROOT_SHAREABLE, &root->state)) {
-			BUG_ON(node->new_bytenr);
-			BUG_ON(!list_empty(&node->list));
+			/*
+			 * This block was the root block of a root, and this is
+			 * the first time we're processing the block and thus it
+			 * should not have had the ->new_bytenr modified and
+			 * should have not been included on the changed list.
+			 *
+			 * However in the case of corruption we could have
+			 * multiple refs pointing to the same block improperly,
+			 * and thus we would trip over these checks.  ASSERT()
+			 * for the developer case, because it could indicate a
+			 * bug in the backref code, however error out for a
+			 * normal user in the case of corruption.
+			 */
+			ASSERT(node->new_bytenr == 0);
+			ASSERT(list_empty(&node->list));
+			if (node->new_bytenr || !list_empty(&node->list)) {
+				btrfs_err(root->fs_info,
+				  "bytenr %llu has improper references to it",
+					  node->bytenr);
+				ret = -EUCLEAN;
+				goto out;
+			}
 			btrfs_record_root_in_trans(trans, root);
 			root = root->reloc_root;
 			node->new_bytenr = root->node->start;
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 05/42] btrfs: return an error from btrfs_record_root_in_trans
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (3 preceding siblings ...)
  2020-11-12 21:18 ` [PATCH 04/42] btrfs: convert BUG_ON()'s in relocate_tree_block Josef Bacik
@ 2020-11-12 21:18 ` Josef Bacik
  2020-11-12 21:18 ` [PATCH 06/42] btrfs: handle errors from select_reloc_root() Josef Bacik
                   ` (37 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:18 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

We can create a reloc root when we record the root in the trans, which
can fail for all sorts of different reasons.  Propagate this error up
the chain of callers.  Future patches will fix the callers of
btrfs_record_root_in_trans() to handle the error.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/transaction.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
index b671ea4d80e1..9cb379facf7a 100644
--- a/fs/btrfs/transaction.c
+++ b/fs/btrfs/transaction.c
@@ -403,6 +403,7 @@ static int record_root_in_trans(struct btrfs_trans_handle *trans,
 			       int force)
 {
 	struct btrfs_fs_info *fs_info = root->fs_info;
+	int ret = 0;
 
 	if ((test_bit(BTRFS_ROOT_SHAREABLE, &root->state) &&
 	    root->last_trans < trans->transid) || force) {
@@ -451,11 +452,11 @@ static int record_root_in_trans(struct btrfs_trans_handle *trans,
 		 * lock.  smp_wmb() makes sure that all the writes above are
 		 * done before we pop in the zero below
 		 */
-		btrfs_init_reloc_root(trans, root);
+		ret = btrfs_init_reloc_root(trans, root);
 		smp_mb__before_atomic();
 		clear_bit(BTRFS_ROOT_IN_TRANS_SETUP, &root->state);
 	}
-	return 0;
+	return ret;
 }
 
 
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 06/42] btrfs: handle errors from select_reloc_root()
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (4 preceding siblings ...)
  2020-11-12 21:18 ` [PATCH 05/42] btrfs: return an error from btrfs_record_root_in_trans Josef Bacik
@ 2020-11-12 21:18 ` Josef Bacik
  2020-11-12 21:18 ` [PATCH 07/42] btrfs: convert BUG_ON()'s in select_reloc_root() to proper errors Josef Bacik
                   ` (36 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:18 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

Currently select_reloc_root() doesn't return an error, but followup
patches will make it possible for it to return an error.  We do have
proper error recovery in do_relocation however, so handle the
possibility of select_reloc_root() having an error properly instead of
BUG_ON(!root).  I've also adjusted select_reloc_root() to return
ERR_PTR(-ENOENT) if we don't find a root, instead of NULL, to make the
error case easier to deal with.  I've replaced the BUG_ON(!root) with an
ASSERT(ret != -ENOENT), as this indicates we messed up the backref
walking code, but could indicate corruption so we do not want to have a
BUG_ON() here.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/relocation.c | 15 +++++++++++++--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index bc598eb014fd..a94671199e8d 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -2056,7 +2056,7 @@ struct btrfs_root *select_reloc_root(struct btrfs_trans_handle *trans,
 			break;
 	}
 	if (!root)
-		return NULL;
+		return ERR_PTR(-ENOENT);
 
 	next = node;
 	/* setup backref node path for btrfs_reloc_cow_block */
@@ -2231,7 +2231,18 @@ static int do_relocation(struct btrfs_trans_handle *trans,
 
 		upper = edge->node[UPPER];
 		root = select_reloc_root(trans, rc, upper, edges);
-		BUG_ON(!root);
+		if (IS_ERR(root)) {
+			err = PTR_ERR(root);
+
+			/*
+			 * This can happen if there's fs corruption, but if we
+			 * have ASSERT()'s on then we're developers and we
+			 * likely made a logic mistake in the backref code, so
+			 * check for this error condition.
+			 */
+			ASSERT(err != -ENOENT);
+			goto next;
+		}
 
 		if (upper->eb && !upper->locked) {
 			if (!lowest) {
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 07/42] btrfs: convert BUG_ON()'s in select_reloc_root() to proper errors
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (5 preceding siblings ...)
  2020-11-12 21:18 ` [PATCH 06/42] btrfs: handle errors from select_reloc_root() Josef Bacik
@ 2020-11-12 21:18 ` Josef Bacik
  2020-11-12 21:18 ` [PATCH 08/42] btrfs: check record_root_in_trans related failures in select_reloc_root Josef Bacik
                   ` (35 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:18 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

We have several BUG_ON()'s in select_reloc_root() that can be tripped if
you have extent tree corruption.  Convert these to ASSERT()'s, because
if we hit it during testing it really is bad, or could indicate a
problem with the backref walking code.

However if users hit these problems it generally indicates corruption,
I've hit a few machines in the fleet that trip over these with clearly
corrupted extent trees, so be nice and spit out an error message and
return an error instead of bringing the whole box down.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/relocation.c | 51 +++++++++++++++++++++++++++++++++++++++----
 1 file changed, 47 insertions(+), 4 deletions(-)

diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index a94671199e8d..f5c562955690 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -2025,8 +2025,35 @@ struct btrfs_root *select_reloc_root(struct btrfs_trans_handle *trans,
 		cond_resched();
 		next = walk_up_backref(next, edges, &index);
 		root = next->root;
-		BUG_ON(!root);
-		BUG_ON(!test_bit(BTRFS_ROOT_SHAREABLE, &root->state));
+
+		/*
+		 * If there is no root, then our references for this block are
+		 * incomplete, as we should be able to walk all the way up to a
+		 * block that is owned by a root.
+		 *
+		 * This path is only for SHAREABLE roots, so if we come upon a
+		 * non-SHAREABLE root then we have backrefs that resolve
+		 * improperly.
+		 *
+		 * Both of these cases indicate file system corruption, or a bug
+		 * in the backref walking code.  The ASSERT() is to make sure
+		 * developers get bitten as soon as possible, proper error
+		 * handling is for users who may have corrupt file systems.
+		 */
+		ASSERT(root);
+		ASSERT(test_bit(BTRFS_ROOT_SHAREABLE, &root->state));
+		if (!root) {
+			btrfs_err(trans->fs_info,
+		"bytenr %llu doesn't have a backref path ending in a root",
+				  node->bytenr);
+			return ERR_PTR(-EUCLEAN);
+		}
+		if (!test_bit(BTRFS_ROOT_SHAREABLE, &root->state)) {
+			btrfs_err(trans->fs_info,
+"bytenr %llu has multiple refs with one ending in a non shareable root",
+				  node->bytenr);
+			return ERR_PTR(-EUCLEAN);
+		}
 
 		if (root->root_key.objectid == BTRFS_TREE_RELOC_OBJECTID) {
 			record_reloc_root_in_trans(trans, root);
@@ -2037,8 +2064,24 @@ struct btrfs_root *select_reloc_root(struct btrfs_trans_handle *trans,
 		root = root->reloc_root;
 
 		if (next->new_bytenr != root->node->start) {
-			BUG_ON(next->new_bytenr);
-			BUG_ON(!list_empty(&next->list));
+			/*
+			 * We just created the reloc root, so we shouldn't have
+			 * ->new_bytenr set and this shouldn't be in the changed
+			 *  list.  If it is then we have multiple roots pointing
+			 *  at the same bytenr, or we've made a mistake in the
+			 *  backref walking code.  ASSERT() for developers,
+			 *  error out for users, as it indicates corruption or a
+			 *  bad bug.
+			 */
+			ASSERT(next->new_bytenr == 0);
+			ASSERT(list_empty(&next->list));
+			if (next->new_bytenr || !list_empty(&next->list)) {
+				btrfs_err(trans->fs_info,
+"bytenr %llu possibly has multiple roots pointing at the same bytenr %llu",
+					  node->bytenr, next->bytenr);
+				return ERR_PTR(-EUCLEAN);
+			}
+
 			next->new_bytenr = root->node->start;
 			btrfs_put_root(next->root);
 			next->root = btrfs_grab_root(root);
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 08/42] btrfs: check record_root_in_trans related failures in select_reloc_root
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (6 preceding siblings ...)
  2020-11-12 21:18 ` [PATCH 07/42] btrfs: convert BUG_ON()'s in select_reloc_root() to proper errors Josef Bacik
@ 2020-11-12 21:18 ` Josef Bacik
  2020-11-12 21:18 ` [PATCH 09/42] btrfs: do proper error handling in record_reloc_root_in_trans Josef Bacik
                   ` (34 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:18 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

We will record the fs root or the reloc root in the trans in
select_reloc_root.  These will actually return errors in the following
patches, so check their return value here and return it up the stack.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/relocation.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index f5c562955690..5deaf56ceb8d 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -2019,6 +2019,7 @@ struct btrfs_root *select_reloc_root(struct btrfs_trans_handle *trans,
 	struct btrfs_backref_node *next;
 	struct btrfs_root *root;
 	int index = 0;
+	int ret;
 
 	next = node;
 	while (1) {
@@ -2056,11 +2057,15 @@ struct btrfs_root *select_reloc_root(struct btrfs_trans_handle *trans,
 		}
 
 		if (root->root_key.objectid == BTRFS_TREE_RELOC_OBJECTID) {
-			record_reloc_root_in_trans(trans, root);
+			ret = record_reloc_root_in_trans(trans, root);
+			if (ret)
+				return ERR_PTR(ret);
 			break;
 		}
 
-		btrfs_record_root_in_trans(trans, root);
+		ret = btrfs_record_root_in_trans(trans, root);
+		if (ret)
+			return ERR_PTR(ret);
 		root = root->reloc_root;
 
 		if (next->new_bytenr != root->node->start) {
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 09/42] btrfs: do proper error handling in record_reloc_root_in_trans
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (7 preceding siblings ...)
  2020-11-12 21:18 ` [PATCH 08/42] btrfs: check record_root_in_trans related failures in select_reloc_root Josef Bacik
@ 2020-11-12 21:18 ` Josef Bacik
  2020-11-12 21:18 ` [PATCH 10/42] btrfs: handle btrfs_record_root_in_trans failure in btrfs_rename_exchange Josef Bacik
                   ` (33 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:18 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

Generally speaking this shouldn't ever fail, the corresponding fs root
for the reloc root will already be in memory, so we won't get -ENOMEM
here.

However if there is no corresponding root for the reloc root then we
could get -ENOMEM when we try to allocate it or we could get -ENOENT
when we look it up and see that it doesn't exist.

Convert these BUG_ON()'s into ASSERT()'s + proper error handling for the
case of corruption.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/relocation.c | 26 ++++++++++++++++++++++++--
 1 file changed, 24 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 5deaf56ceb8d..4d445cbc8d69 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -2002,8 +2002,30 @@ static int record_reloc_root_in_trans(struct btrfs_trans_handle *trans,
 		return 0;
 
 	root = btrfs_get_fs_root(fs_info, reloc_root->root_key.offset, false);
-	BUG_ON(IS_ERR(root));
-	BUG_ON(root->reloc_root != reloc_root);
+
+	/*
+	 * This should succeed, since we can't have a reloc root without having
+	 * already looked up the actual root and created the reloc root for this
+	 * root.
+	 *
+	 * However if there's some sort of corruption where we have a ref to a
+	 * reloc root without a corresponding root this could return -ENOENT.
+	 *
+	 * The ASSERT()'s are to catch this case in testing, because it could
+	 * indicate a bug, but for non-developers it indicates corruption and we
+	 * should error out.
+	 */
+	ASSERT(!IS_ERR(root));
+	ASSERT(root->reloc_root == reloc_root);
+	if (IS_ERR(root))
+		return PTR_ERR(root);
+	if (root->reloc_root != reloc_root) {
+		btrfs_err(fs_info,
+			  "root %llu has two reloc roots associated with it",
+			  reloc_root->root_key.offset);
+		btrfs_put_root(root);
+		return -EUCLEAN;
+	}
 	ret = btrfs_record_root_in_trans(trans, root);
 	btrfs_put_root(root);
 
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 10/42] btrfs: handle btrfs_record_root_in_trans failure in btrfs_rename_exchange
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (8 preceding siblings ...)
  2020-11-12 21:18 ` [PATCH 09/42] btrfs: do proper error handling in record_reloc_root_in_trans Josef Bacik
@ 2020-11-12 21:18 ` Josef Bacik
  2020-11-12 21:18 ` [PATCH 11/42] btrfs: handle btrfs_record_root_in_trans failure in btrfs_rename Josef Bacik
                   ` (32 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:18 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

btrfs_record_root_in_trans will return errors in the future, so handle
the error properly in btrfs_rename_exchange.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/inode.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 272ee4c8295e..4eea3b4d9b56 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -8758,8 +8758,11 @@ static int btrfs_rename_exchange(struct inode *old_dir,
 		goto out_notrans;
 	}
 
-	if (dest != root)
-		btrfs_record_root_in_trans(trans, dest);
+	if (dest != root) {
+		ret = btrfs_record_root_in_trans(trans, dest);
+		if (ret)
+			goto out_fail;
+	}
 
 	/*
 	 * We need to find a free sequence number both in the source and
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 11/42] btrfs: handle btrfs_record_root_in_trans failure in btrfs_rename
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (9 preceding siblings ...)
  2020-11-12 21:18 ` [PATCH 10/42] btrfs: handle btrfs_record_root_in_trans failure in btrfs_rename_exchange Josef Bacik
@ 2020-11-12 21:18 ` Josef Bacik
  2020-11-12 21:18 ` [PATCH 12/42] btrfs: handle btrfs_record_root_in_trans failure in btrfs_delete_subvolume Josef Bacik
                   ` (31 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:18 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

btrfs_record_root_in_trans will return errors in the future, so handle
the error properly in btrfs_rename.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/inode.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 4eea3b4d9b56..ab7743c8bbd4 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -9066,8 +9066,11 @@ static int btrfs_rename(struct inode *old_dir, struct dentry *old_dentry,
 		goto out_notrans;
 	}
 
-	if (dest != root)
-		btrfs_record_root_in_trans(trans, dest);
+	if (dest != root) {
+		ret = btrfs_record_root_in_trans(trans, dest);
+		if (ret)
+			goto out_fail;
+	}
 
 	ret = btrfs_set_inode_index(BTRFS_I(new_dir), &index);
 	if (ret)
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 12/42] btrfs: handle btrfs_record_root_in_trans failure in btrfs_delete_subvolume
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (10 preceding siblings ...)
  2020-11-12 21:18 ` [PATCH 11/42] btrfs: handle btrfs_record_root_in_trans failure in btrfs_rename Josef Bacik
@ 2020-11-12 21:18 ` Josef Bacik
  2020-11-12 21:18 ` [PATCH 13/42] btrfs: handle btrfs_record_root_in_trans failure in btrfs_recover_log_trees Josef Bacik
                   ` (30 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:18 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

btrfs_record_root_in_trans will return errors in the future, so handle
the error properly in btrfs_delete_subvolume.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/inode.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index ab7743c8bbd4..0d9be9419a80 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -4049,7 +4049,12 @@ int btrfs_delete_subvolume(struct inode *dir, struct dentry *dentry)
 		goto out_end_trans;
 	}
 
-	btrfs_record_root_in_trans(trans, dest);
+	ret = btrfs_record_root_in_trans(trans, dest);
+	if (ret) {
+		err = ret;
+		btrfs_abort_transaction(trans, ret);
+		goto out_end_trans;
+	}
 
 	memset(&dest->root_item.drop_progress, 0,
 		sizeof(dest->root_item.drop_progress));
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 13/42] btrfs: handle btrfs_record_root_in_trans failure in btrfs_recover_log_trees
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (11 preceding siblings ...)
  2020-11-12 21:18 ` [PATCH 12/42] btrfs: handle btrfs_record_root_in_trans failure in btrfs_delete_subvolume Josef Bacik
@ 2020-11-12 21:18 ` Josef Bacik
  2020-11-12 21:18 ` [PATCH 14/42] btrfs: handle btrfs_record_root_in_trans failure in create_subvol Josef Bacik
                   ` (29 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:18 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

btrfs_record_root_in_trans will return errors in the future, so handle
the error properly in btrfs_recover_log_trees.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/tree-log.c | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index eb86c632535a..70f7413726d9 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -6261,8 +6261,12 @@ int btrfs_recover_log_trees(struct btrfs_root *log_root_tree)
 		}
 
 		wc.replay_dest->log_root = log;
-		btrfs_record_root_in_trans(trans, wc.replay_dest);
-		ret = walk_log_tree(trans, log, &wc);
+		ret = btrfs_record_root_in_trans(trans, wc.replay_dest);
+		if (ret)
+			btrfs_handle_fs_error(fs_info, ret,
+				"Couldn't record the root in the transaction.");
+		else
+			ret = walk_log_tree(trans, log, &wc);
 
 		if (!ret && wc.stage == LOG_WALK_REPLAY_ALL) {
 			ret = fixup_inode_link_counts(trans, wc.replay_dest,
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 14/42] btrfs: handle btrfs_record_root_in_trans failure in create_subvol
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (12 preceding siblings ...)
  2020-11-12 21:18 ` [PATCH 13/42] btrfs: handle btrfs_record_root_in_trans failure in btrfs_recover_log_trees Josef Bacik
@ 2020-11-12 21:18 ` Josef Bacik
  2020-11-12 21:18 ` [PATCH 15/42] btrfs: btrfs: handle btrfs_record_root_in_trans failure in relocate_tree_block Josef Bacik
                   ` (28 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:18 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

btrfs_record_root_in_trans will return errors in the future, so handle
the error properly in create_subvol.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/ioctl.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/ioctl.c b/fs/btrfs/ioctl.c
index ea40a19cc4cb..ca25183c9c84 100644
--- a/fs/btrfs/ioctl.c
+++ b/fs/btrfs/ioctl.c
@@ -702,7 +702,11 @@ static noinline int create_subvol(struct inode *dir,
 	/* Freeing will be done in btrfs_put_root() of new_root */
 	anon_dev = 0;
 
-	btrfs_record_root_in_trans(trans, new_root);
+	ret = btrfs_record_root_in_trans(trans, new_root);
+	if (ret) {
+		btrfs_abort_transaction(trans, ret);
+		goto fail;
+	}
 
 	ret = btrfs_create_subvol_root(trans, new_root, root, new_dirid);
 	btrfs_put_root(new_root);
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 15/42] btrfs: btrfs: handle btrfs_record_root_in_trans failure in relocate_tree_block
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (13 preceding siblings ...)
  2020-11-12 21:18 ` [PATCH 14/42] btrfs: handle btrfs_record_root_in_trans failure in create_subvol Josef Bacik
@ 2020-11-12 21:18 ` Josef Bacik
  2020-11-12 21:18 ` [PATCH 16/42] btrfs: handle btrfs_record_root_in_trans failure in start_transaction Josef Bacik
                   ` (27 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:18 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

btrfs_record_root_in_trans will return errors in the future, so handle
the error properly in relocate_tree_block.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/relocation.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 4d445cbc8d69..4d6f898025e5 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -2607,7 +2607,9 @@ static int relocate_tree_block(struct btrfs_trans_handle *trans,
 				ret = -EUCLEAN;
 				goto out;
 			}
-			btrfs_record_root_in_trans(trans, root);
+			ret = btrfs_record_root_in_trans(trans, root);
+			if (ret)
+				goto out;
 			root = root->reloc_root;
 			node->new_bytenr = root->node->start;
 			btrfs_put_root(node->root);
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 16/42] btrfs: handle btrfs_record_root_in_trans failure in start_transaction
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (14 preceding siblings ...)
  2020-11-12 21:18 ` [PATCH 15/42] btrfs: btrfs: handle btrfs_record_root_in_trans failure in relocate_tree_block Josef Bacik
@ 2020-11-12 21:18 ` Josef Bacik
  2020-11-12 21:18 ` [PATCH 17/42] btrfs: handle record_root_in_trans failure in qgroup_account_snapshot Josef Bacik
                   ` (26 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:18 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

btrfs_record_root_in_trans will return errors in the future, so handle
the error properly in start_transaction.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/transaction.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
index 9cb379facf7a..c666e6bef0ff 100644
--- a/fs/btrfs/transaction.c
+++ b/fs/btrfs/transaction.c
@@ -737,7 +737,11 @@ start_transaction(struct btrfs_root *root, unsigned int num_items,
 	 * Thus it need to be called after current->journal_info initialized,
 	 * or we can deadlock.
 	 */
-	btrfs_record_root_in_trans(h, root);
+	ret = btrfs_record_root_in_trans(h, root);
+	if (ret) {
+		btrfs_end_transaction(h);
+		return ERR_PTR(ret);
+	}
 
 	return h;
 
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 17/42] btrfs: handle record_root_in_trans failure in qgroup_account_snapshot
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (15 preceding siblings ...)
  2020-11-12 21:18 ` [PATCH 16/42] btrfs: handle btrfs_record_root_in_trans failure in start_transaction Josef Bacik
@ 2020-11-12 21:18 ` Josef Bacik
  2020-11-12 21:18 ` [PATCH 18/42] btrfs: handle record_root_in_trans failure in btrfs_record_root_in_trans Josef Bacik
                   ` (25 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:18 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

record_root_in_trans can fail currently, so handle this failure
properly.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/transaction.c | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
index c666e6bef0ff..91be4a1a6bc8 100644
--- a/fs/btrfs/transaction.c
+++ b/fs/btrfs/transaction.c
@@ -1440,7 +1440,9 @@ static int qgroup_account_snapshot(struct btrfs_trans_handle *trans,
 	 * recorded root will never be updated again, causing an outdated root
 	 * item.
 	 */
-	record_root_in_trans(trans, src, 1);
+	ret = record_root_in_trans(trans, src, 1);
+	if (ret)
+		return ret;
 
 	/*
 	 * We are going to commit transaction, see btrfs_commit_transaction()
@@ -1492,7 +1494,7 @@ static int qgroup_account_snapshot(struct btrfs_trans_handle *trans,
 	 * insert_dir_item()
 	 */
 	if (!ret)
-		record_root_in_trans(trans, parent, 1);
+		ret = record_root_in_trans(trans, parent, 1);
 	return ret;
 }
 
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 18/42] btrfs: handle record_root_in_trans failure in btrfs_record_root_in_trans
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (16 preceding siblings ...)
  2020-11-12 21:18 ` [PATCH 17/42] btrfs: handle record_root_in_trans failure in qgroup_account_snapshot Josef Bacik
@ 2020-11-12 21:18 ` Josef Bacik
  2020-11-12 21:18 ` [PATCH 19/42] btrfs: handle record_root_in_trans failure in create_pending_snapshot Josef Bacik
                   ` (24 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:18 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

record_root_in_trans can fail currently, handle this failure properly.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/transaction.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
index 91be4a1a6bc8..f255274d4cb5 100644
--- a/fs/btrfs/transaction.c
+++ b/fs/btrfs/transaction.c
@@ -483,6 +483,7 @@ int btrfs_record_root_in_trans(struct btrfs_trans_handle *trans,
 			       struct btrfs_root *root)
 {
 	struct btrfs_fs_info *fs_info = root->fs_info;
+	int ret;
 
 	if (!test_bit(BTRFS_ROOT_SHAREABLE, &root->state))
 		return 0;
@@ -497,10 +498,10 @@ int btrfs_record_root_in_trans(struct btrfs_trans_handle *trans,
 		return 0;
 
 	mutex_lock(&fs_info->reloc_mutex);
-	record_root_in_trans(trans, root, 0);
+	ret = record_root_in_trans(trans, root, 0);
 	mutex_unlock(&fs_info->reloc_mutex);
 
-	return 0;
+	return ret;
 }
 
 static inline int is_transaction_blocked(struct btrfs_transaction *trans)
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 19/42] btrfs: handle record_root_in_trans failure in create_pending_snapshot
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (17 preceding siblings ...)
  2020-11-12 21:18 ` [PATCH 18/42] btrfs: handle record_root_in_trans failure in btrfs_record_root_in_trans Josef Bacik
@ 2020-11-12 21:18 ` Josef Bacik
  2020-11-12 21:18 ` [PATCH 20/42] btrfs: do not panic in __add_reloc_root Josef Bacik
                   ` (23 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:18 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

record_root_in_trans can currently fail, so handle this failure
properly.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/transaction.c | 11 ++++++++---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
index f255274d4cb5..29084716b4d2 100644
--- a/fs/btrfs/transaction.c
+++ b/fs/btrfs/transaction.c
@@ -1572,8 +1572,9 @@ static noinline int create_pending_snapshot(struct btrfs_trans_handle *trans,
 	dentry = pending->dentry;
 	parent_inode = pending->dir;
 	parent_root = BTRFS_I(parent_inode)->root;
-	record_root_in_trans(trans, parent_root, 0);
-
+	ret = record_root_in_trans(trans, parent_root, 0);
+	if (ret)
+		goto fail;
 	cur_time = current_time(parent_inode);
 
 	/*
@@ -1609,7 +1610,11 @@ static noinline int create_pending_snapshot(struct btrfs_trans_handle *trans,
 		goto fail;
 	}
 
-	record_root_in_trans(trans, root, 0);
+	ret = record_root_in_trans(trans, root, 0);
+	if (ret) {
+		btrfs_abort_transaction(trans, ret);
+		goto fail;
+	}
 	btrfs_set_root_last_snapshot(&root->root_item, trans->transid);
 	memcpy(new_root_item, &root->root_item, sizeof(*new_root_item));
 	btrfs_check_and_init_root_item(new_root_item);
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 20/42] btrfs: do not panic in __add_reloc_root
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (18 preceding siblings ...)
  2020-11-12 21:18 ` [PATCH 19/42] btrfs: handle record_root_in_trans failure in create_pending_snapshot Josef Bacik
@ 2020-11-12 21:18 ` Josef Bacik
  2020-11-12 21:18 ` [PATCH 21/42] btrfs: have proper error handling in btrfs_init_reloc_root Josef Bacik
                   ` (22 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:18 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

If we have a duplicate entry for a reloc root then we could have fs
corruption that resulted in a double allocation.  This shouldn't happen
generally so leave an ASSERT() for this case, but return an error
instead of panicing in the normal user case.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/relocation.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 4d6f898025e5..1627e1378b35 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -637,10 +637,12 @@ static int __must_check __add_reloc_root(struct btrfs_root *root)
 	rb_node = rb_simple_insert(&rc->reloc_root_tree.rb_root,
 				   node->bytenr, &node->rb_node);
 	spin_unlock(&rc->reloc_root_tree.lock);
+	ASSERT(rb_node == NULL);
 	if (rb_node) {
-		btrfs_panic(fs_info, -EEXIST,
+		btrfs_err(fs_info,
 			    "Duplicate root found for start=%llu while inserting into relocation tree",
 			    node->bytenr);
+		return -EEXIST;
 	}
 
 	list_add_tail(&root->root_list, &rc->reloc_roots);
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 21/42] btrfs: have proper error handling in btrfs_init_reloc_root
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (19 preceding siblings ...)
  2020-11-12 21:18 ` [PATCH 20/42] btrfs: do not panic in __add_reloc_root Josef Bacik
@ 2020-11-12 21:18 ` Josef Bacik
  2020-11-12 21:18 ` [PATCH 22/42] btrfs: do proper error handling in create_reloc_root Josef Bacik
                   ` (21 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:18 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

create_reloc_root will return errors in the future, and __add_reloc_root
can return -ENOMEM or -EEXIST, so handle these errors properly.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/relocation.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 1627e1378b35..c0be6b1f22cb 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -860,9 +860,14 @@ int btrfs_init_reloc_root(struct btrfs_trans_handle *trans,
 	reloc_root = create_reloc_root(trans, root, root->root_key.objectid);
 	if (clear_rsv)
 		trans->block_rsv = rsv;
+	if (IS_ERR(reloc_root))
+		return PTR_ERR(reloc_root);
 
 	ret = __add_reloc_root(reloc_root);
-	BUG_ON(ret < 0);
+	if (ret) {
+		btrfs_put_root(reloc_root);
+		return ret;
+	}
 	root->reloc_root = btrfs_grab_root(reloc_root);
 	return 0;
 }
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 22/42] btrfs: do proper error handling in create_reloc_root
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (20 preceding siblings ...)
  2020-11-12 21:18 ` [PATCH 21/42] btrfs: have proper error handling in btrfs_init_reloc_root Josef Bacik
@ 2020-11-12 21:18 ` Josef Bacik
  2020-11-12 21:18 ` [PATCH 23/42] btrfs: handle btrfs_update_reloc_root failure in commit_fs_roots Josef Bacik
                   ` (20 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:18 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

We do memory allocations here, read blocks from disk, all sorts of
operations that could easily fail at any given point.  Instead of
panicing the box, simply return the error back up the chain, all callers
at this point have proper error handling.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/relocation.c | 22 ++++++++++++++++------
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index c0be6b1f22cb..d61dc2b1928c 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -737,10 +737,11 @@ static struct btrfs_root *create_reloc_root(struct btrfs_trans_handle *trans,
 	struct extent_buffer *eb;
 	struct btrfs_root_item *root_item;
 	struct btrfs_key root_key;
-	int ret;
+	int ret = 0;
 
 	root_item = kmalloc(sizeof(*root_item), GFP_NOFS);
-	BUG_ON(!root_item);
+	if (!root_item)
+		return ERR_PTR(-ENOMEM);
 
 	root_key.objectid = BTRFS_TREE_RELOC_OBJECTID;
 	root_key.type = BTRFS_ROOT_ITEM_KEY;
@@ -752,7 +753,9 @@ static struct btrfs_root *create_reloc_root(struct btrfs_trans_handle *trans,
 		/* called by btrfs_init_reloc_root */
 		ret = btrfs_copy_root(trans, root, root->commit_root, &eb,
 				      BTRFS_TREE_RELOC_OBJECTID);
-		BUG_ON(ret);
+		if (ret)
+			goto fail;
+
 		/*
 		 * Set the last_snapshot field to the generation of the commit
 		 * root - like this ctree.c:btrfs_block_can_be_shared() behaves
@@ -773,7 +776,8 @@ static struct btrfs_root *create_reloc_root(struct btrfs_trans_handle *trans,
 		 */
 		ret = btrfs_copy_root(trans, root, root->node, &eb,
 				      BTRFS_TREE_RELOC_OBJECTID);
-		BUG_ON(ret);
+		if (ret)
+			goto fail;
 	}
 
 	memcpy(root_item, &root->root_item, sizeof(*root_item));
@@ -793,14 +797,20 @@ static struct btrfs_root *create_reloc_root(struct btrfs_trans_handle *trans,
 
 	ret = btrfs_insert_root(trans, fs_info->tree_root,
 				&root_key, root_item);
-	BUG_ON(ret);
+	if (ret)
+		goto fail;
+
 	kfree(root_item);
 
 	reloc_root = btrfs_read_tree_root(fs_info->tree_root, &root_key);
-	BUG_ON(IS_ERR(reloc_root));
+	if (IS_ERR(reloc_root))
+		return reloc_root;
 	set_bit(BTRFS_ROOT_SHAREABLE, &reloc_root->state);
 	reloc_root->last_trans = trans->transid;
 	return reloc_root;
+fail:
+	kfree(root_item);
+	return ERR_PTR(ret);
 }
 
 /*
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 23/42] btrfs: handle btrfs_update_reloc_root failure in commit_fs_roots
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (21 preceding siblings ...)
  2020-11-12 21:18 ` [PATCH 22/42] btrfs: do proper error handling in create_reloc_root Josef Bacik
@ 2020-11-12 21:18 ` Josef Bacik
  2020-11-12 21:18 ` [PATCH 24/42] btrfs: change insert_dirty_subvol to return errors Josef Bacik
                   ` (19 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:18 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

btrfs_update_reloc_root will will return errors in the future, so handle
the error properly in commit_fs_roots.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/transaction.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
index 29084716b4d2..93b62ead47f2 100644
--- a/fs/btrfs/transaction.c
+++ b/fs/btrfs/transaction.c
@@ -1346,7 +1346,9 @@ static noinline int commit_fs_roots(struct btrfs_trans_handle *trans)
 			spin_unlock(&fs_info->fs_roots_radix_lock);
 
 			btrfs_free_log(trans, root);
-			btrfs_update_reloc_root(trans, root);
+			err = btrfs_update_reloc_root(trans, root);
+			if (err)
+				return err;
 
 			btrfs_save_ino_cache(root, trans);
 
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 24/42] btrfs: change insert_dirty_subvol to return errors
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (22 preceding siblings ...)
  2020-11-12 21:18 ` [PATCH 23/42] btrfs: handle btrfs_update_reloc_root failure in commit_fs_roots Josef Bacik
@ 2020-11-12 21:18 ` Josef Bacik
  2020-11-12 21:18 ` [PATCH 25/42] btrfs: handle btrfs_update_reloc_root failure in insert_dirty_subvol Josef Bacik
                   ` (18 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:18 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

This will be able to return errors in the future, so change it to return
an error and handle the error appropriately.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/relocation.c | 16 +++++++++++-----
 1 file changed, 11 insertions(+), 5 deletions(-)

diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index d61dc2b1928c..5174f5b2765e 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -1575,9 +1575,9 @@ static int find_next_key(struct btrfs_path *path, int level,
 /*
  * Insert current subvolume into reloc_control::dirty_subvol_roots
  */
-static void insert_dirty_subvol(struct btrfs_trans_handle *trans,
-				struct reloc_control *rc,
-				struct btrfs_root *root)
+static int insert_dirty_subvol(struct btrfs_trans_handle *trans,
+			       struct reloc_control *rc,
+			       struct btrfs_root *root)
 {
 	struct btrfs_root *reloc_root = root->reloc_root;
 	struct btrfs_root_item *reloc_root_item;
@@ -1597,6 +1597,7 @@ static void insert_dirty_subvol(struct btrfs_trans_handle *trans,
 		btrfs_grab_root(root);
 		list_add_tail(&root->reloc_dirty_list, &rc->dirty_subvol_roots);
 	}
+	return 0;
 }
 
 static int clean_dirty_subvols(struct reloc_control *rc)
@@ -1808,8 +1809,13 @@ static noinline_for_stack int merge_reloc_root(struct reloc_control *rc,
 out:
 	btrfs_free_path(path);
 
-	if (err == 0)
-		insert_dirty_subvol(trans, rc, root);
+	if (err == 0) {
+		ret = insert_dirty_subvol(trans, rc, root);
+		if (ret) {
+			btrfs_abort_transaction(trans, ret);
+			err = ret;
+		}
+	}
 
 	if (trans)
 		btrfs_end_transaction_throttle(trans);
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 25/42] btrfs: handle btrfs_update_reloc_root failure in insert_dirty_subvol
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (23 preceding siblings ...)
  2020-11-12 21:18 ` [PATCH 24/42] btrfs: change insert_dirty_subvol to return errors Josef Bacik
@ 2020-11-12 21:18 ` Josef Bacik
  2020-11-12 21:18 ` [PATCH 26/42] btrfs: handle btrfs_update_reloc_root failure in prepare_to_merge Josef Bacik
                   ` (17 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:18 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

btrfs_update_reloc_root will will return errors in the future, so handle
the error properly in insert_dirty_subvol.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/relocation.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 5174f5b2765e..d75c9be438bb 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -1581,6 +1581,7 @@ static int insert_dirty_subvol(struct btrfs_trans_handle *trans,
 {
 	struct btrfs_root *reloc_root = root->reloc_root;
 	struct btrfs_root_item *reloc_root_item;
+	int ret;
 
 	/* @root must be a subvolume tree root with a valid reloc tree */
 	ASSERT(root->root_key.objectid != BTRFS_TREE_RELOC_OBJECTID);
@@ -1591,7 +1592,9 @@ static int insert_dirty_subvol(struct btrfs_trans_handle *trans,
 		sizeof(reloc_root_item->drop_progress));
 	btrfs_set_root_drop_level(reloc_root_item, 0);
 	btrfs_set_root_refs(reloc_root_item, 0);
-	btrfs_update_reloc_root(trans, root);
+	ret = btrfs_update_reloc_root(trans, root);
+	if (ret)
+		return ret;
 
 	if (list_empty(&root->reloc_dirty_list)) {
 		btrfs_grab_root(root);
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 26/42] btrfs: handle btrfs_update_reloc_root failure in prepare_to_merge
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (24 preceding siblings ...)
  2020-11-12 21:18 ` [PATCH 25/42] btrfs: handle btrfs_update_reloc_root failure in insert_dirty_subvol Josef Bacik
@ 2020-11-12 21:18 ` Josef Bacik
  2020-11-12 21:18 ` [PATCH 27/42] btrfs: do proper error handling in btrfs_update_reloc_root Josef Bacik
                   ` (16 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:18 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

btrfs_update_reloc_root will will return errors in the future, so handle
an error properly in prepare_to_merge.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/relocation.c | 13 ++++++++++++-
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index d75c9be438bb..0daa4e671182 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -1891,10 +1891,21 @@ int prepare_to_merge(struct reloc_control *rc, int err)
 		 */
 		if (!err)
 			btrfs_set_root_refs(&reloc_root->root_item, 1);
-		btrfs_update_reloc_root(trans, root);
+		ret = btrfs_update_reloc_root(trans, root);
 
+		/*
+		 * Even if we have an error we need this reloc root back on our
+		 * list so we can clean up properly.
+		 */
 		list_add(&reloc_root->root_list, &reloc_roots);
 		btrfs_put_root(root);
+
+		if (ret) {
+			btrfs_abort_transaction(trans, ret);
+			if (!err)
+				err = ret;
+			break;
+		}
 	}
 
 	list_splice(&reloc_roots, &rc->reloc_roots);
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 27/42] btrfs: do proper error handling in btrfs_update_reloc_root
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (25 preceding siblings ...)
  2020-11-12 21:18 ` [PATCH 26/42] btrfs: handle btrfs_update_reloc_root failure in prepare_to_merge Josef Bacik
@ 2020-11-12 21:18 ` Josef Bacik
  2020-11-12 21:18 ` [PATCH 28/42] btrfs: convert logic BUG_ON()'s in replace_path to ASSERT()'s Josef Bacik
                   ` (15 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:18 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

We call btrfs_update_root in btrfs_update_reloc_root, which can fail for
all sorts of reasons, including IO errors.  Instead of panicing the box
lets return the error, now that all callers properly handle those
errors.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/relocation.c | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 0daa4e671182..04a0eb2d434c 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -894,7 +894,7 @@ int btrfs_update_reloc_root(struct btrfs_trans_handle *trans,
 	int ret;
 
 	if (!have_reloc_root(root))
-		goto out;
+		return 0;
 
 	reloc_root = root->reloc_root;
 	root_item = &reloc_root->root_item;
@@ -927,10 +927,8 @@ int btrfs_update_reloc_root(struct btrfs_trans_handle *trans,
 
 	ret = btrfs_update_root(trans, fs_info->tree_root,
 				&reloc_root->root_key, root_item);
-	BUG_ON(ret);
 	btrfs_put_root(reloc_root);
-out:
-	return 0;
+	return ret;
 }
 
 /*
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 28/42] btrfs: convert logic BUG_ON()'s in replace_path to ASSERT()'s
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (26 preceding siblings ...)
  2020-11-12 21:18 ` [PATCH 27/42] btrfs: do proper error handling in btrfs_update_reloc_root Josef Bacik
@ 2020-11-12 21:18 ` Josef Bacik
  2020-11-12 21:18 ` [PATCH 29/42] btrfs: handle initial btrfs_cow_block error in replace_path Josef Bacik
                   ` (14 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:18 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

A few BUG_ON()'s in replace_path are purely to keep us from making
logical mistakes, so replace them with ASSERT()'s.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/relocation.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 04a0eb2d434c..2d1aab778fb6 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -1202,8 +1202,8 @@ int replace_path(struct btrfs_trans_handle *trans, struct reloc_control *rc,
 	int ret;
 	int slot;
 
-	BUG_ON(src->root_key.objectid != BTRFS_TREE_RELOC_OBJECTID);
-	BUG_ON(dest->root_key.objectid == BTRFS_TREE_RELOC_OBJECTID);
+	ASSERT(src->root_key.objectid == BTRFS_TREE_RELOC_OBJECTID);
+	ASSERT(dest->root_key.objectid != BTRFS_TREE_RELOC_OBJECTID);
 
 	last_snapshot = btrfs_root_last_snapshot(&src->root_item);
 again:
@@ -1236,7 +1236,7 @@ int replace_path(struct btrfs_trans_handle *trans, struct reloc_control *rc,
 		struct btrfs_key first_key;
 
 		level = btrfs_header_level(parent);
-		BUG_ON(level < lowest_level);
+		ASSERT(level >= lowest_level);
 
 		ret = btrfs_bin_search(parent, &key, &slot);
 		if (ret < 0)
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 29/42] btrfs: handle initial btrfs_cow_block error in replace_path
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (27 preceding siblings ...)
  2020-11-12 21:18 ` [PATCH 28/42] btrfs: convert logic BUG_ON()'s in replace_path to ASSERT()'s Josef Bacik
@ 2020-11-12 21:18 ` Josef Bacik
  2020-11-12 21:18 ` [PATCH 30/42] btrfs: handle the loop " Josef Bacik
                   ` (13 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:18 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

If we error out cow'ing the root node when doing a replace_path then we
simply unlock and free the buffer and return the error.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/relocation.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 2d1aab778fb6..07092d7a4d0e 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -1222,7 +1222,11 @@ int replace_path(struct btrfs_trans_handle *trans, struct reloc_control *rc,
 	if (cow) {
 		ret = btrfs_cow_block(trans, dest, eb, NULL, 0, &eb,
 				      BTRFS_NESTING_COW);
-		BUG_ON(ret);
+		if (ret) {
+			btrfs_tree_unlock(eb);
+			free_extent_buffer(eb);
+			return ret;
+		}
 	}
 
 	if (next_key) {
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 30/42] btrfs: handle the loop btrfs_cow_block error in replace_path
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (28 preceding siblings ...)
  2020-11-12 21:18 ` [PATCH 29/42] btrfs: handle initial btrfs_cow_block error in replace_path Josef Bacik
@ 2020-11-12 21:18 ` Josef Bacik
  2020-11-12 21:18 ` [PATCH 31/42] btrfs: handle btrfs_search_slot failure " Josef Bacik
                   ` (12 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:18 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

As we loop through the path to replace it, we will have to cow each node
we hit on the path down to the lowest_level.  If this fails we simply
unlock and free the block and break from the loop.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/relocation.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 07092d7a4d0e..52ae6bba2261 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -1294,7 +1294,11 @@ int replace_path(struct btrfs_trans_handle *trans, struct reloc_control *rc,
 				ret = btrfs_cow_block(trans, dest, eb, parent,
 						      slot, &eb,
 						      BTRFS_NESTING_COW);
-				BUG_ON(ret);
+				if (ret) {
+					btrfs_tree_unlock(eb);
+					free_extent_buffer(eb);
+					break;
+				}
 			}
 
 			btrfs_tree_unlock(parent);
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 31/42] btrfs: handle btrfs_search_slot failure in replace_path
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (29 preceding siblings ...)
  2020-11-12 21:18 ` [PATCH 30/42] btrfs: handle the loop " Josef Bacik
@ 2020-11-12 21:18 ` Josef Bacik
  2020-11-12 21:18 ` [PATCH 32/42] btrfs: handle errors in reference count manipulation " Josef Bacik
                   ` (11 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:18 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

This can fail for any number of reasons, why bring the whole box down
with it?

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/relocation.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 52ae6bba2261..2c7196e4ef8f 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -1322,7 +1322,8 @@ int replace_path(struct btrfs_trans_handle *trans, struct reloc_control *rc,
 		path->lowest_level = level;
 		ret = btrfs_search_slot(trans, src, &key, path, 0, 1);
 		path->lowest_level = 0;
-		BUG_ON(ret);
+		if (ret)
+			break;
 
 		/*
 		 * Info qgroup to trace both subtrees.
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 32/42] btrfs: handle errors in reference count manipulation in replace_path
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (30 preceding siblings ...)
  2020-11-12 21:18 ` [PATCH 31/42] btrfs: handle btrfs_search_slot failure " Josef Bacik
@ 2020-11-12 21:18 ` Josef Bacik
  2020-11-12 21:19 ` [PATCH 33/42] btrfs: handle extent reference errors in do_relocation Josef Bacik
                   ` (10 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:18 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

If any of the reference count manipulation stuff fails in replace_path
we need to abort the transaction, as we've modified the blocks already.
We can simply break at this point and everything will be cleaned up.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/relocation.c | 20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 2c7196e4ef8f..df45b4df989b 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -1363,27 +1363,39 @@ int replace_path(struct btrfs_trans_handle *trans, struct reloc_control *rc,
 		ref.skip_qgroup = true;
 		btrfs_init_tree_ref(&ref, level - 1, src->root_key.objectid);
 		ret = btrfs_inc_extent_ref(trans, &ref);
-		BUG_ON(ret);
+		if (ret) {
+			btrfs_abort_transaction(trans, ret);
+			break;
+		}
 		btrfs_init_generic_ref(&ref, BTRFS_ADD_DELAYED_REF, new_bytenr,
 				       blocksize, 0);
 		ref.skip_qgroup = true;
 		btrfs_init_tree_ref(&ref, level - 1, dest->root_key.objectid);
 		ret = btrfs_inc_extent_ref(trans, &ref);
-		BUG_ON(ret);
+		if (ret) {
+			btrfs_abort_transaction(trans, ret);
+			break;
+		}
 
 		btrfs_init_generic_ref(&ref, BTRFS_DROP_DELAYED_REF, new_bytenr,
 				       blocksize, path->nodes[level]->start);
 		btrfs_init_tree_ref(&ref, level - 1, src->root_key.objectid);
 		ref.skip_qgroup = true;
 		ret = btrfs_free_extent(trans, &ref);
-		BUG_ON(ret);
+		if (ret) {
+			btrfs_abort_transaction(trans, ret);
+			break;
+		}
 
 		btrfs_init_generic_ref(&ref, BTRFS_DROP_DELAYED_REF, old_bytenr,
 				       blocksize, 0);
 		btrfs_init_tree_ref(&ref, level - 1, dest->root_key.objectid);
 		ref.skip_qgroup = true;
 		ret = btrfs_free_extent(trans, &ref);
-		BUG_ON(ret);
+		if (ret) {
+			btrfs_abort_transaction(trans, ret);
+			break;
+		}
 
 		btrfs_unlock_up_safe(path, 0);
 
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 33/42] btrfs: handle extent reference errors in do_relocation
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (31 preceding siblings ...)
  2020-11-12 21:18 ` [PATCH 32/42] btrfs: handle errors in reference count manipulation " Josef Bacik
@ 2020-11-12 21:19 ` Josef Bacik
  2020-11-12 21:19 ` [PATCH 34/42] btrfs: check for BTRFS_BLOCK_FLAG_FULL_BACKREF being set improperly Josef Bacik
                   ` (9 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:19 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

We can already deal with errors appropriately from do_relocation, simply
handle any errors that come from changing the refs at this point
cleanly.  We have to abort the transaction if we fail here as we've
modified metadata at this point.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/relocation.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index df45b4df989b..100cd8eba91c 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -2476,10 +2476,12 @@ static int do_relocation(struct btrfs_trans_handle *trans,
 			btrfs_init_tree_ref(&ref, node->level,
 					    btrfs_header_owner(upper->eb));
 			ret = btrfs_inc_extent_ref(trans, &ref);
-			BUG_ON(ret);
-
-			ret = btrfs_drop_subtree(trans, root, eb, upper->eb);
-			BUG_ON(ret);
+			if (!ret)
+				btrfs_drop_subtree(trans, root, eb, upper->eb);
+			if (ret) {
+				btrfs_abort_transaction(trans, ret);
+				err = ret;
+			}
 		}
 next:
 		if (!upper->pending)
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 34/42] btrfs: check for BTRFS_BLOCK_FLAG_FULL_BACKREF being set improperly
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (32 preceding siblings ...)
  2020-11-12 21:19 ` [PATCH 33/42] btrfs: handle extent reference errors in do_relocation Josef Bacik
@ 2020-11-12 21:19 ` Josef Bacik
  2020-11-12 21:19 ` [PATCH 35/42] btrfs: remove the extent item sanity checks in relocate_block_group Josef Bacik
                   ` (8 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:19 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

We need to validate that a data extent item does not have the
FULL_BACKREF flag set on it's flags.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/tree-checker.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/fs/btrfs/tree-checker.c b/fs/btrfs/tree-checker.c
index d8af62d9f98b..df39ad294aa2 100644
--- a/fs/btrfs/tree-checker.c
+++ b/fs/btrfs/tree-checker.c
@@ -1272,6 +1272,11 @@ static int check_extent_item(struct extent_buffer *leaf,
 				   key->offset, fs_info->sectorsize);
 			return -EUCLEAN;
 		}
+		if (flags & BTRFS_BLOCK_FLAG_FULL_BACKREF) {
+			extent_err(leaf, slot,
+			"invalid extent flag, data has full backref set");
+			return -EUCLEAN;
+		}
 	}
 	ptr = (unsigned long)(struct btrfs_extent_item *)(ei + 1);
 
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 35/42] btrfs: remove the extent item sanity checks in relocate_block_group
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (33 preceding siblings ...)
  2020-11-12 21:19 ` [PATCH 34/42] btrfs: check for BTRFS_BLOCK_FLAG_FULL_BACKREF being set improperly Josef Bacik
@ 2020-11-12 21:19 ` Josef Bacik
  2020-11-12 21:19 ` [PATCH 36/42] btrfs: do proper error handling in create_reloc_inode Josef Bacik
                   ` (7 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:19 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

These checks are all taken care of for us by the tree checker code.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/relocation.c | 28 ----------------------------
 1 file changed, 28 deletions(-)

diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 100cd8eba91c..80d5fea41791 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -3365,20 +3365,6 @@ static void unset_reloc_control(struct reloc_control *rc)
 	mutex_unlock(&fs_info->reloc_mutex);
 }
 
-static int check_extent_flags(u64 flags)
-{
-	if ((flags & BTRFS_EXTENT_FLAG_DATA) &&
-	    (flags & BTRFS_EXTENT_FLAG_TREE_BLOCK))
-		return 1;
-	if (!(flags & BTRFS_EXTENT_FLAG_DATA) &&
-	    !(flags & BTRFS_EXTENT_FLAG_TREE_BLOCK))
-		return 1;
-	if ((flags & BTRFS_EXTENT_FLAG_DATA) &&
-	    (flags & BTRFS_BLOCK_FLAG_FULL_BACKREF))
-		return 1;
-	return 0;
-}
-
 static noinline_for_stack
 int prepare_to_relocate(struct reloc_control *rc)
 {
@@ -3430,7 +3416,6 @@ static noinline_for_stack int relocate_block_group(struct reloc_control *rc)
 	struct btrfs_path *path;
 	struct btrfs_extent_item *ei;
 	u64 flags;
-	u32 item_size;
 	int ret;
 	int err = 0;
 	int progress = 0;
@@ -3479,19 +3464,6 @@ static noinline_for_stack int relocate_block_group(struct reloc_control *rc)
 
 		ei = btrfs_item_ptr(path->nodes[0], path->slots[0],
 				    struct btrfs_extent_item);
-		item_size = btrfs_item_size_nr(path->nodes[0], path->slots[0]);
-		if (item_size >= sizeof(*ei)) {
-			flags = btrfs_extent_flags(path->nodes[0], ei);
-			ret = check_extent_flags(flags);
-			BUG_ON(ret);
-		} else if (unlikely(item_size == sizeof(struct btrfs_extent_item_v0))) {
-			err = -EINVAL;
-			btrfs_print_v0_err(trans->fs_info);
-			btrfs_abort_transaction(trans, err);
-			break;
-		} else {
-			BUG();
-		}
 
 		if (flags & BTRFS_EXTENT_FLAG_TREE_BLOCK) {
 			ret = add_tree_block(rc, &key, path, &blocks);
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 36/42] btrfs: do proper error handling in create_reloc_inode
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (34 preceding siblings ...)
  2020-11-12 21:19 ` [PATCH 35/42] btrfs: remove the extent item sanity checks in relocate_block_group Josef Bacik
@ 2020-11-12 21:19 ` Josef Bacik
  2020-11-12 21:19 ` [PATCH 37/42] btrfs: handle __add_reloc_root failure in btrfs_recover_relocation Josef Bacik
                   ` (6 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:19 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

We already handle some errors in this function, and the callers do the
correct error handling, so clean up the rest of the function to do the
appropriate error handling.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/relocation.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 80d5fea41791..c6619e54f424 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -3628,10 +3628,15 @@ struct inode *create_reloc_inode(struct btrfs_fs_info *fs_info,
 		goto out;
 
 	err = __insert_orphan_inode(trans, root, objectid);
-	BUG_ON(err);
+	if (err)
+		goto out;
 
 	inode = btrfs_iget(fs_info->sb, objectid, root);
-	BUG_ON(IS_ERR(inode));
+	if (IS_ERR(inode)) {
+		err = PTR_ERR(inode);
+		inode = NULL;
+		goto out;
+	}
 	BTRFS_I(inode)->index_cnt = group->start;
 
 	err = btrfs_orphan_add(trans, BTRFS_I(inode));
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 37/42] btrfs: handle __add_reloc_root failure in btrfs_recover_relocation
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (35 preceding siblings ...)
  2020-11-12 21:19 ` [PATCH 36/42] btrfs: do proper error handling in create_reloc_inode Josef Bacik
@ 2020-11-12 21:19 ` Josef Bacik
  2020-11-12 21:19 ` [PATCH 38/42] btrfs: handle __add_reloc_root failure in btrfs_reloc_post_snapshot Josef Bacik
                   ` (5 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:19 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

We can already handle errors appropriately from this function, deal with
an error coming from __add_reloc_root appropriately.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/relocation.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index c6619e54f424..832bf7c19dac 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -3978,7 +3978,12 @@ int btrfs_recover_relocation(struct btrfs_root *root)
 		}
 
 		err = __add_reloc_root(reloc_root);
-		BUG_ON(err < 0); /* -ENOMEM or logic error */
+		if (err) {
+			list_add_tail(&reloc_root->root_list, &reloc_roots);
+			btrfs_put_root(fs_root);
+			btrfs_end_transaction(trans);
+			goto out_unset;
+		}
 		fs_root->reloc_root = btrfs_grab_root(reloc_root);
 		btrfs_put_root(fs_root);
 	}
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 38/42] btrfs: handle __add_reloc_root failure in btrfs_reloc_post_snapshot
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (36 preceding siblings ...)
  2020-11-12 21:19 ` [PATCH 37/42] btrfs: handle __add_reloc_root failure in btrfs_recover_relocation Josef Bacik
@ 2020-11-12 21:19 ` Josef Bacik
  2020-11-12 21:19 ` [PATCH 39/42] btrfs: cleanup error handling in prepare_to_merge Josef Bacik
                   ` (4 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:19 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

If we fail to add the reloc root, drop it and return the error.  All
callers of this function already handle errors appropriately.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/relocation.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 832bf7c19dac..651295864ec0 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -4198,7 +4198,10 @@ int btrfs_reloc_post_snapshot(struct btrfs_trans_handle *trans,
 		return PTR_ERR(reloc_root);
 
 	ret = __add_reloc_root(reloc_root);
-	BUG_ON(ret < 0);
+	if (ret) {
+		btrfs_put_root(reloc_root);
+		return ret;
+	}
 	new_root->reloc_root = btrfs_grab_root(reloc_root);
 
 	if (rc->create_reloc_tree)
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 39/42] btrfs: cleanup error handling in prepare_to_merge
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (37 preceding siblings ...)
  2020-11-12 21:19 ` [PATCH 38/42] btrfs: handle __add_reloc_root failure in btrfs_reloc_post_snapshot Josef Bacik
@ 2020-11-12 21:19 ` Josef Bacik
  2020-11-12 21:19 ` [PATCH 40/42] btrfs: handle extent corruption with select_one_root properly Josef Bacik
                   ` (3 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:19 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

This probably can't happen even with a corrupt file system, because we
would have failed much earlier on than here.  However there's no reason
we can't just check and bail out as appropriate, so do that and convert
the correctness BUG_ON() to an ASSERT().

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/relocation.c | 10 ++++++++--
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 651295864ec0..32e523361240 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -1901,8 +1901,14 @@ int prepare_to_merge(struct reloc_control *rc, int err)
 
 		root = btrfs_get_fs_root(fs_info, reloc_root->root_key.offset,
 				false);
-		BUG_ON(IS_ERR(root));
-		BUG_ON(root->reloc_root != reloc_root);
+		if (IS_ERR(root)) {
+			list_add(&reloc_root->root_list, &reloc_roots);
+			btrfs_abort_transaction(trans, (int)PTR_ERR(root));
+			if (!err)
+				err = PTR_ERR(root);
+			break;
+		}
+		ASSERT(root->reloc_root == reloc_root);
 
 		/*
 		 * set reference count to 1, so btrfs_recover_relocation
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 40/42] btrfs: handle extent corruption with select_one_root properly
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (38 preceding siblings ...)
  2020-11-12 21:19 ` [PATCH 39/42] btrfs: cleanup error handling in prepare_to_merge Josef Bacik
@ 2020-11-12 21:19 ` Josef Bacik
  2020-11-12 21:19 ` [PATCH 41/42] btrfs: do proper error handling in merge_reloc_roots Josef Bacik
                   ` (2 subsequent siblings)
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:19 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

In corruption cases we could have paths from a block up to no root at
all, and thus we'll BUG_ON(!root) in select_one_root.  Handle this by
adding an ASSERT() for developers, and returning an error for normal
users.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/relocation.c | 19 ++++++++++++++++---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 32e523361240..4648675980b9 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -2224,7 +2224,16 @@ struct btrfs_root *select_one_root(struct btrfs_backref_node *node)
 		cond_resched();
 		next = walk_up_backref(next, edges, &index);
 		root = next->root;
-		BUG_ON(!root);
+
+		/*
+		 * This can occur if we have incomplete extent refs leading all
+		 * the way up a particular path, in this case return -EUCLEAN.
+		 * However leave as an ASSERT() for developers, because it could
+		 * indicate a bug in the backref code.
+		 */
+		ASSERT(root);
+		if (!root)
+			return ERR_PTR(-EUCLEAN);
 
 		/* No other choice for non-shareable tree */
 		if (!test_bit(BTRFS_ROOT_SHAREABLE, &root->state))
@@ -2642,8 +2651,12 @@ static int relocate_tree_block(struct btrfs_trans_handle *trans,
 
 	BUG_ON(node->processed);
 	root = select_one_root(node);
-	if (root == ERR_PTR(-ENOENT)) {
-		update_processed_blocks(rc, node);
+	if (IS_ERR(root)) {
+		ret = PTR_ERR(root);
+		if (ret == -ENOENT) {
+			ret = 0;
+			update_processed_blocks(rc, node);
+		}
 		goto out;
 	}
 
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 41/42] btrfs: do proper error handling in merge_reloc_roots
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (39 preceding siblings ...)
  2020-11-12 21:19 ` [PATCH 40/42] btrfs: handle extent corruption with select_one_root properly Josef Bacik
@ 2020-11-12 21:19 ` Josef Bacik
  2020-11-12 21:19 ` [PATCH 42/42] btrfs: check return value of btrfs_commit_transaction in relocation Josef Bacik
  2020-11-13  3:53 ` [PATCH 00/42] Cleanup error handling " Zygo Blaxell
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:19 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

We have a BUG_ON() if we get an error back from btrfs_get_fs_root().
This honestly should never fail, as at this point we have a solid
coordination of fs root to reloc root, and these roots will all be in
memory.  But in the name of killing BUG_ON()'s remove this one and
handle the error properly.  Change the remaining BUG_ON() to an
ASSERT().

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/relocation.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index 4648675980b9..ef7430eaa119 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -1980,9 +1980,18 @@ void merge_reloc_roots(struct reloc_control *rc)
 
 		root = btrfs_get_fs_root(fs_info, reloc_root->root_key.offset,
 					 false);
+		if (IS_ERR(root)) {
+			/*
+			 * This likely won't happen, since we would have failed
+			 * at a higher level.  However for correctness sake
+			 * handle the error anyway.
+			 */
+			ret = PTR_ERR(root);
+			goto out;
+		}
+
 		if (btrfs_root_refs(&reloc_root->root_item) > 0) {
-			BUG_ON(IS_ERR(root));
-			BUG_ON(root->reloc_root != reloc_root);
+			ASSERT(root->reloc_root == reloc_root);
 			ret = merge_reloc_root(rc, root);
 			btrfs_put_root(root);
 			if (ret) {
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* [PATCH 42/42] btrfs: check return value of btrfs_commit_transaction in relocation
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (40 preceding siblings ...)
  2020-11-12 21:19 ` [PATCH 41/42] btrfs: do proper error handling in merge_reloc_roots Josef Bacik
@ 2020-11-12 21:19 ` Josef Bacik
  2020-11-13  3:53 ` [PATCH 00/42] Cleanup error handling " Zygo Blaxell
  42 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-12 21:19 UTC (permalink / raw)
  To: linux-btrfs, kernel-team

There's a few places where we don't check the return value of
btrfs_commit_transaction in relocation.c.  Thankfully all these places
have straightforward error handling, so simply change all of the sites
at once.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
 fs/btrfs/relocation.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/fs/btrfs/relocation.c b/fs/btrfs/relocation.c
index ef7430eaa119..e9e6f518fe26 100644
--- a/fs/btrfs/relocation.c
+++ b/fs/btrfs/relocation.c
@@ -1936,7 +1936,7 @@ int prepare_to_merge(struct reloc_control *rc, int err)
 	list_splice(&reloc_roots, &rc->reloc_roots);
 
 	if (!err)
-		btrfs_commit_transaction(trans);
+		err = btrfs_commit_transaction(trans);
 	else
 		btrfs_end_transaction(trans);
 	return err;
@@ -3431,8 +3431,7 @@ int prepare_to_relocate(struct reloc_control *rc)
 		 */
 		return PTR_ERR(trans);
 	}
-	btrfs_commit_transaction(trans);
-	return 0;
+	return btrfs_commit_transaction(trans);
 }
 
 static noinline_for_stack int relocate_block_group(struct reloc_control *rc)
@@ -3590,7 +3589,9 @@ static noinline_for_stack int relocate_block_group(struct reloc_control *rc)
 		err = PTR_ERR(trans);
 		goto out_free;
 	}
-	btrfs_commit_transaction(trans);
+	ret = btrfs_commit_transaction(trans);
+	if (ret && !err)
+		err = ret;
 out_free:
 	ret = clean_dirty_subvols(rc);
 	if (ret < 0 && !err)
-- 
2.26.2


^ permalink raw reply related	[flat|nested] 49+ messages in thread

* Re: [PATCH 01/42] btrfs: allow error injection for btrfs_search_slot and btrfs_cow_block
  2020-11-12 21:18 ` [PATCH 01/42] btrfs: allow error injection for btrfs_search_slot and btrfs_cow_block Josef Bacik
@ 2020-11-13  0:02   ` Qu Wenruo
  2020-11-13 11:05     ` Josef Bacik
  0 siblings, 1 reply; 49+ messages in thread
From: Qu Wenruo @ 2020-11-13  0:02 UTC (permalink / raw)
  To: Josef Bacik, linux-btrfs, kernel-team


[-- Attachment #1.1: Type: text/plain, Size: 1417 bytes --]



On 2020/11/13 上午5:18, Josef Bacik wrote:
> The following patches are going to address error handling in relocation,
> in order to test those patches I need to be able to inject errors in
> btrfs_search_slot and btrfs_cow_block, as we call both of these pretty
> often in different cases during relocation.
> 
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
> ---
>  fs/btrfs/ctree.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
> index d2d5854d51a7..a51e761bf00f 100644
> --- a/fs/btrfs/ctree.c
> +++ b/fs/btrfs/ctree.c
> @@ -1493,6 +1493,7 @@ noinline int btrfs_cow_block(struct btrfs_trans_handle *trans,
>  
>  	return ret;
>  }
> +ALLOW_ERROR_INJECTION(btrfs_cow_block, ERRNO);
>  
>  /*
>   * helper function for defrag to decide if two blocks pointed to by a
> @@ -2870,6 +2871,7 @@ int btrfs_search_slot(struct btrfs_trans_handle *trans, struct btrfs_root *root,
>  		btrfs_release_path(p);
>  	return ret;
>  }
> +ALLOW_ERROR_INJECTION(btrfs_search_slot, ERRNO);

This concerns me a little.

For error case, wouldn't we also free the path?
But if we just override the error, the path is not freed by anyone,
neither caller nor btrfs_search_slot() would free the path.

Or did I miss something?

Thanks,
Qu
>  
>  /*
>   * Like btrfs_search_slot, this looks for a key in the given tree. It uses the
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 00/42] Cleanup error handling in relocation
  2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
                   ` (41 preceding siblings ...)
  2020-11-12 21:19 ` [PATCH 42/42] btrfs: check return value of btrfs_commit_transaction in relocation Josef Bacik
@ 2020-11-13  3:53 ` Zygo Blaxell
  2020-11-13 11:03   ` Josef Bacik
  42 siblings, 1 reply; 49+ messages in thread
From: Zygo Blaxell @ 2020-11-13  3:53 UTC (permalink / raw)
  To: Josef Bacik; +Cc: linux-btrfs, kernel-team

On Thu, Nov 12, 2020 at 04:18:27PM -0500, Josef Bacik wrote:
> Hello,
> 
> Relocation is the last place that is not able to handle errors at all, which
> results in all sorts of lovely panics if you encounter corruptions or IO errors.
> I'm going to start cleaning up relocation, but before I move code around I want
> the error handling to be somewhat sane, so I'm not changing behavior and error
> handling at the same time.
> 
> These patches are purely about error handling, there is no behavior changing
> other than returning errors up the chain properly.  There is a lot of room for
> follow up cleanups, which will happen next.  However I wanted to get this series
> done today and out so we could get it merged ASAP, and then the follow up
> cleanups can happen later as they are less important and less critical.
> 
> The only exception to the above is the patch to add the error injection sites
> for btrfs_cow_block and btrfs_search_slot, and a lockdep fix that I discovered
> while running my tests, those are the first two patches in the series.
> 
> I tested this with my error injection stress test, where I keep track of all
> stack traces that have been tested and only inject errors when we have a new
> stack trace, which means I should have covered all of the various error
> conditions.  With this patchset I'm no longer panicing while stressing the error
> conditions.  Thanks,

I just threw this patch set on top of kdave/for-next
(a12315094469d573e41fe3eee91c99a83cec02df) and I got something that
looks like runaway balances:

	[Thu Nov 12 22:16:37 2020] BTRFS info (device dm-0): balance: start -dlimit=9
	[Thu Nov 12 22:16:37 2020] BTRFS info (device dm-0): relocating block group 37256442150912 flags data
	[Thu Nov 12 22:16:38 2020] BTRFS info (device dm-0): found 19 extents, loops 1, stage: move data extents
	[Thu Nov 12 22:16:41 2020] BTRFS info (device dm-0): found 19 extents, loops 2, stage: move data extents
	[Thu Nov 12 22:16:45 2020] BTRFS info (device dm-0): found 19 extents, loops 3, stage: move data extents
	[Thu Nov 12 22:16:46 2020] BTRFS info (device dm-0): found 19 extents, loops 4, stage: move data extents
	[Thu Nov 12 22:16:47 2020] BTRFS info (device dm-0): found 19 extents, loops 5, stage: move data extents
	[Thu Nov 12 22:16:47 2020] avg_delayed_ref_runtime = 3492558, time = 750175264685, count = 214792
	[Thu Nov 12 22:16:50 2020] BTRFS info (device dm-0): found 19 extents, loops 6, stage: move data extents
	[Thu Nov 12 22:16:55 2020] BTRFS info (device dm-0): found 19 extents, loops 7, stage: move data extents
	[Thu Nov 12 22:16:58 2020] BTRFS info (device dm-0): found 19 extents, loops 8, stage: move data extents
	[Thu Nov 12 22:17:02 2020] BTRFS info (device dm-0): found 19 extents, loops 9, stage: move data extents
	[Thu Nov 12 22:17:07 2020] BTRFS info (device dm-0): found 19 extents, loops 10, stage: move data extents
	[Thu Nov 12 22:17:11 2020] BTRFS info (device dm-0): found 19 extents, loops 11, stage: move data extents
	[Thu Nov 12 22:17:15 2020] BTRFS info (device dm-0): found 19 extents, loops 12, stage: move data extents
	[Thu Nov 12 22:17:19 2020] BTRFS info (device dm-0): found 19 extents, loops 13, stage: move data extents
	[Thu Nov 12 22:17:23 2020] BTRFS info (device dm-0): found 19 extents, loops 14, stage: move data extents
	[Thu Nov 12 22:17:27 2020] BTRFS info (device dm-0): found 19 extents, loops 15, stage: move data extents
	[Thu Nov 12 22:17:31 2020] BTRFS info (device dm-0): found 19 extents, loops 16, stage: move data extents
	[Thu Nov 12 22:17:35 2020] BTRFS info (device dm-0): found 19 extents, loops 17, stage: move data extents
	[Thu Nov 12 22:17:40 2020] BTRFS info (device dm-0): found 19 extents, loops 18, stage: move data extents
	[Thu Nov 12 22:17:47 2020] BTRFS info (device dm-0): found 19 extents, loops 19, stage: move data extents
	[Thu Nov 12 22:17:51 2020] BTRFS info (device dm-0): found 19 extents, loops 20, stage: move data extents
	[Thu Nov 12 22:17:55 2020] BTRFS info (device dm-0): found 19 extents, loops 21, stage: move data extents
	[Thu Nov 12 22:17:59 2020] BTRFS info (device dm-0): found 19 extents, loops 22, stage: move data extents
	[Thu Nov 12 22:18:04 2020] BTRFS info (device dm-0): found 19 extents, loops 23, stage: move data extents
	[Thu Nov 12 22:18:07 2020] BTRFS info (device dm-0): found 19 extents, loops 24, stage: move data extents
	[Thu Nov 12 22:18:11 2020] BTRFS info (device dm-0): found 19 extents, loops 25, stage: move data extents
	[Thu Nov 12 22:18:15 2020] BTRFS info (device dm-0): found 19 extents, loops 26, stage: move data extents
	[Thu Nov 12 22:18:20 2020] BTRFS info (device dm-0): found 19 extents, loops 27, stage: move data extents
	[Thu Nov 12 22:18:24 2020] BTRFS info (device dm-0): found 19 extents, loops 28, stage: move data extents
	[Thu Nov 12 22:18:28 2020] BTRFS info (device dm-0): found 19 extents, loops 29, stage: move data extents
	[Thu Nov 12 22:18:32 2020] BTRFS info (device dm-0): found 19 extents, loops 30, stage: move data extents
	[Thu Nov 12 22:18:38 2020] BTRFS info (device dm-0): found 19 extents, loops 31, stage: move data extents
	[Thu Nov 12 22:18:45 2020] BTRFS info (device dm-0): found 19 extents, loops 32, stage: move data extents
	[Thu Nov 12 22:18:49 2020] BTRFS info (device dm-0): found 19 extents, loops 33, stage: move data extents
	[Thu Nov 12 22:18:53 2020] BTRFS info (device dm-0): found 19 extents, loops 34, stage: move data extents
	[Thu Nov 12 22:18:59 2020] BTRFS info (device dm-0): found 19 extents, loops 35, stage: move data extents
	[Thu Nov 12 22:19:02 2020] BTRFS info (device dm-0): found 19 extents, loops 36, stage: move data extents
	[Thu Nov 12 22:19:06 2020] BTRFS info (device dm-0): found 19 extents, loops 37, stage: move data extents
	[Thu Nov 12 22:19:12 2020] BTRFS info (device dm-0): found 19 extents, loops 38, stage: move data extents
	[Thu Nov 12 22:19:15 2020] BTRFS info (device dm-0): found 19 extents, loops 39, stage: move data extents
	[Thu Nov 12 22:19:20 2020] BTRFS info (device dm-0): found 19 extents, loops 40, stage: move data extents
	[Thu Nov 12 22:19:23 2020] BTRFS info (device dm-0): found 19 extents, loops 41, stage: move data extents
	[Thu Nov 12 22:19:27 2020] BTRFS info (device dm-0): found 19 extents, loops 42, stage: move data extents
	[Thu Nov 12 22:19:31 2020] BTRFS info (device dm-0): found 19 extents, loops 43, stage: move data extents
	[Thu Nov 12 22:19:35 2020] BTRFS info (device dm-0): found 19 extents, loops 44, stage: move data extents
	[Thu Nov 12 22:19:38 2020] BTRFS info (device dm-0): found 19 extents, loops 45, stage: move data extents
	[Thu Nov 12 22:19:42 2020] BTRFS info (device dm-0): found 19 extents, loops 46, stage: move data extents
	[Thu Nov 12 22:19:46 2020] BTRFS info (device dm-0): found 19 extents, loops 47, stage: move data extents
	[Thu Nov 12 22:19:51 2020] BTRFS info (device dm-0): found 19 extents, loops 48, stage: move data extents
	[Thu Nov 12 22:19:54 2020] BTRFS info (device dm-0): found 19 extents, loops 49, stage: move data extents
	[Thu Nov 12 22:19:57 2020] BTRFS info (device dm-0): found 19 extents, loops 50, stage: move data extents
	[Thu Nov 12 22:19:58 2020] BTRFS info (device dm-0): found 19 extents, loops 51, stage: move data extents
	[Thu Nov 12 22:19:58 2020] BTRFS info (device dm-0): found 19 extents, loops 52, stage: move data extents
	[Thu Nov 12 22:20:02 2020] BTRFS info (device dm-0): found 19 extents, loops 53, stage: move data extents
	[Thu Nov 12 22:20:06 2020] BTRFS info (device dm-0): found 19 extents, loops 54, stage: move data extents
	[Thu Nov 12 22:20:10 2020] BTRFS info (device dm-0): found 19 extents, loops 55, stage: move data extents
	[Thu Nov 12 22:20:14 2020] BTRFS info (device dm-0): found 19 extents, loops 56, stage: move data extents
	[Thu Nov 12 22:20:26 2020] BTRFS info (device dm-0): found 19 extents, loops 57, stage: move data extents
	[Thu Nov 12 22:21:05 2020] BTRFS info (device dm-0): found 19 extents, loops 58, stage: move data extents
	[Thu Nov 12 22:21:16 2020] BTRFS info (device dm-0): found 19 extents, loops 59, stage: move data extents
	[Thu Nov 12 22:21:20 2020] BTRFS info (device dm-0): found 19 extents, loops 60, stage: move data extents
	[Thu Nov 12 22:21:25 2020] BTRFS info (device dm-0): found 19 extents, loops 61, stage: move data extents
	[Thu Nov 12 22:21:31 2020] BTRFS info (device dm-0): found 19 extents, loops 62, stage: move data extents
	[Thu Nov 12 22:21:37 2020] BTRFS info (device dm-0): found 19 extents, loops 63, stage: move data extents

The "loops N" is something I added for testing previous runaway balance
fixes as I got tired of counting them from scripts all the time.

The same for-next kernel without patches had been running for 48 hours
before this with no strange balance loop counts, so this looks like new
behavior from this patch series.

On a metadata block group the extent count does change over time:

	[Thu Nov 12 22:45:23 2020] BTRFS info (device dm-0): balance: start -mlimit=1 -slimit=1
	[Thu Nov 12 22:45:23 2020] BTRFS info (device dm-0): relocating block group 37252147183616 flags metadata|raid1
	[Thu Nov 12 22:45:31 2020] BTRFS info (device dm-0): found 21944 extents, loops 1, stage: move data extents
	[Thu Nov 12 22:45:51 2020] BTRFS info (device dm-0): found 21482 extents, loops 2, stage: move data extents
	[Thu Nov 12 22:46:00 2020] BTRFS info (device dm-0): found 20066 extents, loops 3, stage: move data extents
	[Thu Nov 12 22:46:02 2020] BTRFS info (device dm-0): found 20000 extents, loops 4, stage: move data extents
	[Thu Nov 12 22:46:06 2020] BTRFS info (device dm-0): found 19986 extents, loops 5, stage: move data extents
	[Thu Nov 12 22:46:08 2020] BTRFS info (device dm-0): found 19980 extents, loops 6, stage: move data extents
	[Thu Nov 12 22:46:12 2020] BTRFS info (device dm-0): found 19978 extents, loops 7, stage: move data extents
	[Thu Nov 12 22:46:15 2020] BTRFS info (device dm-0): found 19971 extents, loops 8, stage: move data extents
	[Thu Nov 12 22:46:18 2020] BTRFS info (device dm-0): found 19958 extents, loops 9, stage: move data extents
	[Thu Nov 12 22:46:21 2020] BTRFS info (device dm-0): found 19955 extents, loops 10, stage: move data extents
	[Thu Nov 12 22:46:24 2020] BTRFS info (device dm-0): found 19943 extents, loops 11, stage: move data extents
	[Thu Nov 12 22:46:27 2020] BTRFS info (device dm-0): found 19939 extents, loops 12, stage: move data extents
	[Thu Nov 12 22:46:30 2020] BTRFS info (device dm-0): found 19927 extents, loops 13, stage: move data extents
	[Thu Nov 12 22:46:33 2020] BTRFS info (device dm-0): found 19925 extents, loops 14, stage: move data extents
	[Thu Nov 12 22:46:48 2020] BTRFS info (device dm-0): found 19891 extents, loops 15, stage: move data extents
	[Thu Nov 12 22:47:06 2020] BTRFS info (device dm-0): found 19808 extents, loops 16, stage: move data extents
	[Thu Nov 12 22:47:10 2020] BTRFS info (device dm-0): found 19805 extents, loops 17, stage: move data extents
	[Thu Nov 12 22:47:13 2020] BTRFS info (device dm-0): found 19803 extents, loops 18, stage: move data extents
	[Thu Nov 12 22:47:15 2020] BTRFS info (device dm-0): found 19802 extents, loops 19, stage: move data extents
	[Thu Nov 12 22:47:18 2020] BTRFS info (device dm-0): found 19802 extents, loops 20, stage: move data extents
	[Thu Nov 12 22:47:21 2020] BTRFS info (device dm-0): found 19802 extents, loops 21, stage: move data extents
	[Thu Nov 12 22:47:24 2020] BTRFS info (device dm-0): found 19802 extents, loops 22, stage: move data extents
	[Thu Nov 12 22:47:28 2020] BTRFS info (device dm-0): found 19802 extents, loops 23, stage: move data extents
	[Thu Nov 12 22:47:30 2020] BTRFS info (device dm-0): found 19802 extents, loops 24, stage: move data extents
	[Thu Nov 12 22:47:34 2020] BTRFS info (device dm-0): found 19802 extents, loops 25, stage: move data extents
	[Thu Nov 12 22:47:36 2020] BTRFS info (device dm-0): found 19800 extents, loops 26, stage: move data extents
	[Thu Nov 12 22:47:40 2020] BTRFS info (device dm-0): found 19800 extents, loops 27, stage: move data extents
	[Thu Nov 12 22:47:43 2020] BTRFS info (device dm-0): found 19800 extents, loops 28, stage: move data extents
	[Thu Nov 12 22:47:56 2020] BTRFS info (device dm-0): found 19800 extents, loops 29, stage: move data extents
	[Thu Nov 12 22:48:10 2020] BTRFS info (device dm-0): found 19770 extents, loops 30, stage: move data extents
	[Thu Nov 12 22:48:15 2020] BTRFS info (device dm-0): found 19765 extents, loops 31, stage: move data extents
	[Thu Nov 12 22:48:17 2020] BTRFS info (device dm-0): found 19764 extents, loops 32, stage: move data extents
	[Thu Nov 12 22:48:19 2020] BTRFS info (device dm-0): found 19764 extents, loops 33, stage: move data extents
	[Thu Nov 12 22:48:23 2020] BTRFS info (device dm-0): found 19764 extents, loops 34, stage: move data extents
	[Thu Nov 12 22:48:25 2020] BTRFS info (device dm-0): found 19764 extents, loops 35, stage: move data extents
	[Thu Nov 12 22:48:29 2020] BTRFS info (device dm-0): found 19764 extents, loops 36, stage: move data extents
	[Thu Nov 12 22:48:32 2020] BTRFS info (device dm-0): found 19763 extents, loops 37, stage: move data extents
	[Thu Nov 12 22:48:35 2020] BTRFS info (device dm-0): found 19763 extents, loops 38, stage: move data extents
	[Thu Nov 12 22:48:38 2020] BTRFS info (device dm-0): found 19763 extents, loops 39, stage: move data extents
	[Thu Nov 12 22:48:41 2020] BTRFS info (device dm-0): found 19763 extents, loops 40, stage: move data extents
	[Thu Nov 12 22:48:44 2020] BTRFS info (device dm-0): found 19763 extents, loops 41, stage: move data extents

> Josef
> 
> Josef Bacik (42):
>   btrfs: allow error injection for btrfs_search_slot and btrfs_cow_block
>   btrfs: fix lockdep splat in btrfs_recover_relocation
>   btrfs: convert some BUG_ON()'s to ASSERT()'s in do_relocation
>   btrfs: convert BUG_ON()'s in relocate_tree_block
>   btrfs: return an error from btrfs_record_root_in_trans
>   btrfs: handle errors from select_reloc_root()
>   btrfs: convert BUG_ON()'s in select_reloc_root() to proper errors
>   btrfs: check record_root_in_trans related failures in
>     select_reloc_root
>   btrfs: do proper error handling in record_reloc_root_in_trans
>   btrfs: handle btrfs_record_root_in_trans failure in
>     btrfs_rename_exchange
>   btrfs: handle btrfs_record_root_in_trans failure in btrfs_rename
>   btrfs: handle btrfs_record_root_in_trans failure in
>     btrfs_delete_subvolume
>   btrfs: handle btrfs_record_root_in_trans failure in
>     btrfs_recover_log_trees
>   btrfs: handle btrfs_record_root_in_trans failure in create_subvol
>   btrfs: btrfs: handle btrfs_record_root_in_trans failure in
>     relocate_tree_block
>   btrfs: handle btrfs_record_root_in_trans failure in start_transaction
>   btrfs: handle record_root_in_trans failure in qgroup_account_snapshot
>   btrfs: handle record_root_in_trans failure in
>     btrfs_record_root_in_trans
>   btrfs: handle record_root_in_trans failure in create_pending_snapshot
>   btrfs: do not panic in __add_reloc_root
>   btrfs: have proper error handling in btrfs_init_reloc_root
>   btrfs: do proper error handling in create_reloc_root
>   btrfs: handle btrfs_update_reloc_root failure in commit_fs_roots
>   btrfs: change insert_dirty_subvol to return errors
>   btrfs: handle btrfs_update_reloc_root failure in insert_dirty_subvol
>   btrfs: handle btrfs_update_reloc_root failure in prepare_to_merge
>   btrfs: do proper error handling in btrfs_update_reloc_root
>   btrfs: convert logic BUG_ON()'s in replace_path to ASSERT()'s
>   btrfs: handle initial btrfs_cow_block error in replace_path
>   btrfs: handle the loop btrfs_cow_block error in replace_path
>   btrfs: handle btrfs_search_slot failure in replace_path
>   btrfs: handle errors in reference count manipulation in replace_path
>   btrfs: handle extent reference errors in do_relocation
>   btrfs: check for BTRFS_BLOCK_FLAG_FULL_BACKREF being set improperly
>   btrfs: remove the extent item sanity checks in relocate_block_group
>   btrfs: do proper error handling in create_reloc_inode
>   btrfs: handle __add_reloc_root failure in btrfs_recover_relocation
>   btrfs: handle __add_reloc_root failure in btrfs_reloc_post_snapshot
>   btrfs: cleanup error handling in prepare_to_merge
>   btrfs: handle extent corruption with select_one_root properly
>   btrfs: do proper error handling in merge_reloc_roots
>   btrfs: check return value of btrfs_commit_transaction in relocation
> 
>  fs/btrfs/ctree.c        |   2 +
>  fs/btrfs/inode.c        |  21 ++-
>  fs/btrfs/ioctl.c        |   6 +-
>  fs/btrfs/relocation.c   | 372 ++++++++++++++++++++++++++++++----------
>  fs/btrfs/transaction.c  |  37 ++--
>  fs/btrfs/tree-checker.c |   5 +
>  fs/btrfs/tree-log.c     |   8 +-
>  fs/btrfs/volumes.c      |   2 +
>  8 files changed, 342 insertions(+), 111 deletions(-)
> 
> -- 
> 2.26.2
> 

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 00/42] Cleanup error handling in relocation
  2020-11-13  3:53 ` [PATCH 00/42] Cleanup error handling " Zygo Blaxell
@ 2020-11-13 11:03   ` Josef Bacik
  2020-11-13 14:39     ` Zygo Blaxell
  0 siblings, 1 reply; 49+ messages in thread
From: Josef Bacik @ 2020-11-13 11:03 UTC (permalink / raw)
  To: Zygo Blaxell; +Cc: linux-btrfs, kernel-team

On 11/12/20 10:53 PM, Zygo Blaxell wrote:
> On Thu, Nov 12, 2020 at 04:18:27PM -0500, Josef Bacik wrote:
>> Hello,
>>
>> Relocation is the last place that is not able to handle errors at all, which
>> results in all sorts of lovely panics if you encounter corruptions or IO errors.
>> I'm going to start cleaning up relocation, but before I move code around I want
>> the error handling to be somewhat sane, so I'm not changing behavior and error
>> handling at the same time.
>>
>> These patches are purely about error handling, there is no behavior changing
>> other than returning errors up the chain properly.  There is a lot of room for
>> follow up cleanups, which will happen next.  However I wanted to get this series
>> done today and out so we could get it merged ASAP, and then the follow up
>> cleanups can happen later as they are less important and less critical.
>>
>> The only exception to the above is the patch to add the error injection sites
>> for btrfs_cow_block and btrfs_search_slot, and a lockdep fix that I discovered
>> while running my tests, those are the first two patches in the series.
>>
>> I tested this with my error injection stress test, where I keep track of all
>> stack traces that have been tested and only inject errors when we have a new
>> stack trace, which means I should have covered all of the various error
>> conditions.  With this patchset I'm no longer panicing while stressing the error
>> conditions.  Thanks,
> 
> I just threw this patch set on top of kdave/for-next
> (a12315094469d573e41fe3eee91c99a83cec02df) and I got something that
> looks like runaway balances:
> 

Yup I hit this with my xfstests run that I started after I sent these 
out, I got a little happy with deleting things for one of the patches, 
this time I'm running xfstests _before_ I send the next version.  Thanks,

Josef

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 01/42] btrfs: allow error injection for btrfs_search_slot and btrfs_cow_block
  2020-11-13  0:02   ` Qu Wenruo
@ 2020-11-13 11:05     ` Josef Bacik
  0 siblings, 0 replies; 49+ messages in thread
From: Josef Bacik @ 2020-11-13 11:05 UTC (permalink / raw)
  To: Qu Wenruo, linux-btrfs, kernel-team

On 11/12/20 7:02 PM, Qu Wenruo wrote:
> 
> 
> On 2020/11/13 上午5:18, Josef Bacik wrote:
>> The following patches are going to address error handling in relocation,
>> in order to test those patches I need to be able to inject errors in
>> btrfs_search_slot and btrfs_cow_block, as we call both of these pretty
>> often in different cases during relocation.
>>
>> Signed-off-by: Josef Bacik <josef@toxicpanda.com>
>> ---
>>   fs/btrfs/ctree.c | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c
>> index d2d5854d51a7..a51e761bf00f 100644
>> --- a/fs/btrfs/ctree.c
>> +++ b/fs/btrfs/ctree.c
>> @@ -1493,6 +1493,7 @@ noinline int btrfs_cow_block(struct btrfs_trans_handle *trans,
>>   
>>   	return ret;
>>   }
>> +ALLOW_ERROR_INJECTION(btrfs_cow_block, ERRNO);
>>   
>>   /*
>>    * helper function for defrag to decide if two blocks pointed to by a
>> @@ -2870,6 +2871,7 @@ int btrfs_search_slot(struct btrfs_trans_handle *trans, struct btrfs_root *root,
>>   		btrfs_release_path(p);
>>   	return ret;
>>   }
>> +ALLOW_ERROR_INJECTION(btrfs_search_slot, ERRNO);
> 
> This concerns me a little.
> 
> For error case, wouldn't we also free the path?
> But if we just override the error, the path is not freed by anyone,
> neither caller nor btrfs_search_slot() would free the path.
> 
> Or did I miss something?
> 

You're missing that the caller is responsible for free'ing the path, 
failing btrfs_search_slot isn't going to leak anything unless there's a 
bug with the caller.  Thanks,

Josef

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 00/42] Cleanup error handling in relocation
  2020-11-13 11:03   ` Josef Bacik
@ 2020-11-13 14:39     ` Zygo Blaxell
  2020-11-15  0:37       ` Zygo Blaxell
  0 siblings, 1 reply; 49+ messages in thread
From: Zygo Blaxell @ 2020-11-13 14:39 UTC (permalink / raw)
  To: Josef Bacik; +Cc: linux-btrfs, kernel-team

On Fri, Nov 13, 2020 at 06:03:39AM -0500, Josef Bacik wrote:
> On 11/12/20 10:53 PM, Zygo Blaxell wrote:
> > On Thu, Nov 12, 2020 at 04:18:27PM -0500, Josef Bacik wrote:
> > > Hello,
> > > 
> > > Relocation is the last place that is not able to handle errors at all, which
> > > results in all sorts of lovely panics if you encounter corruptions or IO errors.
> > > I'm going to start cleaning up relocation, but before I move code around I want
> > > the error handling to be somewhat sane, so I'm not changing behavior and error
> > > handling at the same time.
> > > 
> > > These patches are purely about error handling, there is no behavior changing
> > > other than returning errors up the chain properly.  There is a lot of room for
> > > follow up cleanups, which will happen next.  However I wanted to get this series
> > > done today and out so we could get it merged ASAP, and then the follow up
> > > cleanups can happen later as they are less important and less critical.
> > > 
> > > The only exception to the above is the patch to add the error injection sites
> > > for btrfs_cow_block and btrfs_search_slot, and a lockdep fix that I discovered
> > > while running my tests, those are the first two patches in the series.
> > > 
> > > I tested this with my error injection stress test, where I keep track of all
> > > stack traces that have been tested and only inject errors when we have a new
> > > stack trace, which means I should have covered all of the various error
> > > conditions.  With this patchset I'm no longer panicing while stressing the error
> > > conditions.  Thanks,
> > 
> > I just threw this patch set on top of kdave/for-next
> > (a12315094469d573e41fe3eee91c99a83cec02df) and I got something that
> > looks like runaway balances:
> > 
> 
> Yup I hit this with my xfstests run that I started after I sent these out, I
> got a little happy with deleting things for one of the patches, this time
> I'm running xfstests _before_ I send the next version.  Thanks,

Well, the good news is you killed the BUG_ON I was hitting every few hours
while running a test that sends a SIGINT to balance:

	https://lore.kernel.org/linux-btrfs/20200904155359.GC5890@hungrycats.org/

so I'm looking forward to the next version.

> Josef

^ permalink raw reply	[flat|nested] 49+ messages in thread

* Re: [PATCH 00/42] Cleanup error handling in relocation
  2020-11-13 14:39     ` Zygo Blaxell
@ 2020-11-15  0:37       ` Zygo Blaxell
  0 siblings, 0 replies; 49+ messages in thread
From: Zygo Blaxell @ 2020-11-15  0:37 UTC (permalink / raw)
  To: Josef Bacik; +Cc: linux-btrfs, kernel-team

On Fri, Nov 13, 2020 at 09:39:26AM -0500, Zygo Blaxell wrote:
> On Fri, Nov 13, 2020 at 06:03:39AM -0500, Josef Bacik wrote:
> > On 11/12/20 10:53 PM, Zygo Blaxell wrote:
> > > On Thu, Nov 12, 2020 at 04:18:27PM -0500, Josef Bacik wrote:
> > > > Hello,
> > > > 
> > > > Relocation is the last place that is not able to handle errors at all, which
> > > > results in all sorts of lovely panics if you encounter corruptions or IO errors.
> > > > I'm going to start cleaning up relocation, but before I move code around I want
> > > > the error handling to be somewhat sane, so I'm not changing behavior and error
> > > > handling at the same time.
> > > > 
> > > > These patches are purely about error handling, there is no behavior changing
> > > > other than returning errors up the chain properly.  There is a lot of room for
> > > > follow up cleanups, which will happen next.  However I wanted to get this series
> > > > done today and out so we could get it merged ASAP, and then the follow up
> > > > cleanups can happen later as they are less important and less critical.
> > > > 
> > > > The only exception to the above is the patch to add the error injection sites
> > > > for btrfs_cow_block and btrfs_search_slot, and a lockdep fix that I discovered
> > > > while running my tests, those are the first two patches in the series.
> > > > 
> > > > I tested this with my error injection stress test, where I keep track of all
> > > > stack traces that have been tested and only inject errors when we have a new
> > > > stack trace, which means I should have covered all of the various error
> > > > conditions.  With this patchset I'm no longer panicing while stressing the error
> > > > conditions.  Thanks,
> > > 
> > > I just threw this patch set on top of kdave/for-next
> > > (a12315094469d573e41fe3eee91c99a83cec02df) and I got something that
> > > looks like runaway balances:
> > > 
> > 
> > Yup I hit this with my xfstests run that I started after I sent these out, I
> > got a little happy with deleting things for one of the patches, this time
> > I'm running xfstests _before_ I send the next version.  Thanks,
> 
> Well, the good news is you killed the BUG_ON I was hitting every few hours
> while running a test that sends a SIGINT to balance:
> 
> 	https://lore.kernel.org/linux-btrfs/20200904155359.GC5890@hungrycats.org/
> 
> so I'm looking forward to the next version.

OK, I've run the next version, and...the SIGINT test is still failing,
just not in the original place, because the original place doesn't exist
any more.

This happened once:

	[48401.882283][T11825] BTRFS info (device dm-0): balance: start -mlimit=1 -slimit=1
	[48401.889294][T11825] BTRFS info (device dm-0): relocating block group 37267716440064 flags metadata|raid1
	[48423.523596][T11825] BTRFS info (device dm-0): balance: canceled
	[48553.928742][ T1426] BTRFS info (device dm-0): balance: start -mlimit=1 -slimit=1
	[48553.952356][ T1426] BTRFS info (device dm-0): relocating block group 37267716440064 flags metadata|raid1
	[48626.179977][ T4548] avg_delayed_ref_runtime = 5084522, time = 780837759114, count = 153571
	[48639.557809][ T1426] ==================================================================
	[48639.559006][ T1426] BUG: KASAN: null-ptr-deref in select_reloc_root+0x1b0/0x6a0
	[48639.560146][ T1426] Read of size 8 at addr 0000000000000000 by task btrfs/1426
	[48639.561274][ T1426] 
	[48639.561618][ T1426] CPU: 1 PID: 1426 Comm: btrfs Tainted: G        W         5.10.0-87fa69f8a71b-for-next+ #14
	[48639.563076][ T1426] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
	[48639.564382][ T1426] Call Trace:
	[48639.564909][ T1426]  dump_stack+0xbc/0xf9
	[48639.565504][ T1426]  ? select_reloc_root+0x1b0/0x6a0
	[48639.566238][ T1426]  ? select_reloc_root+0x1b0/0x6a0
	[48639.566980][ T1426]  kasan_report.cold.10+0x5/0x37
	[48639.567685][ T1426]  ? select_reloc_root+0x1b0/0x6a0
	[48639.568599][ T1426]  __asan_load8+0x69/0x90
	[48639.569481][ T1426]  select_reloc_root+0x1b0/0x6a0
	[48639.570199][ T1426]  ? __kasan_slab_free+0xf3/0x140
	[48639.570926][ T1426]  ? relocate_data_extent+0x1a0/0x1a0
	[48639.571710][ T1426]  ? btrfs_ioctl+0x24c8/0x4380
	[48639.572400][ T1426]  ? do_syscall_64+0x37/0x80
	[48639.573062][ T1426]  ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
	[48639.573934][ T1426]  ? entry_SYSCALL_64_after_hwframe+0x44/0xa9
	[48639.574953][ T1426]  ? free_extent_buffer.part.52+0xb1/0x140
	[48639.575786][ T1426]  ? do_raw_spin_unlock+0xa8/0x140
	[48639.576528][ T1426]  do_relocation+0x23c/0xc10
	[48639.577187][ T1426]  ? free_extent_buffer.part.52+0xd7/0x140
	[48639.578020][ T1426]  ? __list_add_valid+0x33/0x70
	[48639.578711][ T1426]  ? select_reloc_root+0x6a0/0x6a0
	[48639.579441][ T1426]  ? btrfs_backref_finish_upper_links+0x419/0x7d0
	[48639.580358][ T1426]  ? walk_up_backref+0x91/0xd0
	[48639.581039][ T1426]  ? __asan_loadN+0xf/0x20
	[48639.581664][ T1426]  ? select_one_root+0x11d/0x2d0
	[48639.582373][ T1426]  ? lock_downgrade+0x3f0/0x3f0
	[48639.583068][ T1426]  ? do_raw_spin_unlock+0xa8/0x140
	[48639.583802][ T1426]  ? _raw_spin_unlock+0x22/0x30
	[48639.584503][ T1426]  ? btrfs_block_rsv_refill+0x50/0xa0
	[48639.585280][ T1426]  relocate_tree_blocks+0x853/0xb60
	[48639.586030][ T1426]  ? do_relocation+0xc10/0xc10
	[48639.586709][ T1426]  ? kasan_kmalloc+0x9/0x10
	[48639.587356][ T1426]  ? kmem_cache_alloc_trace+0x6a3/0xcb0
	[48639.588147][ T1426]  ? free_extent_buffer.part.52+0xd7/0x140
	[48639.588983][ T1426]  ? rb_insert_color+0x342/0x360
	[48639.589687][ T1426]  ? add_tree_block.isra.36+0x236/0x2b0
	[48639.590478][ T1426]  relocate_block_group+0x2eb/0x780
	[48639.591223][ T1426]  ? merge_reloc_roots+0x470/0x470
	[48639.591972][ T1426]  btrfs_relocate_block_group+0x26e/0x4c0
	[48639.592945][ T1426]  btrfs_relocate_chunk+0x52/0x120
	[48639.593668][ T1426]  btrfs_balance+0xe2e/0x18f0
	[48639.594311][ T1426]  ? __kasan_check_read+0x11/0x20
	[48639.594962][ T1426]  ? lock_acquire+0xd0/0x550
	[48639.595597][ T1426]  ? btrfs_relocate_chunk+0x120/0x120
	[48639.596372][ T1426]  ? kasan_unpoison_task_stack+0xf/0x20
	[48639.597168][ T1426]  ? kmem_cache_alloc_trace+0x6a3/0xcb0
	[48639.597969][ T1426]  ? _copy_from_user+0x83/0xc0
	[48639.598648][ T1426]  btrfs_ioctl_balance+0x3a7/0x460
	[48639.599383][ T1426]  btrfs_ioctl+0x24c8/0x4380
	[48639.600060][ T1426]  ? __kasan_check_read+0x11/0x20
	[48639.600769][ T1426]  ? lock_release+0xc8/0x640
	[48639.601429][ T1426]  ? lru_cache_add+0x178/0x250
	[48639.602102][ T1426]  ? btrfs_ioctl_get_supported_features+0x30/0x30
	[48639.603004][ T1426]  ? lock_downgrade+0x3f0/0x3f0
	[48639.603681][ T1426]  ? handle_mm_fault+0x159e/0x2150
	[48639.604408][ T1426]  ? __kasan_check_read+0x11/0x20
	[48639.605108][ T1426]  ? lock_release+0xc8/0x640
	[48639.605750][ T1426]  ? do_user_addr_fault+0x299/0x5a0
	[48639.606481][ T1426]  ? do_raw_spin_unlock+0xa8/0x140
	[48639.607198][ T1426]  ? lock_downgrade+0x3f0/0x3f0
	[48639.607880][ T1426]  ? _raw_spin_unlock+0x22/0x30
	[48639.608557][ T1426]  ? handle_mm_fault+0xad6/0x2150
	[48639.609262][ T1426]  ? do_vfs_ioctl+0xfc/0x9d0
	[48639.609907][ T1426]  ? ioctl_file_clone+0xe0/0xe0
	[48639.610584][ T1426]  ? __kasan_check_write+0x14/0x20
	[48639.611301][ T1426]  ? up_read+0x176/0x4f0
	[48639.611901][ T1426]  ? down_write_nested+0x2d0/0x2d0
	[48639.612612][ T1426]  ? vmacache_find+0xc9/0x120
	[48639.613274][ T1426]  ? __kasan_check_read+0x11/0x20
	[48639.613977][ T1426]  ? __fget_light+0xae/0x110
	[48639.614620][ T1426]  __x64_sys_ioctl+0xc3/0x100
	[48639.615280][ T1426]  do_syscall_64+0x37/0x80
	[48639.615905][ T1426]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
	[48639.616726][ T1426] RIP: 0033:0x7ffb3753c427
	[48639.617349][ T1426] Code: 00 00 90 48 8b 05 69 aa 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 39 aa 0c 00 f7 d8 64 89 01 48
	[48639.620089][ T1426] RSP: 002b:00007ffddaf08558 EFLAGS: 00000202 ORIG_RAX: 0000000000000010
	[48639.621268][ T1426] RAX: ffffffffffffffda RBX: 00007ffddaf085f8 RCX: 00007ffb3753c427
	[48639.622380][ T1426] RDX: 00007ffddaf085f8 RSI: 00000000c4009420 RDI: 0000000000000003
	[48639.623492][ T1426] RBP: 0000000000000003 R08: 0000000000000003 R09: 0000000000000078
	[48639.624606][ T1426] R10: fffffffffffff59d R11: 0000000000000202 R12: 0000000000000001
	[48639.625719][ T1426] R13: 0000000000000000 R14: 00007ffddaf09a34 R15: 0000000000000001
[48639.626841][ T1426] ==================================================================

	(gdb) list *(select_reloc_root+0x1b0)
	0xffffffff8194db20 is in select_reloc_root (fs/btrfs/relocation.c:2145).
	2140                    ret = btrfs_record_root_in_trans(trans, root);
	2141                    if (ret)
	2142                            return ERR_PTR(ret);
	2143                    root = root->reloc_root;
	2144
	2145                    if (next->new_bytenr != root->node->start) {
	2146                            /*
	2147                             * We just created the reloc root, so we shouldn't have
	2148                             * ->new_bytenr set and this shouldn't be in the changed
	2149                             *  list.  If it is then we have multiple roots pointing

The following sequence has happened 3 times since yesterday:

	[ 3252.939619][ T8472] BTRFS info (device dm-0): balance: resume -musage=90,limit=1 -susage=90,limit=1
	[ 3253.962086][ T8472] BTRFS info (device dm-0): relocating block group 37252147183616 flags metadata|raid1
	[ 3279.938601][ T8472] 
	[ 3279.938977][ T8472] ======================================================
	[ 3279.939993][ T8472] WARNING: possible circular locking dependency detected
	[ 3279.941020][ T8472] 5.10.0-87fa69f8a71b-for-next+ #14 Tainted: G        W        
	[ 3279.942201][ T8472] ------------------------------------------------------
	[ 3279.943481][ T8472] btrfs/8472 is trying to acquire lock:
	[ 3279.944615][ T8472] ffff888040a3ba28 (btrfs-tree-00){++++}-{3:3}, at: __btrfs_tree_lock+0x29/0x190
	[ 3279.946631][ T8472] 
	[ 3279.946631][ T8472] but task is already holding lock:
	[ 3279.947819][ T8472] ffff88812c69eeb8 (btrfs-extent-01){++++}-{3:3}, at: __btrfs_tree_read_lock+0x49/0x240
	[ 3279.949266][ T8472] 
	[ 3279.949266][ T8472] which lock already depends on the new lock.
	[ 3279.949266][ T8472] 
	[ 3279.950909][ T8472] 
	[ 3279.950909][ T8472] the existing dependency chain (in reverse order) is:
	[ 3279.952357][ T8472] 
	[ 3279.952357][ T8472] -> #1 (btrfs-extent-01){++++}-{3:3}:
	[ 3279.953462][ T8472]        lock_release+0x28c/0x640
	[ 3279.954184][ T8472]        up_read+0x7d/0x4f0
	[ 3279.954833][ T8472]        btrfs_tree_read_unlock+0xbc/0x1b0
	[ 3279.955861][ T8472]        btrfs_search_slot+0xd84/0xfb0
	[ 3279.956639][ T8472]        btrfs_lookup_extent_info+0x165/0x5b0
	[ 3279.957508][ T8472]        do_walk_down+0x29c/0xc00
	[ 3279.958230][ T8472]        walk_down_tree+0x1af/0x210
	[ 3279.958973][ T8472]        btrfs_drop_snapshot+0x44f/0xda0
	[ 3279.959779][ T8472]        clean_dirty_subvols+0x1bd/0x220
	[ 3279.960592][ T8472]        btrfs_recover_relocation+0x60d/0x940
	[ 3279.961464][ T8472]        btrfs_mount_rw+0x12e/0x200
	[ 3279.962236][ T8472]        open_ctree+0x2149/0x2507
	[ 3279.962986][ T8472]        btrfs_mount_root.cold.74+0xe/0xea
	[ 3279.963816][ T8472]        legacy_get_tree+0x89/0xd0
	[ 3279.964547][ T8472]        vfs_get_tree+0x52/0x150
	[ 3279.965257][ T8472]        fc_mount+0x14/0x60
	[ 3279.965903][ T8472]        vfs_kern_mount.part.38+0x61/0xa0
	[ 3279.966717][ T8472]        vfs_kern_mount+0x13/0x20
	[ 3279.967435][ T8472]        btrfs_mount+0x1f0/0x5d0
	[ 3279.968147][ T8472]        legacy_get_tree+0x89/0xd0
	[ 3279.968938][ T8472]        vfs_get_tree+0x52/0x150
	[ 3279.969652][ T8472]        path_mount+0xa53/0xf00
	[ 3279.970411][ T8472]        do_mount+0xd2/0xf0
	[ 3279.971063][ T8472]        __x64_sys_mount+0x100/0x120
	[ 3279.971833][ T8472]        do_syscall_64+0x37/0x80
	[ 3279.972586][ T8472]        entry_SYSCALL_64_after_hwframe+0x44/0xa9
	[ 3279.973564][ T8472] 
	[ 3279.973564][ T8472] -> #0 (btrfs-tree-00){++++}-{3:3}:
	[ 3279.974673][ T8472]        __lock_acquire+0x1dce/0x28a0
	[ 3279.975509][ T8472]        lock_acquire+0x192/0x550
	[ 3279.976287][ T8472]        down_write_nested+0xa6/0x2d0
	[ 3279.977131][ T8472]        __btrfs_tree_lock+0x29/0x190
	[ 3279.977972][ T8472]        btrfs_tree_lock+0x10/0x20
	[ 3279.978764][ T8472]        btrfs_search_slot+0x462/0xfb0
	[ 3279.979614][ T8472]        relocate_tree_blocks+0x8cd/0xb60
	[ 3279.980506][ T8472]        relocate_block_group+0x2eb/0x780
	[ 3279.981368][ T8472]        btrfs_relocate_block_group+0x26e/0x4c0
	[ 3279.982285][ T8472]        btrfs_relocate_chunk+0x52/0x120
	[ 3279.983093][ T8472]        btrfs_balance+0xe2e/0x18f0
	[ 3279.983924][ T8472]        btrfs_ioctl_balance+0x1f9/0x460
	[ 3279.984729][ T8472]        btrfs_ioctl+0x24c8/0x4380
	[ 3279.985472][ T8472]        __x64_sys_ioctl+0xc3/0x100
	[ 3279.986327][ T8472]        do_syscall_64+0x37/0x80
	[ 3279.987058][ T8472]        entry_SYSCALL_64_after_hwframe+0x44/0xa9
	[ 3279.987999][ T8472] 
	[ 3279.987999][ T8472] other info that might help us debug this:
	[ 3279.987999][ T8472] 
	[ 3279.989509][ T8472]  Possible unsafe locking scenario:
	[ 3279.989509][ T8472] 
	[ 3279.990577][ T8472]        CPU0                    CPU1
	[ 3279.991346][ T8472]        ----                    ----
	[ 3279.992116][ T8472]   lock(btrfs-extent-01);
	[ 3279.992751][ T8472]                                lock(btrfs-tree-00);
	[ 3279.993722][ T8472]                                lock(btrfs-extent-01);
	[ 3279.994718][ T8472]   lock(btrfs-tree-00);
	[ 3279.995333][ T8472] 
	[ 3279.995333][ T8472]  *** DEADLOCK ***
	[ 3279.995333][ T8472] 
	[ 3279.996497][ T8472] 5 locks held by btrfs/8472:
	[ 3279.997172][ T8472]  #0: ffff888113010498 (sb_writers#13){.+.+}-{0:0}, at: mnt_want_write_file+0x43/0x90
	[ 3279.998557][ T8472]  #1: ffff888106cc2318 (&fs_info->delete_unused_bgs_mutex){+.+.}-{3:3}, at: btrfs_balance+0xa54/0x18f0
	[ 3280.000165][ T8472]  #2: ffff888106cc08f0 (&fs_info->cleaner_mutex){+.+.}-{3:3}, at: btrfs_relocate_block_group+0x266/0x4c0
	[ 3280.001823][ T8472]  #3: ffff8881130106b8 (sb_internal#2){.+.+}-{0:0}, at: start_transaction+0x6a3/0x910
	[ 3280.003355][ T8472]  #4: ffff88812c69eeb8 (btrfs-extent-01){++++}-{3:3}, at: __btrfs_tree_read_lock+0x49/0x240
	[ 3280.004829][ T8472] 
	[ 3280.004829][ T8472] stack backtrace:
	[ 3280.005671][ T8472] CPU: 3 PID: 8472 Comm: btrfs Tainted: G        W         5.10.0-87fa69f8a71b-for-next+ #14
	[ 3280.007129][ T8472] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
	[ 3280.008438][ T8472] Call Trace:
	[ 3280.008915][ T8472]  dump_stack+0xbc/0xf9
	[ 3280.009562][ T8472]  print_circular_bug.isra.42.cold.67+0x146/0x14b
	[ 3280.010491][ T8472]  check_noncircular+0x219/0x250
	[ 3280.011207][ T8472]  ? print_circular_bug.isra.42+0x1c0/0x1c0
	[ 3280.012059][ T8472]  ? pvclock_clocksource_read+0xeb/0x190
	[ 3280.012873][ T8472]  ? __kasan_check_write+0x14/0x20
	[ 3280.013606][ T8472]  ? lockdep_lock+0xa7/0x160
	[ 3280.014269][ T8472]  __lock_acquire+0x1dce/0x28a0
	[ 3280.014973][ T8472]  ? register_lock_class+0x8f0/0x8f0
	[ 3280.015734][ T8472]  ? rcu_read_lock_sched_held+0xa1/0xd0
	[ 3280.016535][ T8472]  ? rcu_read_lock_bh_held+0xb0/0xb0
	[ 3280.017300][ T8472]  lock_acquire+0x192/0x550
	[ 3280.017950][ T8472]  ? __btrfs_tree_lock+0x29/0x190
	[ 3280.018725][ T8472]  ? check_flags+0x30/0x30
	[ 3280.019366][ T8472]  ? ___might_sleep+0x10f/0x1e0
	[ 3280.020062][ T8472]  ? __might_sleep+0x71/0xe0
	[ 3280.020716][ T8472]  down_write_nested+0xa6/0x2d0
	[ 3280.021413][ T8472]  ? __btrfs_tree_lock+0x29/0x190
	[ 3280.022135][ T8472]  ? _down_write_nest_lock+0x2c0/0x2c0
	[ 3280.022911][ T8472]  ? balance_node_right+0x3c0/0x3c0
	[ 3280.023649][ T8472]  ? rcu_read_lock_bh_held+0x70/0xb0
	[ 3280.024402][ T8472]  ? rcu_read_lock_bh_held+0xb0/0xb0
	[ 3280.025157][ T8472]  __btrfs_tree_lock+0x29/0x190
	[ 3280.025852][ T8472]  btrfs_tree_lock+0x10/0x20
	[ 3280.026524][ T8472]  btrfs_search_slot+0x462/0xfb0
	[ 3280.027261][ T8472]  ? split_leaf+0x9a0/0x9a0
	[ 3280.027941][ T8472]  ? walk_up_backref+0xd0/0xd0
	[ 3280.028652][ T8472]  ? do_raw_spin_lock+0x1e0/0x1e0
	[ 3280.029445][ T8472]  ? do_raw_spin_unlock+0xa8/0x140
	[ 3280.030222][ T8472]  ? _raw_spin_unlock+0x22/0x30
	[ 3280.030960][ T8472]  ? btrfs_block_rsv_refill+0x50/0xa0
	[ 3280.031772][ T8472]  relocate_tree_blocks+0x8cd/0xb60
	[ 3280.032567][ T8472]  ? do_relocation+0xc10/0xc10
	[ 3280.033294][ T8472]  ? kmem_cache_alloc_trace+0xa06/0xcb0
	[ 3280.034144][ T8472]  ? free_extent_buffer.part.52+0xd7/0x140
	[ 3280.035039][ T8472]  ? rb_insert_color+0x342/0x360
	[ 3280.035842][ T8472]  ? add_tree_block.isra.36+0x236/0x2b0
	[ 3280.036707][ T8472]  relocate_block_group+0x2eb/0x780
	[ 3280.037544][ T8472]  ? merge_reloc_roots+0x470/0x470
	[ 3280.038371][ T8472]  btrfs_relocate_block_group+0x26e/0x4c0
	[ 3280.039289][ T8472]  btrfs_relocate_chunk+0x52/0x120
	[ 3280.040114][ T8472]  btrfs_balance+0xe2e/0x18f0
	[ 3280.040867][ T8472]  ? pvclock_clocksource_read+0xeb/0x190
	[ 3280.041775][ T8472]  ? btrfs_relocate_chunk+0x120/0x120
	[ 3280.042655][ T8472]  ? lock_contended+0x620/0x6e0
	[ 3280.043490][ T8472]  ? do_raw_spin_lock+0x1e0/0x1e0
	[ 3280.044303][ T8472]  ? do_raw_spin_unlock+0xa8/0x140
	[ 3280.045051][ T8472]  btrfs_ioctl_balance+0x1f9/0x460
	[ 3280.045980][ T8472]  btrfs_ioctl+0x24c8/0x4380
	[ 3280.047029][ T8472]  ? __kasan_check_read+0x11/0x20
	[ 3280.047851][ T8472]  ? check_chain_key+0x1f4/0x2f0
	[ 3280.048644][ T8472]  ? __asan_loadN+0xf/0x20
	[ 3280.049360][ T8472]  ? btrfs_ioctl_get_supported_features+0x30/0x30
	[ 3280.050469][ T8472]  ? kvm_sched_clock_read+0x18/0x30
	[ 3280.051598][ T8472]  ? check_chain_key+0x1f4/0x2f0
	[ 3280.052378][ T8472]  ? lock_downgrade+0x3f0/0x3f0
	[ 3280.053141][ T8472]  ? handle_mm_fault+0xad6/0x2150
	[ 3280.053934][ T8472]  ? do_vfs_ioctl+0xfc/0x9d0
	[ 3280.054654][ T8472]  ? ioctl_file_clone+0xe0/0xe0
	[ 3280.055421][ T8472]  ? check_flags.part.50+0x6c/0x1e0
	[ 3280.056240][ T8472]  ? check_flags.part.50+0x6c/0x1e0
	[ 3280.057060][ T8472]  ? check_flags+0x26/0x30
	[ 3280.057749][ T8472]  ? lock_is_held_type+0xc3/0xf0
	[ 3280.058573][ T8472]  ? syscall_enter_from_user_mode+0x1b/0x60
	[ 3280.059553][ T8472]  ? do_syscall_64+0x13/0x80
	[ 3280.060294][ T8472]  ? rcu_read_lock_sched_held+0xa1/0xd0
	[ 3280.061149][ T8472]  ? __kasan_check_read+0x11/0x20
	[ 3280.061924][ T8472]  ? __fget_light+0xae/0x110
	[ 3280.062631][ T8472]  __x64_sys_ioctl+0xc3/0x100
	[ 3280.063352][ T8472]  do_syscall_64+0x37/0x80
	[ 3280.064036][ T8472]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
	[ 3280.064941][ T8472] RIP: 0033:0x7f18ca415427
	[ 3280.065619][ T8472] Code: 00 00 90 48 8b 05 69 aa 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 39 aa 0c 00 f7 d8 64 89 01 48
	[ 3280.068691][ T8472] RSP: 002b:00007ffcd1fed6b8 EFLAGS: 00000206 ORIG_RAX: 0000000000000010
	[ 3280.070070][ T8472] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f18ca415427
	[ 3280.071348][ T8472] RDX: 00007ffcd1fed6c8 RSI: 00000000c4009420 RDI: 0000000000000003
	[ 3280.072750][ T8472] RBP: 0000000000000003 R08: 0000000000000003 R09: 0000000000000078
	[ 3280.073998][ T8472] R10: fffffffffffff59d R11: 0000000000000206 R12: 0000000000000002
	[ 3280.075238][ T8472] R13: 00007ffcd1fefa39 R14: 0000560042d94119 R15: 0000000000000000
	[ 3280.222230][ T8472] ------------[ cut here ]------------
	[ 3280.223530][ T8472] WARNING: CPU: 3 PID: 8472 at fs/btrfs/backref.c:2627 btrfs_backref_add_tree_node+0xfa4/0x11d0
	[ 3280.226859][ T8472] Modules linked in:
	[ 3280.228422][ T8472] CPU: 3 PID: 8472 Comm: btrfs Tainted: G        W         5.10.0-87fa69f8a71b-for-next+ #14
	[ 3280.231521][ T8472] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
	[ 3280.233746][ T8472] RIP: 0010:btrfs_backref_add_tree_node+0xfa4/0x11d0
	[ 3280.234776][ T8472] Code: 89 e7 4d 8d 66 30 e8 db 3e f3 ff 49 8d 46 2c 48 89 45 c0 e9 da f1 ff ff 49 8d 46 2c bb 8b ff ff ff 48 89 45 c0 e9 c8 f1 ff ff <0f> 0b 49 8d 46 2c bb fe ff ff ff 4d 8d 66 30 48 89 45 c0 e9 b0 f1
	[ 3280.237631][ T8472] RSP: 0018:ffffc9000769f4c0 EFLAGS: 00010246
	[ 3280.238626][ T8472] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1ffff92000ed3e85
	[ 3280.239826][ T8472] RDX: 0000000000000000 RSI: dffffc0000000000 RDI: ffff88805ef475e8
	[ 3280.241013][ T8472] RBP: ffffc9000769f598 R08: ffffed100bde8ebe R09: ffffed100bde8ebe
	[ 3280.242197][ T8472] R10: ffff88805ef475eb R11: ffffed100bde8ebd R12: ffff88805ef47020
	[ 3280.243428][ T8472] R13: 0000217411380000 R14: ffff888126976b80 R15: 0000000000000000
	[ 3280.244679][ T8472] FS:  00007f18ca3228c0(0000) GS:ffff8881f5e00000(0000) knlGS:0000000000000000
	[ 3280.246099][ T8472] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
	[ 3280.247102][ T8472] CR2: 000055b5c456ab00 CR3: 000000012c08e002 CR4: 00000000001706e0
	[ 3280.248455][ T8472] Call Trace:
	[ 3280.249018][ T8472]  build_backref_tree+0xc5/0x700
	[ 3280.249845][ T8472]  ? _raw_spin_unlock+0x22/0x30
	[ 3280.250576][ T8472]  ? release_extent_buffer+0x225/0x280
	[ 3280.251381][ T8472]  ? free_extent_buffer.part.52+0xd7/0x140
	[ 3280.252253][ T8472]  relocate_tree_blocks+0x2a6/0xb60
	[ 3280.253044][ T8472]  ? kasan_unpoison_shadow+0x35/0x50
	[ 3280.253841][ T8472]  ? do_relocation+0xc10/0xc10
	[ 3280.254559][ T8472]  ? kasan_kmalloc+0x9/0x10
	[ 3280.255227][ T8472]  ? kmem_cache_alloc_trace+0x6a3/0xcb0
	[ 3280.256063][ T8472]  ? free_extent_buffer.part.52+0xd7/0x140
	[ 3280.256939][ T8472]  ? rb_insert_color+0x342/0x360
	[ 3280.257685][ T8472]  ? add_tree_block.isra.36+0x236/0x2b0
	[ 3280.258519][ T8472]  relocate_block_group+0x2eb/0x780
	[ 3280.259332][ T8472]  ? merge_reloc_roots+0x470/0x470
	[ 3280.260223][ T8472]  btrfs_relocate_block_group+0x26e/0x4c0
	[ 3280.261169][ T8472]  btrfs_relocate_chunk+0x52/0x120
	[ 3280.262199][ T8472]  btrfs_balance+0xe2e/0x18f0
	[ 3280.263146][ T8472]  ? pvclock_clocksource_read+0xeb/0x190
	[ 3280.264035][ T8472]  ? btrfs_relocate_chunk+0x120/0x120
	[ 3280.264851][ T8472]  ? lock_contended+0x620/0x6e0
	[ 3280.265587][ T8472]  ? do_raw_spin_lock+0x1e0/0x1e0
	[ 3280.266334][ T8472]  ? do_raw_spin_unlock+0xa8/0x140
	[ 3280.267103][ T8472]  btrfs_ioctl_balance+0x1f9/0x460
	[ 3280.267896][ T8472]  btrfs_ioctl+0x24c8/0x4380
	[ 3280.268599][ T8472]  ? __kasan_check_read+0x11/0x20
	[ 3280.269377][ T8472]  ? check_chain_key+0x1f4/0x2f0
	[ 3280.270149][ T8472]  ? __asan_loadN+0xf/0x20
	[ 3280.270875][ T8472]  ? btrfs_ioctl_get_supported_features+0x30/0x30
	[ 3280.271894][ T8472]  ? kvm_sched_clock_read+0x18/0x30
	[ 3280.272716][ T8472]  ? check_chain_key+0x1f4/0x2f0
	[ 3280.273503][ T8472]  ? lock_downgrade+0x3f0/0x3f0
	[ 3280.274258][ T8472]  ? handle_mm_fault+0xad6/0x2150
	[ 3280.275053][ T8472]  ? do_vfs_ioctl+0xfc/0x9d0
	[ 3280.275796][ T8472]  ? ioctl_file_clone+0xe0/0xe0
	[ 3280.276575][ T8472]  ? check_flags.part.50+0x6c/0x1e0
	[ 3280.277393][ T8472]  ? check_flags.part.50+0x6c/0x1e0
	[ 3280.278222][ T8472]  ? check_flags+0x26/0x30
	[ 3280.278943][ T8472]  ? lock_is_held_type+0xc3/0xf0
	[ 3280.279734][ T8472]  ? syscall_enter_from_user_mode+0x1b/0x60
	[ 3280.280672][ T8472]  ? do_syscall_64+0x13/0x80
	[ 3280.281394][ T8472]  ? rcu_read_lock_sched_held+0xa1/0xd0
	[ 3280.282276][ T8472]  ? __kasan_check_read+0x11/0x20
	[ 3280.283084][ T8472]  ? __fget_light+0xae/0x110
	[ 3280.283826][ T8472]  __x64_sys_ioctl+0xc3/0x100
	[ 3280.284576][ T8472]  do_syscall_64+0x37/0x80
	[ 3280.285268][ T8472]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
	[ 3280.286198][ T8472] RIP: 0033:0x7f18ca415427
	[ 3280.286912][ T8472] Code: 00 00 90 48 8b 05 69 aa 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 39 aa 0c 00 f7 d8 64 89 01 48
	[ 3280.289939][ T8472] RSP: 002b:00007ffcd1fed6b8 EFLAGS: 00000206 ORIG_RAX: 0000000000000010
	[ 3280.291265][ T8472] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f18ca415427
	[ 3280.292520][ T8472] RDX: 00007ffcd1fed6c8 RSI: 00000000c4009420 RDI: 0000000000000003
	[ 3280.293776][ T8472] RBP: 0000000000000003 R08: 0000000000000003 R09: 0000000000000078
	[ 3280.295056][ T8472] R10: fffffffffffff59d R11: 0000000000000206 R12: 0000000000000002
	[ 3280.296340][ T8472] R13: 00007ffcd1fefa39 R14: 0000560042d94119 R15: 0000000000000000
	[ 3280.297670][ T8472] CPU: 3 PID: 8472 Comm: btrfs Tainted: G        W         5.10.0-87fa69f8a71b-for-next+ #14
	[ 3280.299320][ T8472] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
	[ 3280.300804][ T8472] Call Trace:
	[ 3280.301338][ T8472]  dump_stack+0xbc/0xf9
	[ 3280.302022][ T8472]  ? btrfs_backref_add_tree_node+0xfa4/0x11d0
	[ 3280.302979][ T8472]  __warn.cold.11+0xe/0x53
	[ 3280.303672][ T8472]  ? btrfs_backref_add_tree_node+0xfa4/0x11d0
	[ 3280.304627][ T8472]  report_bug+0xf4/0x130
	[ 3280.305301][ T8472]  handle_bug+0x41/0x80
	[ 3280.305959][ T8472]  exc_invalid_op+0x18/0x40
	[ 3280.306666][ T8472]  asm_exc_invalid_op+0x12/0x20
	[ 3280.307429][ T8472] RIP: 0010:btrfs_backref_add_tree_node+0xfa4/0x11d0
	[ 3280.308481][ T8472] Code: 89 e7 4d 8d 66 30 e8 db 3e f3 ff 49 8d 46 2c 48 89 45 c0 e9 da f1 ff ff 49 8d 46 2c bb 8b ff ff ff 48 89 45 c0 e9 c8 f1 ff ff <0f> 0b 49 8d 46 2c bb fe ff ff ff 4d 8d 66 30 48 89 45 c0 e9 b0 f1
	[ 3280.311594][ T8472] RSP: 0018:ffffc9000769f4c0 EFLAGS: 00010246
	[ 3280.312577][ T8472] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1ffff92000ed3e85
	[ 3280.313872][ T8472] RDX: 0000000000000000 RSI: dffffc0000000000 RDI: ffff88805ef475e8
	[ 3280.315142][ T8472] RBP: ffffc9000769f598 R08: ffffed100bde8ebe R09: ffffed100bde8ebe
	[ 3280.316417][ T8472] R10: ffff88805ef475eb R11: ffffed100bde8ebd R12: ffff88805ef47020
	[ 3280.317664][ T8472] R13: 0000217411380000 R14: ffff888126976b80 R15: 0000000000000000
	[ 3280.318924][ T8472]  build_backref_tree+0xc5/0x700
	[ 3280.319696][ T8472]  ? _raw_spin_unlock+0x22/0x30
	[ 3280.320459][ T8472]  ? release_extent_buffer+0x225/0x280
	[ 3280.321321][ T8472]  ? free_extent_buffer.part.52+0xd7/0x140
	[ 3280.322237][ T8472]  relocate_tree_blocks+0x2a6/0xb60
	[ 3280.323056][ T8472]  ? kasan_unpoison_shadow+0x35/0x50
	[ 3280.323897][ T8472]  ? do_relocation+0xc10/0xc10
	[ 3280.324707][ T8472]  ? kasan_kmalloc+0x9/0x10
	[ 3280.325406][ T8472]  ? kmem_cache_alloc_trace+0x6a3/0xcb0
	[ 3280.326258][ T8472]  ? free_extent_buffer.part.52+0xd7/0x140
	[ 3280.327176][ T8472]  ? rb_insert_color+0x342/0x360
	[ 3280.327970][ T8472]  ? add_tree_block.isra.36+0x236/0x2b0
	[ 3280.328825][ T8472]  relocate_block_group+0x2eb/0x780
	[ 3280.329621][ T8472]  ? merge_reloc_roots+0x470/0x470
	[ 3280.330443][ T8472]  btrfs_relocate_block_group+0x26e/0x4c0
	[ 3280.331348][ T8472]  btrfs_relocate_chunk+0x52/0x120
	[ 3280.332179][ T8472]  btrfs_balance+0xe2e/0x18f0
	[ 3280.332951][ T8472]  ? pvclock_clocksource_read+0xeb/0x190
	[ 3280.333844][ T8472]  ? btrfs_relocate_chunk+0x120/0x120
	[ 3280.334711][ T8472]  ? lock_contended+0x620/0x6e0
	[ 3280.335562][ T8472]  ? do_raw_spin_lock+0x1e0/0x1e0
	[ 3280.336383][ T8472]  ? do_raw_spin_unlock+0xa8/0x140
	[ 3280.337215][ T8472]  btrfs_ioctl_balance+0x1f9/0x460
	[ 3280.338026][ T8472]  btrfs_ioctl+0x24c8/0x4380
	[ 3280.338743][ T8472]  ? __kasan_check_read+0x11/0x20
	[ 3280.339530][ T8472]  ? check_chain_key+0x1f4/0x2f0
	[ 3280.340326][ T8472]  ? __asan_loadN+0xf/0x20
	[ 3280.341065][ T8472]  ? btrfs_ioctl_get_supported_features+0x30/0x30
	[ 3280.342069][ T8472]  ? kvm_sched_clock_read+0x18/0x30
	[ 3280.342890][ T8472]  ? check_chain_key+0x1f4/0x2f0
	[ 3280.343670][ T8472]  ? lock_downgrade+0x3f0/0x3f0
	[ 3280.344440][ T8472]  ? handle_mm_fault+0xad6/0x2150
	[ 3280.345257][ T8472]  ? do_vfs_ioctl+0xfc/0x9d0
	[ 3280.346010][ T8472]  ? ioctl_file_clone+0xe0/0xe0
	[ 3280.346801][ T8472]  ? check_flags.part.50+0x6c/0x1e0
	[ 3280.347640][ T8472]  ? check_flags.part.50+0x6c/0x1e0
	[ 3280.348542][ T8472]  ? check_flags+0x26/0x30
	[ 3280.349322][ T8472]  ? lock_is_held_type+0xc3/0xf0
	[ 3280.350180][ T8472]  ? syscall_enter_from_user_mode+0x1b/0x60
	[ 3280.351128][ T8472]  ? do_syscall_64+0x13/0x80
	[ 3280.351872][ T8472]  ? rcu_read_lock_sched_held+0xa1/0xd0
	[ 3280.352819][ T8472]  ? __kasan_check_read+0x11/0x20
	[ 3280.353604][ T8472]  ? __fget_light+0xae/0x110
	[ 3280.354321][ T8472]  __x64_sys_ioctl+0xc3/0x100
	[ 3280.355050][ T8472]  do_syscall_64+0x37/0x80
	[ 3280.355733][ T8472]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
	[ 3280.356645][ T8472] RIP: 0033:0x7f18ca415427
	[ 3280.357332][ T8472] Code: 00 00 90 48 8b 05 69 aa 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 39 aa 0c 00 f7 d8 64 89 01 48
	[ 3280.360434][ T8472] RSP: 002b:00007ffcd1fed6b8 EFLAGS: 00000206 ORIG_RAX: 0000000000000010
	[ 3280.361741][ T8472] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f18ca415427
	[ 3280.362962][ T8472] RDX: 00007ffcd1fed6c8 RSI: 00000000c4009420 RDI: 0000000000000003
	[ 3280.364165][ T8472] RBP: 0000000000000003 R08: 0000000000000003 R09: 0000000000000078
	[ 3280.365366][ T8472] R10: fffffffffffff59d R11: 0000000000000206 R12: 0000000000000002
	[ 3280.366570][ T8472] R13: 00007ffcd1fefa39 R14: 0000560042d94119 R15: 0000000000000000
	[ 3280.367904][ T8472] irq event stamp: 4498529
	[ 3280.368608][ T8472] hardirqs last  enabled at (4498529): [<ffffffff83a60905>] irqentry_exit+0x35/0x80
	[ 3280.370128][ T8472] hardirqs last disabled at (4498527): [<ffffffff83e00506>] __do_softirq+0x506/0x5a7
	[ 3280.371656][ T8472] softirqs last  enabled at (4498528): [<ffffffff83e0044f>] __do_softirq+0x44f/0x5a7
	[ 3280.373173][ T8472] softirqs last disabled at (4498521): [<ffffffff83c01122>] asm_call_irq_on_stack+0x12/0x20
	[ 3280.374833][ T8472] ---[ end trace 0689b357dfaddeab ]---

	(gdb) list *(btrfs_backref_add_tree_node+0xfa4)
	0xffffffff81970194 is in btrfs_backref_add_tree_node (fs/btrfs/backref.c:2627).
	2622
	2623                    cur->is_reloc_root = 1;
	2624                    /* Only reloc backref cache cares about a specific root */
	2625                    if (cache->is_reloc) {
	2626                            root = find_reloc_root(cache->fs_info, cur->bytenr);
	2627                            if (WARN_ON(!root))
	2628                                    return -ENOENT;
	2629                            cur->root = root;
	2630                    } else {
	2631                            /*

	[ 3280.375749][ T8472] ------------[ cut here ]------------
	[ 3280.376711][ T8472] kernel BUG at fs/btrfs/backref.c:2545!
	[ 3280.377576][ T8472] invalid opcode: 0000 [#1] SMP KASAN PTI
	[ 3280.378401][ T8472] CPU: 3 PID: 8472 Comm: btrfs Tainted: G        W         5.10.0-87fa69f8a71b-for-next+ #14
	[ 3280.379966][ T8472] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
	[ 3280.381287][ T8472] RIP: 0010:btrfs_backref_cleanup_node+0x5f7/0x600
	[ 3280.382376][ T8472] Code: 5f 5d c3 48 89 df e8 08 e2 fa ff 49 8d 7f 70 e8 0f c8 b9 ff 41 80 67 71 fb 4c 89 e7 e8 b2 c9 b9 ff 49 8b 5f 68 e9 b2 fc ff ff <0f> 0b 0f 0b 0f 0b 0f 0b 90 0f 1f 44 00 00 55 48 89 e5 41 57 41 56
	[ 3280.385743][ T8472] RSP: 0018:ffffc9000769f4c8 EFLAGS: 00010283
	[ 3280.386689][ T8472] RAX: ffff8880436bc880 RBX: ffff8880436bc180 RCX: ffffffff8296ec9b
	[ 3280.387966][ T8472] RDX: dffffc0000000000 RSI: dffffc0000000000 RDI: ffff8881ebd43f40
	[ 3280.389242][ T8472] RBP: ffffc9000769f520 R08: 0000000000000000 R09: 0000000000000000
	[ 3280.390503][ T8472] R10: ffffffff8533ba03 R11: fffffbfff0a67740 R12: ffff8880436bc190
	[ 3280.391763][ T8472] R13: ffff8881ebd43900 R14: ffff8880436bc190 R15: ffff8881ebd43f00
	[ 3280.393123][ T8472] FS:  00007f18ca3228c0(0000) GS:ffff8881f5e00000(0000) knlGS:0000000000000000
	[ 3280.394562][ T8472] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
	[ 3280.395950][ T8472] CR2: 000055b5c456ab00 CR3: 000000012c08e002 CR4: 00000000001706e0
	[ 3280.397253][ T8472] Call Trace:
	[ 3280.399029][ T8472]  btrfs_backref_error_cleanup+0x4df/0x530
	[ 3280.399997][ T8472]  build_backref_tree+0x1a5/0x700
	[ 3280.400814][ T8472]  ? _raw_spin_unlock+0x22/0x30
	[ 3280.401597][ T8472]  ? release_extent_buffer+0x225/0x280
	[ 3280.402532][ T8472]  ? free_extent_buffer.part.52+0xd7/0x140
	[ 3280.403470][ T8472]  relocate_tree_blocks+0x2a6/0xb60
	[ 3280.404295][ T8472]  ? kasan_unpoison_shadow+0x35/0x50
	[ 3280.405146][ T8472]  ? do_relocation+0xc10/0xc10
	[ 3280.405987][ T8472]  ? kasan_kmalloc+0x9/0x10
	[ 3280.407291][ T8472]  ? kmem_cache_alloc_trace+0x6a3/0xcb0
	[ 3280.408229][ T8472]  ? free_extent_buffer.part.52+0xd7/0x140
	[ 3280.409188][ T8472]  ? rb_insert_color+0x342/0x360
	[ 3280.409969][ T8472]  ? add_tree_block.isra.36+0x236/0x2b0
	[ 3280.410985][ T8472]  relocate_block_group+0x2eb/0x780
	[ 3280.411805][ T8472]  ? merge_reloc_roots+0x470/0x470
	[ 3280.412546][ T8472]  btrfs_relocate_block_group+0x26e/0x4c0
	[ 3280.413436][ T8472]  btrfs_relocate_chunk+0x52/0x120
	[ 3280.414302][ T8472]  btrfs_balance+0xe2e/0x18f0
	[ 3280.415022][ T8472]  ? pvclock_clocksource_read+0xeb/0x190
	[ 3280.415922][ T8472]  ? btrfs_relocate_chunk+0x120/0x120
	[ 3280.416842][ T8472]  ? lock_contended+0x620/0x6e0
	[ 3280.417598][ T8472]  ? do_raw_spin_lock+0x1e0/0x1e0
	[ 3280.418394][ T8472]  ? do_raw_spin_unlock+0xa8/0x140
	[ 3280.419208][ T8472]  btrfs_ioctl_balance+0x1f9/0x460
	[ 3280.420016][ T8472]  btrfs_ioctl+0x24c8/0x4380
	[ 3280.420734][ T8472]  ? __kasan_check_read+0x11/0x20
	[ 3280.421523][ T8472]  ? check_chain_key+0x1f4/0x2f0
	[ 3280.423328][ T8472]  ? __asan_loadN+0xf/0x20
	[ 3280.424033][ T8472]  ? btrfs_ioctl_get_supported_features+0x30/0x30
	[ 3280.425042][ T8472]  ? kvm_sched_clock_read+0x18/0x30
	[ 3280.425858][ T8472]  ? check_chain_key+0x1f4/0x2f0
	[ 3280.426632][ T8472]  ? lock_downgrade+0x3f0/0x3f0
	[ 3280.427401][ T8472]  ? handle_mm_fault+0xad6/0x2150
	[ 3280.428192][ T8472]  ? do_vfs_ioctl+0xfc/0x9d0
	[ 3280.428920][ T8472]  ? ioctl_file_clone+0xe0/0xe0
	[ 3280.429667][ T8472]  ? check_flags.part.50+0x6c/0x1e0
	[ 3280.430463][ T8472]  ? check_flags.part.50+0x6c/0x1e0
	[ 3280.431252][ T8472]  ? check_flags+0x26/0x30
	[ 3280.431928][ T8472]  ? lock_is_held_type+0xc3/0xf0
	[ 3280.432681][ T8472]  ? syscall_enter_from_user_mode+0x1b/0x60
	[ 3280.433574][ T8472]  ? do_syscall_64+0x13/0x80
	[ 3280.434278][ T8472]  ? rcu_read_lock_sched_held+0xa1/0xd0
	[ 3280.435122][ T8472]  ? __kasan_check_read+0x11/0x20
	[ 3280.435886][ T8472]  ? __fget_light+0xae/0x110
	[ 3280.436586][ T8472]  __x64_sys_ioctl+0xc3/0x100
	[ 3280.437300][ T8472]  do_syscall_64+0x37/0x80
	[ 3280.438040][ T8472]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
	[ 3280.438932][ T8472] RIP: 0033:0x7f18ca415427
	[ 3280.439595][ T8472] Code: 00 00 90 48 8b 05 69 aa 0c 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 39 aa 0c 00 f7 d8 64 89 01 48
	[ 3280.442689][ T8472] RSP: 002b:00007ffcd1fed6b8 EFLAGS: 00000206 ORIG_RAX: 0000000000000010
	[ 3280.444023][ T8472] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f18ca415427
	[ 3280.445292][ T8472] RDX: 00007ffcd1fed6c8 RSI: 00000000c4009420 RDI: 0000000000000003
	[ 3280.446601][ T8472] RBP: 0000000000000003 R08: 0000000000000003 R09: 0000000000000078
	[ 3280.448014][ T8472] R10: fffffffffffff59d R11: 0000000000000206 R12: 0000000000000002
	[ 3280.449397][ T8472] R13: 00007ffcd1fefa39 R14: 0000560042d94119 R15: 0000000000000000
	[ 3280.450805][ T8472] Modules linked in:
	[ 3280.451530][ T8472] ---[ end trace 0689b357dfaddeac ]---

	(gdb) list *(btrfs_backref_cleanup_node+0x5f7)
	0xffffffff8196f037 is in btrfs_backref_cleanup_node (fs/btrfs/backref.c:2545).
	2540                    list_del(&edge->list[LOWER]);
	2541                    list_del(&edge->list[UPPER]);
	2542                    btrfs_backref_free_edge(cache, edge);
	2543
	2544                    if (RB_EMPTY_NODE(&upper->rb_node)) {
	2545                            BUG_ON(!list_empty(&node->upper));
	2546                            btrfs_backref_drop_node(cache, node);
	2547                            node = upper;
	2548                            node->lowest = 1;
	2549                            continue;

> > Josef

^ permalink raw reply	[flat|nested] 49+ messages in thread

end of thread, other threads:[~2020-11-15  0:38 UTC | newest]

Thread overview: 49+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-11-12 21:18 [PATCH 00/42] Cleanup error handling in relocation Josef Bacik
2020-11-12 21:18 ` [PATCH 01/42] btrfs: allow error injection for btrfs_search_slot and btrfs_cow_block Josef Bacik
2020-11-13  0:02   ` Qu Wenruo
2020-11-13 11:05     ` Josef Bacik
2020-11-12 21:18 ` [PATCH 02/42] btrfs: fix lockdep splat in btrfs_recover_relocation Josef Bacik
2020-11-12 21:18 ` [PATCH 03/42] btrfs: convert some BUG_ON()'s to ASSERT()'s in do_relocation Josef Bacik
2020-11-12 21:18 ` [PATCH 04/42] btrfs: convert BUG_ON()'s in relocate_tree_block Josef Bacik
2020-11-12 21:18 ` [PATCH 05/42] btrfs: return an error from btrfs_record_root_in_trans Josef Bacik
2020-11-12 21:18 ` [PATCH 06/42] btrfs: handle errors from select_reloc_root() Josef Bacik
2020-11-12 21:18 ` [PATCH 07/42] btrfs: convert BUG_ON()'s in select_reloc_root() to proper errors Josef Bacik
2020-11-12 21:18 ` [PATCH 08/42] btrfs: check record_root_in_trans related failures in select_reloc_root Josef Bacik
2020-11-12 21:18 ` [PATCH 09/42] btrfs: do proper error handling in record_reloc_root_in_trans Josef Bacik
2020-11-12 21:18 ` [PATCH 10/42] btrfs: handle btrfs_record_root_in_trans failure in btrfs_rename_exchange Josef Bacik
2020-11-12 21:18 ` [PATCH 11/42] btrfs: handle btrfs_record_root_in_trans failure in btrfs_rename Josef Bacik
2020-11-12 21:18 ` [PATCH 12/42] btrfs: handle btrfs_record_root_in_trans failure in btrfs_delete_subvolume Josef Bacik
2020-11-12 21:18 ` [PATCH 13/42] btrfs: handle btrfs_record_root_in_trans failure in btrfs_recover_log_trees Josef Bacik
2020-11-12 21:18 ` [PATCH 14/42] btrfs: handle btrfs_record_root_in_trans failure in create_subvol Josef Bacik
2020-11-12 21:18 ` [PATCH 15/42] btrfs: btrfs: handle btrfs_record_root_in_trans failure in relocate_tree_block Josef Bacik
2020-11-12 21:18 ` [PATCH 16/42] btrfs: handle btrfs_record_root_in_trans failure in start_transaction Josef Bacik
2020-11-12 21:18 ` [PATCH 17/42] btrfs: handle record_root_in_trans failure in qgroup_account_snapshot Josef Bacik
2020-11-12 21:18 ` [PATCH 18/42] btrfs: handle record_root_in_trans failure in btrfs_record_root_in_trans Josef Bacik
2020-11-12 21:18 ` [PATCH 19/42] btrfs: handle record_root_in_trans failure in create_pending_snapshot Josef Bacik
2020-11-12 21:18 ` [PATCH 20/42] btrfs: do not panic in __add_reloc_root Josef Bacik
2020-11-12 21:18 ` [PATCH 21/42] btrfs: have proper error handling in btrfs_init_reloc_root Josef Bacik
2020-11-12 21:18 ` [PATCH 22/42] btrfs: do proper error handling in create_reloc_root Josef Bacik
2020-11-12 21:18 ` [PATCH 23/42] btrfs: handle btrfs_update_reloc_root failure in commit_fs_roots Josef Bacik
2020-11-12 21:18 ` [PATCH 24/42] btrfs: change insert_dirty_subvol to return errors Josef Bacik
2020-11-12 21:18 ` [PATCH 25/42] btrfs: handle btrfs_update_reloc_root failure in insert_dirty_subvol Josef Bacik
2020-11-12 21:18 ` [PATCH 26/42] btrfs: handle btrfs_update_reloc_root failure in prepare_to_merge Josef Bacik
2020-11-12 21:18 ` [PATCH 27/42] btrfs: do proper error handling in btrfs_update_reloc_root Josef Bacik
2020-11-12 21:18 ` [PATCH 28/42] btrfs: convert logic BUG_ON()'s in replace_path to ASSERT()'s Josef Bacik
2020-11-12 21:18 ` [PATCH 29/42] btrfs: handle initial btrfs_cow_block error in replace_path Josef Bacik
2020-11-12 21:18 ` [PATCH 30/42] btrfs: handle the loop " Josef Bacik
2020-11-12 21:18 ` [PATCH 31/42] btrfs: handle btrfs_search_slot failure " Josef Bacik
2020-11-12 21:18 ` [PATCH 32/42] btrfs: handle errors in reference count manipulation " Josef Bacik
2020-11-12 21:19 ` [PATCH 33/42] btrfs: handle extent reference errors in do_relocation Josef Bacik
2020-11-12 21:19 ` [PATCH 34/42] btrfs: check for BTRFS_BLOCK_FLAG_FULL_BACKREF being set improperly Josef Bacik
2020-11-12 21:19 ` [PATCH 35/42] btrfs: remove the extent item sanity checks in relocate_block_group Josef Bacik
2020-11-12 21:19 ` [PATCH 36/42] btrfs: do proper error handling in create_reloc_inode Josef Bacik
2020-11-12 21:19 ` [PATCH 37/42] btrfs: handle __add_reloc_root failure in btrfs_recover_relocation Josef Bacik
2020-11-12 21:19 ` [PATCH 38/42] btrfs: handle __add_reloc_root failure in btrfs_reloc_post_snapshot Josef Bacik
2020-11-12 21:19 ` [PATCH 39/42] btrfs: cleanup error handling in prepare_to_merge Josef Bacik
2020-11-12 21:19 ` [PATCH 40/42] btrfs: handle extent corruption with select_one_root properly Josef Bacik
2020-11-12 21:19 ` [PATCH 41/42] btrfs: do proper error handling in merge_reloc_roots Josef Bacik
2020-11-12 21:19 ` [PATCH 42/42] btrfs: check return value of btrfs_commit_transaction in relocation Josef Bacik
2020-11-13  3:53 ` [PATCH 00/42] Cleanup error handling " Zygo Blaxell
2020-11-13 11:03   ` Josef Bacik
2020-11-13 14:39     ` Zygo Blaxell
2020-11-15  0:37       ` Zygo Blaxell

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.