Fuzzed image bko-156811-bad-parent-ref-qgroup-verify.raw causes qgroup
to report -ENOMEM.
But the fact is, such image is heavily damaged so there is no valid root
item for the extent tree.
Normal extent tree key in root tree should be (EXTENT_TREE ROOT_ITEM 0),
while in that fuzzed image, we got (EXTENT_TREE EXXTENT_DATA SOME_NUMBER).
It's btrfs_find_last_root() that only checks the objectid, not caring
about the key type leading to such problem.
Fix it by doing extra check on key type.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
[ edit changelog ]
Signed-off-by: David Sterba <dsterba@suse.com>
In btrfs_find_last_root before returning with -ENOENT (if root item is
not found) free path and also remove btrfs_release_path before
btrfs_free_path because btrfs_free_path anyway calls it.
Signed-off-by: Rakesh Pandit <rakesh@tuxera.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>
We were bug_on(slot == 0), but that's just obnoxious, return -ENOENT so we can
handle the situation properly. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
In files copied from the kernel, mark many functions as static,
and remove any resulting dead code.
Some functions are left unmarked if they aren't static in the
kernel tree.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
Port of commit b3b4aa7 to userspace.
parameter tree root it's not used since commit
5f39d397dfbe140a14edecd4e73c34ce23c4f9ee ("Btrfs: Create extent_buffer
interface for large blocksizes")
This gets userspace a tad closer to kernelspace by removing
this unused parameter that was all over the codebase...
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
Also remove unused path in extent-tree.c:finish_current_insert().
Signed-off-by: Filipe David Borba Manana <fdmanana@gmail.com>
Reviewed-by: Miao Xie <miaox@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
Remove some commented-out & #if 0'd code:
* close_blocks()
* btrfs_drop_snapshot()
* btrfs_realloc_node()
* btrfs_find_dead_roots()
There are still some #if 0'd functions in there, but I'm hedging
on those for now, they have been copied to cmds-check.c and I want
to see if they can be brough back into ctree.c eventually.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
This addresses the same issue as did:
2bd1169 btrfs-progs: root_item generation_v2 is out of sync after btrfsck
but rather than optionally updating generation_v2 based
on the size of the existing item, increase the size of the
item as needed, and unconditionally set generation_v2.
This matches the kernel code, and keeping things in sync is a
Good Thing.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
With this integration branch commit in place:
2bd1169 btrfs-progs: root_item generation_v2 is out of sync after btrfsck
I started seeing generation mismatch messages from the kernel
at mount time, after a fresh mkfs(!):
btrfs: mismatching generation and generation_v2 found in root item...
This is because the code which emits the warning does not do so if
there is a mismatch but generation_v2 is 0; the above commit began
setting generation_v2 to something non-zero, so the warning was emitted.
The reason there is a mismatch at all is because mkfs.btrfs calls
create_data_reloc_tree(), which copies a root, and then calls
btrfs_set_root_generation(), bumping the original copied generation.
But nothing updated generation_v2 to match on the way to disk.
Fix this by updating generation_v2 in btrfs_insert_root(),
as is done in the kernel.
This is safe because it's a new root created by userspace, so
the btrfs_root_item is guaranteed to be big enough to contain
generation_v2.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Instead of doing a BUG_ON() if we fail to find the last fs root just return
an error so the callers can deal with it how they like. Also we need to
actually return an error if we can't find the latest root so that the error
handling works. With this btrfsck was able to deal with a file system that
was missing a root item but still had extents that referred back to the
root. Thanks,
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
This patch updates the ext3 to btrfs converter for the new
disk format. This mainly involves changing the convert's
data relocation and free space management code. This patch
also ports some functions from kernel module to btrfs-progs.
Thank you,
Signed-off-by: Yan Zheng <zheng.yan@oracle.com>
We get lots of warnings of the flavor:
utils.c:441: warning: format '%Lu' expects type 'long long unsigned int' but argument 2 has type 'u64'
And thanks to -Werror, the build fails. Clean up these printfs
by properly casting the arg to the format specified.
Signed-off-by: Alex Chiang <achiang@hp.com>
Qu Wenruo