summaryrefslogtreecommitdiffstats
path: root/fs
diff options
context:
space:
mode:
authorJosef Bacik <josef@redhat.com>2011-12-13 16:04:54 -0500
committerJosef Bacik <josef@redhat.com>2011-12-15 11:04:24 -0500
commite65cbb94e036058128a5dec6398be2fd64cf88ba (patch)
tree1ad4bba788cc283545d1e240c529eadeab7155aa /fs
parentee4d89f0c4967c624c92516fcc37b41069bfdc23 (diff)
downloadop-kernel-dev-e65cbb94e036058128a5dec6398be2fd64cf88ba.zip
op-kernel-dev-e65cbb94e036058128a5dec6398be2fd64cf88ba.tar.gz
Btrfs: only set cache_generation if we setup the block group
A user reported a problem booting into a new kernel with the old format inodes. He was panicing in cow_file_range while writing out the inode cache. This is because if the block group is not cached we'll just skip writing out the cache, however if it gets dirtied again in the same transaction and it finished caching we'd go ahead and write it out, but since we set cache_generation to the transid we think we've already truncated it and will just carry on, running into cow_file_range and blowing up. We need to make sure we only set cache_generation if we've done the truncate. The user tested this patch and verified that the panic no longer occured. Thanks, Reported-and-Tested-by: Klaus Bitto <klaus.bitto@gmail.com> Signed-off-by: Josef Bacik <josef@redhat.com>
Diffstat (limited to 'fs')
-rw-r--r--fs/btrfs/extent-tree.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/fs/btrfs/extent-tree.c b/fs/btrfs/extent-tree.c
index 4eb4d27..8603ee4 100644
--- a/fs/btrfs/extent-tree.c
+++ b/fs/btrfs/extent-tree.c
@@ -2822,7 +2822,7 @@ out_free:
btrfs_release_path(path);
out:
spin_lock(&block_group->lock);
- if (!ret)
+ if (!ret && dcs == BTRFS_DC_SETUP)
block_group->cache_generation = trans->transid;
block_group->disk_cache_state = dcs;
spin_unlock(&block_group->lock);
OpenPOWER on IntegriCloud