aboutsummaryrefslogtreecommitdiffstats
path: root/fs/btrfs
diff options
context:
space:
mode:
authorJosef Bacik <josef@redhat.com>2011-05-31 15:33:33 -0400
committerChris Mason <chris.mason@oracle.com>2011-06-04 08:03:45 -0400
commitd132a538d258f8f52fd0cd8b5017755f4e915386 (patch)
treebf3a5e67c8eff57425dd656778b40c5aaf858f80 /fs/btrfs
parent5f3f302a6f4cb74906c05fad1d03fc5e95c7e5af (diff)
Btrfs: don't save the inode cache if we are deleting this root
With xfstest 254 I can panic the box every time with the inode number caching stuff on. This is because we clean the inodes out when we delete the subvolume, but then we write out the inode cache which adds an inode to the subvolume inode tree, and then when it gets evicted again the root gets added back on the dead roots list and is deleted again, so we have a double free. To stop this from happening just return 0 if refs is 0 (and we're not the tree root since tree root always has refs of 0). With this fix 254 no longer panics. Thanks, Signed-off-by: Josef Bacik <josef@redhat.com> Tested-by: David Sterba <dsterba@suse.cz> Signed-off-by: Chris Mason <chris.mason@oracle.com>
Diffstat (limited to 'fs/btrfs')
-rw-r--r--fs/btrfs/inode-map.c5
1 files changed, 5 insertions, 0 deletions
diff --git a/fs/btrfs/inode-map.c b/fs/btrfs/inode-map.c
index 04f7199facb4..2d0d50067a7b 100644
--- a/fs/btrfs/inode-map.c
+++ b/fs/btrfs/inode-map.c
@@ -394,6 +394,11 @@ int btrfs_save_ino_cache(struct btrfs_root *root,
394 root->root_key.objectid > BTRFS_LAST_FREE_OBJECTID)) 394 root->root_key.objectid > BTRFS_LAST_FREE_OBJECTID))
395 return 0; 395 return 0;
396 396
397 /* Don't save inode cache if we are deleting this root */
398 if (btrfs_root_refs(&root->root_item) == 0 &&
399 root != root->fs_info->tree_root)
400 return 0;
401
397 path = btrfs_alloc_path(); 402 path = btrfs_alloc_path();
398 if (!path) 403 if (!path)
399 return -ENOMEM; 404 return -ENOMEM;