summaryrefslogtreecommitdiff
path: root/crypto/ghash-generic.c
diff options
context:
space:
mode:
authorJosef Bacik <jbacik@fb.com>2014-09-19 23:43:34 +0400
committerChris Mason <clm@fb.com>2014-10-04 03:14:58 +0400
commitbbe9051441effce51c9a533d2c56440df64db2d7 (patch)
treeaf28bfa4a494877ac47c3e43806ece3c48c5eeaf /crypto/ghash-generic.c
parent75bfb9aff45e44625260f52a5fd581b92ace3e62 (diff)
downloadlinux-bbe9051441effce51c9a533d2c56440df64db2d7.tar.xz
Btrfs: fix build_backref_tree issue with multiple shared blocks
Marc Merlin sent me a broken fs image months ago where it would blow up in the upper->checked BUG_ON() in build_backref_tree. This is because we had a scenario like this block a -- level 4 (not shared) | block b -- level 3 (reloc block, shared) | block c -- level 2 (not shared) | block d -- level 1 (shared) | block e -- level 0 (shared) We go to build a backref tree for block e, we notice block d is shared and add it to the list of blocks to lookup it's backrefs for. Now when we loop around we will check edges for the block, so we will see we looked up block c last time. So we lookup block d and then see that the block that points to it is block c and we can just skip that edge since we've already been up this path. The problem is because we clear need_check when we see block d (as it is shared) we never add block b as needing to be checked. And because block c is in our path already we bail out before we walk up to block b and add it to the backref check list. To fix this we need to reset need_check if we trip over a block that doesn't need to be checked. This will make sure that any subsequent blocks in the path as we're walking up afterwards are added to the list to be processed. With this patch I can now mount Marc's fs image and it'll complete the balance without panicing. Thanks, Reported-by: Marc MERLIN <marc@merlins.org> Signed-off-by: Josef Bacik <jbacik@fb.com> Signed-off-by: Chris Mason <clm@fb.com>
Diffstat (limited to 'crypto/ghash-generic.c')
0 files changed, 0 insertions, 0 deletions