btrfs: Rework error handling of add_extent_mapping in __btrfs_alloc_chunk
authorNikolay Borisov <nborisov@suse.com>
Mon, 21 Aug 2017 09:43:49 +0000 (12:43 +0300)
committerDavid Sterba <dsterba@suse.com>
Mon, 30 Oct 2017 11:27:56 +0000 (12:27 +0100)
Currently the code executes add_extent_mapping and if it is successful
it links the new mapping, it then proceeds to unlock the extent mapping
tree and check for failure and handle them. Instead, rework the code to
only perform a single check if add_extent_mapping has failed and handle
it, otherwise the code continues in a linear fashion. No functional
changes

Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Josef Bacik <jbacik@fb.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
fs/btrfs/volumes.c

index 533b417..ac1e868 100644 (file)
@@ -4808,16 +4808,16 @@ static int __btrfs_alloc_chunk(struct btrfs_trans_handle *trans,
        em_tree = &info->mapping_tree.map_tree;
        write_lock(&em_tree->lock);
        ret = add_extent_mapping(em_tree, em, 0);
-       if (!ret) {
-               list_add_tail(&em->list, &trans->transaction->pending_chunks);
-               refcount_inc(&em->refs);
-       }
-       write_unlock(&em_tree->lock);
        if (ret) {
+               write_unlock(&em_tree->lock);
                free_extent_map(em);
                goto error;
        }
 
+       list_add_tail(&em->list, &trans->transaction->pending_chunks);
+       refcount_inc(&em->refs);
+       write_unlock(&em_tree->lock);
+
        ret = btrfs_make_block_group(trans, info, 0, type, start, num_bytes);
        if (ret)
                goto error_del_extent;