btrfs: check commit root generation in should_ignore_root
authorJosef Bacik <josef@toxicpanda.com>
Thu, 2 Apr 2020 19:51:18 +0000 (15:51 -0400)
committerDavid Sterba <dsterba@suse.com>
Wed, 8 Apr 2020 17:10:31 +0000 (19:10 +0200)
commit4d4225fc228e46948486d8b8207955f0c031b92e
tree1d648c3d737f9de71937da7085692cee287dfea2
parent6ff06729c22ec0b7498d900d79cc88cfb8aceaeb
btrfs: check commit root generation in should_ignore_root

Previously we would set the reloc root's last snapshot to transid - 1.
However there was a problem with doing this, and we changed it to
setting the last snapshot to the generation of the commit node of the fs
root.

This however broke should_ignore_root().  The assumption is that if we
are in a generation newer than when the reloc root was created, then we
would find the reloc root through normal backref lookups, and thus can
ignore any fs roots we find with an old enough reloc root.

Now that the last snapshot could be considerably further in the past
than before, we'd end up incorrectly ignoring an fs root.  Thus we'd
find no nodes for the bytenr we were searching for, and we'd fail to
relocate anything.  We'd loop through the relocate code again and see
that there were still used space in that block group, attempt to
relocate those bytenr's again, fail in the same way, and just loop like
this forever.  This is tricky in that we have to not modify the fs root
at all during this time, so we need to have a block group that has data
in this fs root that is not shared by any other root, which is why this
has been difficult to reproduce.

Fixes: 054570a1dc94 ("Btrfs: fix relocation incorrectly dropping data references")
CC: stable@vger.kernel.org # 4.9+
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
fs/btrfs/relocation.c