summaryrefslogtreecommitdiff
path: root/fs
diff options
context:
space:
mode:
authorJosef Bacik <josef@toxicpanda.com>2020-03-11 11:21:44 -0400
committerDavid Sterba <dsterba@suse.com>2020-03-23 17:01:56 +0100
commitb39c8f5a393e7fc4459ac2aa1582409839eae2f6 (patch)
treec5b4099483d36bdcf36fdf29de04e77d9d1dd9ca /fs
parent0a8068a3dd4294ebd8b99969cdc6ccde0f944ba6 (diff)
downloadlinux-rpi-b39c8f5a393e7fc4459ac2aa1582409839eae2f6.tar.gz
linux-rpi-b39c8f5a393e7fc4459ac2aa1582409839eae2f6.tar.bz2
linux-rpi-b39c8f5a393e7fc4459ac2aa1582409839eae2f6.zip
btrfs: fix ref-verify to catch operations on 0 ref extents
While debugging I noticed I wasn't getting ref verify errors before everything blew up. Turns out it's because we don't warn when we try to add a normal ref via btrfs_inc_ref() if the block entry exists but has 0 references. This is incorrect, we should never be doing anything other than adding a new extent once a block entry drops to 0 references. Signed-off-by: Josef Bacik <josef@toxicpanda.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
Diffstat (limited to 'fs')
-rw-r--r--fs/btrfs/ref-verify.c9
1 files changed, 9 insertions, 0 deletions
diff --git a/fs/btrfs/ref-verify.c b/fs/btrfs/ref-verify.c
index 454a1015d026..7887317033c9 100644
--- a/fs/btrfs/ref-verify.c
+++ b/fs/btrfs/ref-verify.c
@@ -803,6 +803,15 @@ int btrfs_ref_tree_mod(struct btrfs_fs_info *fs_info,
kfree(ref);
kfree(ra);
goto out_unlock;
+ } else if (be->num_refs == 0) {
+ btrfs_err(fs_info,
+ "trying to do action %d for a bytenr that has 0 total references",
+ action);
+ dump_block_entry(fs_info, be);
+ dump_ref_action(fs_info, ra);
+ kfree(ref);
+ kfree(ra);
+ goto out_unlock;
}
if (!parent) {