Btrfs: test_check_exists: Fix infinite loop when searching for free space entries
authorFeifei Xu <xufeifei@linux.vnet.ibm.com>
Wed, 1 Jun 2016 11:18:23 +0000 (19:18 +0800)
committerDavid Sterba <dsterba@suse.com>
Thu, 2 Jun 2016 17:22:34 +0000 (19:22 +0200)
commit5473e0c426ffaeaa19734987b153c2a7f33b8706
tree95255bb93b84571ffdcabf85906a88169fe562f0
parent56244ef151c3cd11f505020ab0b3f45454363bcc
Btrfs: test_check_exists: Fix infinite loop when searching for free space entries

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: Josef Bacik <jbacik@fb.com>
Reviewed-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Signed-off-by: Feifei Xu <xufeifei@linux.vnet.ibm.com>
Signed-off-by: David Sterba <dsterba@suse.com>
fs/btrfs/free-space-cache.c