diff options
| author | Filipe Manana <fdmanana@suse.com> | 2023-04-26 13:51:37 +0300 |
|---|---|---|
| committer | David Sterba <dsterba@suse.com> | 2023-06-19 14:59:22 +0300 |
| commit | 88ad95b055764e4c74fb6b8201f794f4e531753d (patch) | |
| tree | 8d8b0464f207ee7906a2bd7d681a6311b81dd157 /fs/btrfs/ctree.c | |
| parent | f2db4d5cb457b7da439d5509bdb6f7b01054c11b (diff) | |
| download | linux-88ad95b055764e4c74fb6b8201f794f4e531753d.tar.xz | |
btrfs: tag as unlikely the key comparison when checking sibling keys
When checking siblings keys, before moving keys from one node/leaf to a
sibling node/leaf, it's very unexpected to have the last key of the left
sibling greater than or equals to the first key of the right sibling, as
that means we have a (serious) corruption that breaks the key ordering
properties of a b+tree. Since this is unexpected, surround the comparison
with the unlikely macro, which helps the compiler generate better code
for the most expected case (no existing b+tree corruption). This is also
what we do for other unexpected cases of invalid key ordering (like at
btrfs_set_item_key_safe()).
Reviewed-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Diffstat (limited to 'fs/btrfs/ctree.c')
| -rw-r--r-- | fs/btrfs/ctree.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/fs/btrfs/ctree.c b/fs/btrfs/ctree.c index 28b0402a008f..0321f4286681 100644 --- a/fs/btrfs/ctree.c +++ b/fs/btrfs/ctree.c @@ -2707,7 +2707,7 @@ static bool check_sibling_keys(struct extent_buffer *left, btrfs_item_key_to_cpu(right, &right_first, 0); } - if (btrfs_comp_cpu_keys(&left_last, &right_first) >= 0) { + if (unlikely(btrfs_comp_cpu_keys(&left_last, &right_first) >= 0)) { btrfs_crit(left->fs_info, "left extent buffer:"); btrfs_print_tree(left, false); btrfs_crit(left->fs_info, "right extent buffer:"); |