diff options
| author | Josef Bacik | 2013-03-19 17:13:25 +0100 |
|---|---|---|
| committer | Chris Mason | 2013-03-22 00:24:31 +0100 |
| commit | 835d974fabfa9bff4d173ad03c054ac2f673263f (patch) | |
| tree | 7dae22a2ff112055682e79528227814ed7023171 /fs/btrfs/volumes.c | |
| parent | Btrfs: update to use fs_state bit (diff) | |
| download | kernel-qcow2-linux-835d974fabfa9bff4d173ad03c054ac2f673263f.tar.gz kernel-qcow2-linux-835d974fabfa9bff4d173ad03c054ac2f673263f.tar.xz kernel-qcow2-linux-835d974fabfa9bff4d173ad03c054ac2f673263f.zip | |
Btrfs: handle a bogus chunk tree nicely
If you restore a btrfs-image file system and try to mount that file system we'll
panic. That's because btrfs-image restores and just makes one big chunk to
envelope the whole disk, since they are really only meant to be messed with by
our btrfs-progs. So fix up btrfs_rmap_block and the callers of it for mount so
that we no longer panic but instead just return an error and fail to mount.
Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
Diffstat (limited to 'fs/btrfs/volumes.c')
| -rw-r--r-- | fs/btrfs/volumes.c | 13 |
1 files changed, 12 insertions, 1 deletions
diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c index 5989a92236f7..2854c824ab64 100644 --- a/fs/btrfs/volumes.c +++ b/fs/btrfs/volumes.c @@ -4935,7 +4935,18 @@ int btrfs_rmap_block(struct btrfs_mapping_tree *map_tree, em = lookup_extent_mapping(em_tree, chunk_start, 1); read_unlock(&em_tree->lock); - BUG_ON(!em || em->start != chunk_start); + if (!em) { + printk(KERN_ERR "btrfs: couldn't find em for chunk %Lu\n", + chunk_start); + return -EIO; + } + + if (em->start != chunk_start) { + printk(KERN_ERR "btrfs: bad chunk start, em=%Lu, wanted=%Lu\n", + em->start, chunk_start); + free_extent_map(em); + return -EIO; + } map = (struct map_lookup *)em->bdev; length = em->len; |