An invalid extent inline ref type could be read from a btrfs image and it ends up with a panic[1], this set is to deal with the insane value gracefully in patch 1-2 and clean up BUG() in the code in patch 3-5.
Patch 6 adds scrub support to detect the corruption, so users can be noticed when they do scrub on a regular basis. I'm not sure in the real world what may result in this corruption, but I've seen several reports on the ML about __btrfs_free_extent saying something was missing (or simply wrong), while testing this set with btrfs-corrupt-block, I found that switching ref type could end up that situation as well, eg. a data extent's ref type (BTRFS_EXTENT_DATA_REF_KEY) is switched to (BTRFS_TREE_BLOCK_REF_KEY). Hopefully this can give people more sights next time when that happens. [1]:https://www.spinics.net/lists/linux-btrfs/msg65646.html Liu Bo (6): Btrfs: add a helper to retrive extent inline ref type Btrfs: convert to use btrfs_get_extent_inline_ref_type Btrfs: remove BUG() in btrfs_extent_inline_ref_size Btrfs: remove BUG() in print_extent_item Btrfs: remove BUG() in add_data_reference Btrfs: add sanity check of extent item in scrub fs/btrfs/backref.c | 9 +++++-- fs/btrfs/ctree.h | 5 +++- fs/btrfs/extent-tree.c | 68 ++++++++++++++++++++++++++++++++++++++++++++------ fs/btrfs/print-tree.c | 8 +++++- fs/btrfs/relocation.c | 20 ++++++++++++--- fs/btrfs/scrub.c | 43 +++++++++++++++++++++++++++++++ 6 files changed, 139 insertions(+), 14 deletions(-) -- 2.9.4 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
