Sometimes we need to test what happens when we're missing a csum for a range, so
add an option to btrfs-corrupt-block to be able to remove a csum range. Thanks,
Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
This will fix breakage, when doing chrooted receive with cloned paths
outside main subvolume.
Steps to reproduce:
$ create subvolume
$ create file
$ snapshot to snap1
$ delete file
$ snapshot to snap2
$ reflink file from snap1
$ snapsthot to snap3
$ send full snap1 | receive --chroot
$ send incremental snap2 | receive --chroot
$ send incremental snap3 | receive --chroot
The last step would fail with:
Chroot to /mnt/recvdir
At snapshot snap3
ERROR: failed to open /recvdir/snap1/file. No such file or directory
Signed-off-by: Emil Karlson <jekarlson@gmail.com>
[added reproducer]
Signed-off-by: David Sterba <dsterba@suse.cz>
Add the following tree block check to avoid memory corruption on hostile
image:
1) Check level.
Level >= BTRFS_MAX_LEVEL won't be read out.
2) Nritems.
For nr_items > max_nritems, the tree_block won't be read out.
Max nritems is calculated in a easy method.
For node, it's straightforward, just (nodesize - header size) /
(btrfs_key_ptr)
For leaf, (nodesize - header size) / (btrfs_item), as btrfs support zero
item size
This fixes 3 kernel bugs: BZ#97171, BZ#97191, BZ#97271.
Reported-by: Lukas Lueg <lukas.lueg@gmail.com>
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
First fix == bashism, as that is not accepted by e.g. Debian/Ubuntu
dash.
Secondly shift OPTIND, such that last parameter is checked to exist.
Signed-off-by: Dimitri John Ledkov <dimitri.j.ledkov@intel.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
For DUP profile, the num_stripes should be 2 not 1.
This causes btrfs offline tool fails on valid image.
Also, num_stripes check is too restrict for btrfsck self test,
as there is some image in degraded mode, so modify it to allow degraded
chunk.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Adds extra check when reading a chunk item:
1) Check chunk type.
Don't allow any unsupported type/profile bit.
2) Check num_stripes
Any chunk item should contain at least one stripe.
For system chunk, the chunk item size(calculated by btrfs_stripe size *
(num_stripes - 1) + btrfs_chunk size) should not exceed
BTRFS_SYSTEM_CHUNK_SIZE(2048).
For normal chunk, the chunk item size(calculated) should match the chunk
item size.
3) Check num_stripes/sub_stripes against chunk profile.
Num_stripes/sub_stripes must meet its lower limit for its chunk profile.
Reported-by: Lukas Lueg <lukas.lueg@gmail.com>
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Current btrfs only support CRC32 as checksum algorithm.
But in btrfs_csum_sizes array, we have an extra 0 at tail, causing
csum_type 1 can still be considered as supported csum type.
Fix it by removing the tailing 0.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
This function does all the needed things for changing filesystem uuid.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
These two functions will write flags to all supers before and after
fsid/chunk tree id change, informing kernel not to mount a inconsistent
fs.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
[removed chunk tree super flag]
Signed-off-by: David Sterba <dsterba@suse.cz>
This is the function which iterates all metadata extents and changes
their fsid.
This function also does it without transaction.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
This function is used to change fsid and chunk_tree_uuid of a node/leaf.
The function does it without transaction protection.
This is the basis of offline uuid change.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Export write_tree_block() function and allow it write extent without
transaction.
This provides the basis for later uuid change function.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Now open_ctree will exit if it found the superblock is marked
CHANGING_FSID, except given IGNORE_FSID open ctree flags.
Kernel will do the same thing later.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
[removed the chunk tree flag, reworded the error message]
Signed-off-by: David Sterba <dsterba@suse.cz>
Use the new __print_readable_flag() to implement
print_readable_super_flag().
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
[removed the chunk tree flag]
Signed-off-by: David Sterba <dsterba@suse.cz>
Now add a new unified __print_readable_flag() function to implement
print_readable_incompat_flag().
This makes later extension for human readable flags easier.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Add the super flag to inform kernel not to mount a filesystem wich fsid
change is in progress.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
[removed the chunk tree flag]
Signed-off-by: David Sterba <dsterba@suse.cz>
It's res instead of ret, wrong error message could be prointed in case
of error.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
After Patch:
remove BTRFS_SCAN_PROC scan method
There isn't any consumer for btrfs_scan_block_devices() so delete it.
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
In copy_inode_rec(), a shallow copy happens on rec->holes rb_root.
So for shared inode case, new rec->holes still points to old rb_root,
and when the old inode record is freed, the new inode_rec->holes will
points to garbage and cause segfault when we try to free new
inode_rec->holes.
Fix it by calling copy_file_extent_holes() to do deep copy.
Reported-by: Eric Sandeen <sandeen@redhat.com>
Reported-by: Filipe David Manana <fdmanana@gmail.com>
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
The file sys/acl.h is part of libacl and if the development package is
not installed, build of btrfs-convert fails.
We do not link against libacl nor use the functions provided by libacl. The
ACL_* values are directly read from the extN data, so it's more part of the
on-disk format rather than an interface to libacl.
The dependency on libacl is completely dropped.
Reported-by: Hugo Mills <hugo@carfax.org.uk>
Signed-off-by: David Sterba <dsterba@suse.cz>
Symlink restore needs this, but the cut&paste became too complicated.
Simplify everything.
Signed-off-by: Dan Merillat <dan.merillat@gmail.com>
[message wording adjustments]
Signed-off-by: David Sterba <dsterba@suse.cz>
The logic around return value has changed in the metadata restore
patches. The return value from btrfs_search_slot may remain non-zero and
is returned. This is incorrectly interpreted as an error.
Signed-off-by: David Sterba <dsterba@suse.cz>
The chroot action seems important enough to be printed unconditionally
and without the verbose option that prints way too much information.
Signed-off-by: David Sterba <dsterba@suse.cz>
make[1]: Nothing to be done for `all'.
cmds-check.c: In function ‘del_file_extent_hole’:
cmds-check.c:289:26: warning: ‘prev.start’ may be used uninitialized in this function
cmds-check.c:289:26: warning: ‘prev.len’ may be used uninitialized in this function
cmds-check.c:290:26: warning: ‘next.start’ may be used uninitialized in this function
cmds-check.c:290:26: warning: ‘next.len’ may be used uninitialized in this function
Reported-by: Anand Jain <Anand.Jain@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
This patch forces btrfs receive to issue chroot before
parsing the btrfs stream using command-line flag -C
to confine the process and minimize damage that could
be done via malicious btrfs stream.
Signed-off-by: Lauri Võsandi <lauri.vosandi@gmail.com>
[added long option variant, added docs]
Signed-off-by: David Sterba <dsterba@suse.cz>
As long as the inode is intact, the file metadata can be restored.
Directory data is restored at the end of search_dir. Errors are
checked and returned, unless ignore_errors is requested.
Signed-off-by: Dan Merillat <dan.merillat@gmail.com>
[minor style fixes, error message updates]
Signed-off-by: David Sterba <dsterba@suse.cz>
The BTRFS_IOC_RESIZE ioctl returns 0 on success, negative for POSIX
errors, and positive for btrfs-specific errors.
If resize fails with a btrfs-specific error, decode the error and
report it. If we can't decode the error, report its numeric value so
that the userspace tool is not instantly useless when a new error code
is defined in the kernel.
Exit with non-zero status on any resize error. This is very important
for scripts that will shrink the underlying storage when btrfs reports
success!
Signed-off-by: Zygo Blaxell <ce3g8jdj@umail.furryterror.org
Signed-off-by: David Sterba <dsterba@suse.cz>
We have this check in the kernel but not in userspace, which makes fsck
fail when we wouldn't have a problem in the kernel. This was meant to
catch this case because it really isn't good, unfortunately it will
require a design change to fix in the kernel so in the meantime add this
check so we can be sure our tests only catch real problems. Thanks,
Signed-off-by: Josef Bacik <jbacik@fb.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
PPC64 arch use such following IOC values "
\#define _IOC_NONE 1U
\#define _IOC_READ 2U
\#define _IOC_WRITE 4U
" comparing to the default IOC values "
\#define _IOC_NONE 0U
\#define _IOC_READ 2U
\#define _IOC_WRITE 1U"
This means the value "_IOW*" will be negative when we store it in the int
variables. Such as the "BTRFS_IOC_QGROUP_CREATE", it will be "0x4010942e" on
X86_64, but "0x8010942e" on PPC64.
Notice that the IOC values are the "unsigned long" type, so we use the
"unsigned long" to store it, and this can insure the comparison between the
variable and BTRFS_IOC_* valid.
Signed-off-by: George Wang <xuw2015@gmail.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
[manpage states that it's int, kernel uses unsigned int, glibc wants
unsigned long int]
Tested-by: Chandan Rajendra <chandan@linux.vnet.ibm.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Josef Bacik