On a 32bit host the split qgroupid is wrong due to the way the numbers
are passed to the formatter as variable length arguments. The level is
u16, promoted to int and then parsed as u64. This means that the values
are shifted and some stack data are printed instead.
Example error messages from yast2-bootloader:
SystemCmd.cc(addLine):569 Adding Line 7 " "qgroupid": "21474836480/23885859321282560","
The value 21474836480 = 0x5000000 is 0x5 shifted by 32 bits,
23885859321282560 is 0x54dc1000000000 and shifting by 32 does not
lead to a valid value which should be 0 in this case.
Bugzilla: https://bugzilla.suse.com/show_bug.cgi?id=1209136
Signed-off-by: David Sterba <dsterba@suse.com>
The tabular output prints the same value for all columns:
# btrfs device stats /srv/btrfs-data
[/dev/sdc1].write_io_errs 0
[/dev/sdc1].read_io_errs 0
[/dev/sdc1].flush_io_errs 0
[/dev/sdc1].corruption_errs 0
[/dev/sdc1].generation_errs 0
[/dev/sdb1].write_io_errs 7489899
[/dev/sdb1].read_io_errs 3751023
[/dev/sdb1].flush_io_errs 117
[/dev/sdb1].corruption_errs 68
[/dev/sdb1].generation_errs 25
# btrfs device stats -T /srv/btrfs-data
Id Path Write errors Read errors Flush errors Corruption errors Generation errors
-- --------- ------------ ----------- ------------ ----------------- -----------------
1 /dev/sdc1 0 0 0 0 0
2 /dev/sdb1 25 25 25 25 25
The table_printf has a fixed list of columns and should not iterate over
them. Only check if some of the value is set and return error.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=217045
Issue: #585
Signed-off-by: David Sterba <dsterba@suse.com>
As reported in #588, build fails on some microarchitectures when the
blake2 macros do not coverall combinations. Extend the build tests and
add some uarchs to test.
Signed-off-by: David Sterba <dsterba@suse.com>
On recent x86-64 system with march=native|<cpu>|<microarchitecture
level> gcc/clang will automatically define all the available vector
extensions macros. crypto/blake2-config.h then correctly set all the
HAVE_<EXTENSION> macros.
crypto/blake2-round.h then checks the HAVE_<EXTENSION> macros for
including further headers:
#if defined(HAVE_SSE41)
#include "blake2b-load-sse41.h"
#else
#include "blake2b-load-sse2.h"
#endif
which is wrong. On recent systems it always results in including
blake2b-load-sse41.h. crypto/blake2-round.h itself is included by
crypto/blake2b-sse2.c and now we have a SSE2/SSE4.1 code mixing
resulting in the incompatible type for argument build errors described
in #589.
The idea is to remove the lines above from crypto/blake2-round.h and put
the includes directly into crypto/blake2b-sse2.c and
crypto/blake2b-sse41.c respectively.
Note this slightly diverges from the upstream BLAKE2 sources.
Pull-request: #591
Author: Tino Mai <mai.tino@gmail.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Otherwise, the following error occurs:
| In file included from crypto/blake2b-sse2.c:30:
| crypto/blake2b-sse2.c: In function 'blake2b_compress_sse2':
| crypto/blake2b-round.h:32:22: warning: implicit declaration of function '_mm_shuffle_epi8'; did you mean '_mm_shuffle_epi32'? [-Wimplicit-function-declaration]
| 32 | : (-(c) == 24) ? _mm_shuffle_epi8((x), r24) \
| | ^~~~~~~~~~~~~~~~
Note: it's not yet clear what affects this build failure as it otherwise
builds in the tested configurations (gcc/clang, arch, distro), but it
apparently fixes the build in some environments.
Pull-request: #588
Signed-off-by: Alexander Kanavin <alex@linutronix.de>
[ add note ]
Signed-off-by: David Sterba <dsterba@suse.com>
Add config for crypto backends (they could fail for the static targets
due to missing static libraries). Reiserfs is not tested and it slowly
disappears from distros.
Signed-off-by: David Sterba <dsterba@suse.com>
Add the libaries and update script so additional configure parameters
can be passed. Also enable backtrace so it's closer to the defaults.
Signed-off-by: David Sterba <dsterba@suse.com>
Add the libaries and update script so additional configure parameters
can be passed. Also enable backtrace so it's closer to the defaults.
Only the libsodium is enabled and verified to build, libgcrypt has
sufficient version on 8 but configure does not detect it for some
reason. Libkca is old on both.
Signed-off-by: David Sterba <dsterba@suse.com>
Add the libaries and update script so additional configure parameters
can be passed. Also enable backtrace and libudev so it's closer to the
defaults.
Leap 15.3 properly builds only with libsodium, 15.4 with libgcrypt and
libsodium. Libkcapi is old on both.
Signed-off-by: David Sterba <dsterba@suse.com>
Add the libaries and update script so additional configure parameters
can be passed. Also enable backtrace and libudev so it's closer to the
defaults.
Signed-off-by: David Sterba <dsterba@suse.com>
Add entries for all crypto backends and test the ones that match what
was configured with --with-crypto.
Signed-off-by: David Sterba <dsterba@suse.com>
Change what hash-speedtest benchmarks according to the
--with-crypto=backend option. Until now it would run the same version
under different names inherited from the builting.
At configure time detect availability of all backends and define all
macros.
Signed-off-by: David Sterba <dsterba@suse.com>
The build fails with crypto backends other than builtin, the
initializers cannot be reached as they're ifdef-ed out. Move
hash_init_accel under the right condition and delete the
algorithm-specific initializers as they're used only by the hash test
and that can simply call hash_init_accel to set the implementation.
All the -m flags need to be detected at configure time and the flag used
for ifdef (HAVE_CFLAG_m*), not the actual feature defined by compiler as
the dispatcher function is not built with the -m flags.
The uname check for x86_64 must be dropped so on i386/i586 we can still
build accelerated version.
Signed-off-by: David Sterba <dsterba@suse.com>
With the growing list of global option we need to print them somewhere
in the help text and document them.
Signed-off-by: David Sterba <dsterba@suse.com>
Add an option to set the log level exactly instead of -vv and similar.
The combined option may not be known to all users as reported and one
option for the level is for convenience.
Issue: #570
Signed-off-by: David Sterba <dsterba@suse.com>
After previous change to usage() that now has the return code, there's
no purpose of the print_usage() wrapper so it can be removed.
Signed-off-by: David Sterba <dsterba@suse.com>
[BUG]
Test case cli/017 fails with the following errors:
[TEST] cli-tests.sh
[TEST/cli] 017-fi-show-missing
didn't find exact missing device
test failed for case 017-fi-show-missing
[CAUSE]
After kernel commit cb3e217bdb39 ("btrfs: use btrfs_dev_name() helper to
handle missing devices better"), all dev info ioctl call on missing
device would only return "<missing disk>" for its path.
Thus "btrfs filesystem show" would never report detailed device path for
missing disks.
[FIX]
Instead of relying on the device path, change the check to rely on devid
instead.
Now cli/017 can properly pass.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
[BUG]
Currently cli/009 test case failed with different exit number:
====== RUN CHECK /home/adam/btrfs-progs/btrfstune --help
usage: btrfstune [options] device
[...]
failed: /home/adam/btrfs-progs/btrfstune --help
test failed for case 009-btrfstune
[CAUSE]
In tune/main.c, we have the following call on usage():
static void print_usage(int ret)
{
usage(&tune_cmd);
exit(ret);
}
However usage() itself would always call exit(1):
void usage(const struct cmd_struct *cmd)
{
usage_command_usagestr(cmd->usagestr, NULL, 0, true, true);
exit(1);
}
This makes prevents any caller of usage() to modify its exit number.
[FIX]
Add a new argument @error for print_usage(), so we can properly return 0
for -h/--help usage.
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
The kernel commit a26d60dedf9a ("btrfs: sysfs: add devinfo/fsid to
retrieve actual fsid from the device") introduced a sysfs interface
to access the device's fsid from the userspace. This is a more
reliable method to obtain the fsid compared to reading the
superblock, and it even works if the device is not present.
Additionally, this sysfs interface can be read by non-root users.
Therefore, it is recommended to utilize this new sysfs interface to
retrieve the fsid.
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: David Sterba <dsterba@suse.com>
