Btrfs: fix memory leaks in the test test_find_first_clear_extent_bit
The test creates an extent io tree and sets several ranges with the
CHUNK_ALLOCATED and CHUNK_TRIMMED bits, resulting in the allocation of
several extent state structures. However the test never clears those
ranges, resulting in memory leaks of the extent state structures.
This is detected when CONFIG_BTRFS_DEBUG is set once we remove the
btrfs module (rmmod btrfs):
[57399.787918] BTRFS: state leak: start
67108864 end
75497471 state 1 in tree 1 refs 1
[57399.790155] BTRFS: state leak: start
33554432 end
67108863 state 33 in tree 1 refs 1
[57399.791941] BTRFS: state leak: start
1048576 end
4194303 state 33 in tree 1 refs 1
[57399.793753] BTRFS: state leak: start
67108864 end
75497471 state 1 in tree 1 refs 1
[57399.795188] BTRFS: state leak: start
33554432 end
67108863 state 33 in tree 1 refs 1
[57399.796453] BTRFS: state leak: start
1048576 end
4194303 state 33 in tree 1 refs 1
[57399.797765] BTRFS: state leak: start
67108864 end
75497471 state 1 in tree 1 refs 1
[57399.799049] BTRFS: state leak: start
33554432 end
67108863 state 33 in tree 1 refs 1
[57399.800142] BTRFS: state leak: start
1048576 end
4194303 state 33 in tree 1 refs 1
[57399.801126] BTRFS: state leak: start
67108864 end
75497471 state 1 in tree 1 refs 1
[57399.802106] BTRFS: state leak: start
33554432 end
67108863 state 33 in tree 1 refs 1
[57399.803119] BTRFS: state leak: start
1048576 end
4194303 state 33 in tree 1 refs 1
[57399.804153] BTRFS: state leak: start
67108864 end
75497471 state 1 in tree 1 refs 1
[57399.805196] BTRFS: state leak: start
33554432 end
67108863 state 33 in tree 1 refs 1
[57399.806191] BTRFS: state leak: start
1048576 end
4194303 state 33 in tree 1 refs 1
The start and end offsets reported correspond exactly to the ranges
used by the test.
So fix that by clearing all the ranges when the test finishes.
Fixes: 1eaebb341d2b41 ("btrfs: Don't trim returned range based on input value in find_first_clear_extent_bit")
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>