path: root/convert
diff options
authorJeff Mahoney <>2017-07-27 11:47:21 -0400
committerDavid Sterba <>2017-08-24 19:07:29 +0200
commitf2c14eb282a87d7e622538f76dfbc356cb73c1d4 (patch)
tree0fa6d8a2d57a3af08754fcef870723a23216318a /convert
parent10726f7423e9179d367fb6eb9e37d8ffd91a7f66 (diff)
btrfs-progs: convert: use search_cache_extent in migrate_one_reserved_range
When we are looking for extents in migrate_one_reserved_range, it's likely that there will be multiple extents that fall into the 0-1MB range. If lookup_cache_extent is called with a range that covers multiple cache entries, it will return the first entry it encounters while searching from the top of the tree that happens to fall in that range. That means that we can end up skipping regions within that range, resulting in a file system image that can't be rolled back since it wasn't all migrated properly. This is reproducible using convert-tests/008-readonly-image. There was a range from 0-160kB, but the only entry that was returned began at ~ 280kB. The fix is to use search_cache_extent to iterate through multiple regions within that range. Signed-off-by: Jeff Mahoney <> Reviewed-by: Qu Wenruo <> Signed-off-by: David Sterba <>
Diffstat (limited to 'convert')
1 files changed, 3 insertions, 1 deletions
diff --git a/convert/main.c b/convert/main.c
index 800fb1e2..03da9e49 100644
--- a/convert/main.c
+++ b/convert/main.c
@@ -343,10 +343,12 @@ static int migrate_one_reserved_range(struct btrfs_trans_handle *trans,
* migrate ranges that covered by old fs data.
while (cur_off < range_end(range)) {
- cache = lookup_cache_extent(used, cur_off, cur_len);
+ cache = search_cache_extent(used, cur_off);
if (!cache)
cur_off = max(cache->start, cur_off);
+ if (cur_off >= range_end(range))
+ break;
cur_len = min(cache->start + cache->size, range_end(range)) -
BUG_ON(cur_len < root->fs_info->sectorsize);