linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Feifei Xu <xufeifei@linux.vnet.ibm.com>
To: linux-btrfs@vger.kernel.org
Cc: steve.capper@linaro.org, chandan@mykolab.com, jbacik@fb.com,
	dsterba@suse.com, chandan@linux.vnet.ibm.com,
	feifeixu.sh@gmail.com, Feifei Xu <xufeifei@linux.vnet.ibm.com>
Subject: [PATCH V2 1/8] Btrfs: test_check_exists: Fix infinite loop when searching for free space entries
Date: Wed,  1 Jun 2016 15:51:40 +0000	[thread overview]
Message-ID: <1464796307-67173-2-git-send-email-xufeifei@linux.vnet.ibm.com> (raw)
In-Reply-To: <1464796307-67173-1-git-send-email-xufeifei@linux.vnet.ibm.com>

On a ppc64 machine using 64K as the block size, assume that the RB
tree at btrfs_free_space_ctl->free_space_offset contains following
two entries:

1. A bitmap entry having an offset value of 0 and having the bits
   corresponding to the address range [128M+512K, 128M+768K] set.
2. An extent entry corresponding to the address range
   [128M-256K, 128M-128K]

In such a scenario, test_check_exists() invoked for checking the
existence of address range [128M+768K, 256M] can lead to an
infinite loop as explained below:

- Checking for the extent entry fails.
- Checking for a bitmap entry results in the free space info in
  range [128M+512K, 128M+768K] beng returned.
- rb_prev(info) returns NULL because the bitmap entry starting from
  offset 0 comes first in the RB tree.
- current_node = bitmap node.
- while (current_node)
	tmp = rb_next(bitmap_node);/*tmp is extent based free space entry*/
	Since extent based free space entry's last address is smaller
	than the address being searched for (i.e. 128M+768K) we
	incorrectly again obtain the extent node as the "next right node"
	of the RB tree and thus end up looping infinitely.

This patch fixes the issue by checking the "tmp" variable which point
to the most recently searched free space node.

Reviewed-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Signed-off-by: Feifei Xu <xufeifei@linux.vnet.ibm.com>
---
 fs/btrfs/free-space-cache.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
index c6dc118..fa62335 100644
--- a/fs/btrfs/free-space-cache.c
+++ b/fs/btrfs/free-space-cache.c
@@ -3662,7 +3662,7 @@ have_info:
 			if (tmp->offset + tmp->bytes < offset)
 				break;
 			if (offset + bytes < tmp->offset) {
-				n = rb_prev(&info->offset_index);
+				n = rb_prev(&tmp->offset_index);
 				continue;
 			}
 			info = tmp;
@@ -3676,7 +3676,7 @@ have_info:
 			if (offset + bytes < tmp->offset)
 				break;
 			if (tmp->offset + tmp->bytes < offset) {
-				n = rb_next(&info->offset_index);
+				n = rb_next(&tmp->offset_index);
 				continue;
 			}
 			info = tmp;
-- 
2.7.4


  reply	other threads:[~2016-06-01 15:53 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-01 15:51 [PATCH V2 0/8] Btrfs: self-tests: Support non-4k page size Feifei Xu
2016-06-01 15:51 ` Feifei Xu [this message]
2016-06-01 15:51 ` [PATCH V2 2/8] Btrfs: Fix integer overflow when calculating bytes_per_bitmap Feifei Xu
2016-06-01 15:51 ` [PATCH V2 3/8] Btrfs: self-tests: Support non-4k page size Feifei Xu
2016-06-01 15:51 ` [PATCH V2 4/8] Btrfs: self-tests: Execute page straddling test only when nodesize < PAGE_SIZE Feifei Xu
2016-06-01 15:51 ` [PATCH V2 5/8] Btrfs: self-tests: Support testing all possible sectorsizes and nodesizes Feifei Xu
2016-06-01 15:51 ` [PATCH V2 6/8] Btrfs: self-tests: Use macros instead of constants and add missing newline Feifei Xu
2016-06-01 15:51 ` [PATCH V2 7/8] Btrfs: self-tests: Fix test_bitmaps fail on 64k sectorsize Feifei Xu
2016-06-01 15:51 ` [PATCH V2 8/8] Btrfs: self-tests: Fix extent buffer bitmap test fail on BE system Feifei Xu
2016-06-01 15:56 ` [PATCH V2 0/8] Btrfs: self-tests: Support non-4k page size Feifei Xu
2016-06-01 17:13 ` Josef Bacik
  -- strict thread matches above, loose matches on Subject: below --
2016-06-01 11:18 Feifei Xu
2016-06-01 11:18 ` [PATCH V2 1/8] Btrfs: test_check_exists: Fix infinite loop when searching for free space entries Feifei Xu

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=1464796307-67173-2-git-send-email-xufeifei@linux.vnet.ibm.com \
    --to=xufeifei@linux.vnet.ibm.com \
    --cc=chandan@linux.vnet.ibm.com \
    --cc=chandan@mykolab.com \
    --cc=dsterba@suse.com \
    --cc=feifeixu.sh@gmail.com \
    --cc=jbacik@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=steve.capper@linaro.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).