btrfs-progs can't mount space_cache=v2 filesystems read-write, which is
why the compat bit wasn't added to the supported mask in the first
place. Remove it.
Signed-off-by: Omar Sandoval <osandov@fb.com>
Signed-off-by: David Sterba <dsterba@suse.com>
If we discover a bad BLOCK_GROUP_ITEM_KEY with offset = 0, we'll end up looping
forever when we read the block groups in. This is due to the search for the
next block group starting at the current object + the offset. If offset is 0,
we'll just get the same key over and over and never advance. This patch
ensures that we'll advance at least one objectid per iteration.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Quite a common sense for any RAID-like multi-device setup, just in case.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
For RAID5, 2 devices setup is just RAID1 with more overhead.
For RAID6, 3 devices setup is RAID1 with 3 copies, not what most user
want.
So warn user at mkfs time for such case, and add explain in man pages.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Some tools (check, select-super, dump-super) can use the alternate
superblocks, but the options are not consistent. To make it less
confusing, change the meaning of option -s in 'dump-super' to specify
the superblock copy, instead of taking the offset.
Though this is a change in UI, the old usage is detected and the result
would be the same, no breakage in existing scripts.
Signed-off-by: David Sterba <dsterba@suse.com>
This reverts commit 31d8235410.
False report of backref mismatches, lots of messages similar to:
Incorrect local backref count on 12713984 root 5 owner 257 offset 12845056 found 1 wanted 0 back 0x7b3ed0
backpointer mismatch on [12713984 131072]
Repairing will make things worse. A fix has been proposed, but is not
finalized so we go with a revert.
Reported-by: Chris Murphy <bugzilla@colorremedies.com>
References: https://bugzilla.kernel.org/show_bug.cgi?id=155791
Signed-off-by: David Sterba <dsterba@suse.com>
The helper btrfs_super_csum_size unconditionally bugs on a bogus value,
the dump-super is supposed to dump even corrupted superblocks so this
must not happen here. Group the checsum values in the output and be more
robust agains garbage values.
Signed-off-by: David Sterba <dsterba@suse.com>
Prior to udev v190, there was no btrfs builtin helper. Installing it on
systems with an older udev will cause problems.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Add_tree_backref() can cause BUG_ON() and abort() in quite a lot of
cases, from the ENOMEM to existing tree backref records.
Change all these BUG_ON() and abort() to return proper values.
And modify all callers to handle such problems.
Reported-by: Lukas Lueg <lukas.lueg@gmail.com>
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Exposed by fuzzed image from Lukas, which contains invalid drop level
(16), causing segfault when accessing path->nodes[drop_level].
This patch will check drop level against fs tree level and
BTRFS_MAX_LEVEL to avoid such problem.
Reported-by: Lukas Lueg <lukas.lueg@gmail.com>
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Add test case image for unaligned tree block ptr.
It should lead to BUG_ON in free_extent_buffer().
Reported-by: Lukas Lueg <lukas.lueg@gmail.com>
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
[ added bko-NNN- prefix to the files ]
Signed-off-by: David Sterba <dsterba@suse.com>
Although we have enhanced read_tree_block() from a lot of different
aspects, it lacks the early bytenr/blocksize alignment check.
And the lack of such check can lead to strange use-after-free bugs, due
to the fact that alloc_extent_buffer() will free overlapping extent
buffers, and allocate new eb for the usage.
So we should not allow invalid bytenr/blocksize even passed to
btrfs_find_create_tree_block().
This patch will add such check so we won't trigger use-after-free bug
then.
Reported-by: Lukas Lueg <lukas.lueg@gmail.com>
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Reported by Lukas and the same image from him.
DATA_RELOC tree's key type is modifed to CHUNK_ITEM, causing btrfsck
interpret it as CHUNK_ITEM and cause 0 num_stripes.
Add the image to fuzz-test.
Reported-by: Lukas Lueg <lukas.lueg@gmail.com>
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
[ added bko-NNN- prefix to the files ]
Signed-off-by: David Sterba <dsterba@suse.com>
Current we only do chunk validation check at mount time.
It's good for most case, but for fuzzed or manually crafted images, we
can insert a CHUNK_ITEM key into root tree.
Since mount time check will only check chunk tree, it will not check
CHUNK_ITEM in root tree.
Even with previous key type check against leaf owner, it is still
possible to modify the leaf owner to by-pass it.
So we still need to check chunk validation before processing it.
Reported-by: Lukas Lueg <lukas.lueg@gmail.com>
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Btrfs tree implies a lot of restriction on which key types are allowed
in specific roots.
Like CHUNK_ITEM keys are only valid in chunk root.
This patch will add such check at run_next_block() for original mode.
Reported-by: Lukas Lueg <lukas.lueg@gmail.com>
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
This function is quite useful for a lot of error report.
Enhance it to support custom output other than stdout.
And export it for later btrfsck enhancement.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.com>
adduxa