All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 4/6] btrfs-progs: Fix infinite loop when failed to repair bad key order
Date: Fri,  3 Aug 2018 13:50:20 +0800	[thread overview]
Message-ID: <20180803055022.9816-5-wqu@suse.com> (raw)
In-Reply-To: <20180803055022.9816-1-wqu@suse.com>

[BUG]
An infinite loop can be triggered during fuzz/003:
------
====== RUN MAYFAIL /home/adam/btrfs/btrfs-progs/btrfs check --repair /home/adam/btrfs/btrfs-progs/tests//fuzz-tests/images/bko-199833-reloc-recovery-crash.raw.restored
[1/7] checking root items
Fixed 0 roots.
[2/7] checking extents
ctree.c:1650: leaf_space_used: Warning: assertion `data_len < 0` failed, value 1
bad key ordering 18 19
ctree.c:1650: leaf_space_used: Warning: assertion `data_len < 0` failed, value 1
bad key ordering 18 19
ctree.c:1650: leaf_space_used: Warning: assertion `data_len < 0` failed, value 1
bad key ordering 18 19
...
------

[CAUSE]
In try_to_fix_bad_block() it's possible that btrfs_find_all_roots()
finds no root referring to that tree block, thus we can't do any repair.

However in that case, we still return 0 since the last caller assigning
@ret is btrfs_find_all_roots(), and the ulist while loop doesn't get run
at all.

And since try_to_fix_bad_block() returns 0, check_block() in
check/main.c will return -EAGAIN to re-check the tree block.

This leads to the infinite loop.

[FIX]
Change the default return value from 0 to -EIO in
try_to_fix_bad_block(), so if there is no tree referring to the bad tree
block, it won't cause infinite loop any more.

Signed-off-by: Qu Wenruo <wqu@suse.com>
---
 check/main.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/check/main.c b/check/main.c
index e6756e0f852b..571edc7ef928 100644
--- a/check/main.c
+++ b/check/main.c
@@ -4051,6 +4051,11 @@ static int try_to_fix_bad_block(struct btrfs_root *root,
 
 	btrfs_init_path(&path);
 	ULIST_ITER_INIT(&iter);
+	/*
+	 * If we found no roots referrening to this tree block, there is no
+	 * chance to fix. So our default ret is -EIO.
+	 */
+	ret = -EIO;
 	while ((node = ulist_next(roots, &iter))) {
 		root_key.objectid = node->val;
 		root_key.type = BTRFS_ROOT_ITEM_KEY;
-- 
2.18.0


  parent reply	other threads:[~2018-08-03  7:45 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-03  5:50 [PATCH 0/6] btrfs-progs: Variant fixes for fuzz-tests Qu Wenruo
2018-08-03  5:50 ` [PATCH 1/6] btrfs-progs: Exit gracefully if we hit ENOSPC when allocating tree block Qu Wenruo
2018-08-29 14:30   ` Nikolay Borisov
2018-08-03  5:50 ` [PATCH 2/6] btrfs-progs: Exit gracefully when failed to repair root dir item Qu Wenruo
2018-08-29 14:31   ` Nikolay Borisov
2018-08-03  5:50 ` [PATCH 3/6] btrfs-progs: Don't report dirty leaked eb using BUG_ON Qu Wenruo
2018-08-29 14:52   ` Nikolay Borisov
2018-08-30  1:08     ` Qu Wenruo
2018-08-03  5:50 ` Qu Wenruo [this message]
2018-08-03  5:50 ` [PATCH 5/6] btrfs-progs: Exit gracefull when we failed to alloc dev extent Qu Wenruo
2018-08-29 14:59   ` Nikolay Borisov
2018-08-03  5:50 ` [PATCH 6/6] btrfs-progs: rescue-super: Don't double free fs_devices Qu Wenruo
2018-08-29 15:38   ` Nikolay Borisov
2018-08-30  1:16     ` Qu Wenruo
2018-08-29  5:27 ` [PATCH 0/6] btrfs-progs: Variant fixes for fuzz-tests Qu Wenruo
2018-09-11 16:38   ` David Sterba
2018-09-11 23:59     ` Qu Wenruo
2018-09-14 14:25       ` David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180803055022.9816-5-wqu@suse.com \
    --to=wqu@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.