Starting with version 2.41 of libcap, the output of the getcap program
changed and therefore some existing tests fail when the installed version
of libcap is >= 2.41 (the latest version available at the moment is 2.44).
The change was made by the following commit of libcap:
commit 177cd418031b1acfcf73fe3b1af9f3279828681c
Author: Andrew G. Morgan <morgan@kernel.org>
Date: Tue Jul 21 22:58:05 2020 -0700
A more compact form for the text representation of capabilities.
While this does not change anything about the supported range of
equivalent text specifications for capabilities, as accepted by
cap_from_text(), this does alter the preferred output format of
cap_to_text() to be two characters shorter in most cases. That is,
what used to be summarized as:
"= cap_foo+..."
is now converted to the equivalent text:
"cap_foo=..."
which is also more intuitive.
So add a filter to change the old format to the new one, an helper that
calls getcap with that filter, make existing tests use the new helper and
update their golden output to match the new output format of getcap.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
When using old version(such as getfattr 2.4.46) getfattr command, it
has the following output,
touch file
setfattr -n user.a file
getfattr --absolute-names -n user.a file
user.a
on new getfattr, it reports the following output,
getfattr --absolute-names -n user.a file
user.a=""
The {=""} will break the golden image, so use _getfattr to filter
the redundant ="" at the end if it has.
Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Make sure that we can run growfs to expand the realtime volume without
it blowing up. This is a regression test for the following patches:
xfs: Set xfs_buf type flag when growing summary/bitmap files
xfs: Set xfs_buf's b_ops member when zeroing bitmap/summary files
xfs: fix realtime bitmap/summary file truncation when growing rt volume
xfs: make xfs_growfs_rt update secondary superblocks
xfs: annotate grabbing the realtime bitmap/summary locks in growfs
Because the xfs maintainer realized that no, we have no tests for this
particular piece of functionality.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Chandan Babu R <chandanrlinux@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The test checks "noatime" mount option effect, which makes it reasonable
to include the test into atime test group along with generic/003 and
generic/192 tests.
The test properly depends on _require_atime and for certain filesystems
the test is not run:
[not run] atime related mount options have no effect on cifs
Signed-off-by: Vladimir Zapolskiy <vladimir@tuxera.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This test essentially creates an existing COW extent which
covers the first 1M, and then does another IO that overlaps it,
but extends beyond it. The bug was that we did not trim the
new IO to the end of the existing COW extent, and so the IO
extended past the COW blocks and corrupted the reflinked files(s).
The bug came and went upstream. It was introduced by:
78f0cc9d55cb "xfs: don't use delalloc extents for COW on files with extsize hints"
and (inadvertently) fixed as of:
36adcbace24e "xfs: fill out the srcmap in iomap_begin"
upstream, and in the 5.4 stable tree with:
aee38af574a1 "xfs: trim IO to found COW extent limit"
[Eryu: discard outputs of xfs_io when setting [cow]extsize]
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This test has specific fs block size requirements, so make sure that's
what we got before we proceed with the test.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
In Linux v5.6, f2fs added support for per-file compression. f2fs
compression can be used in combination with the existing f2fs encryption
support (a.k.a. fscrypt), in which case the compressed data is encrypted
rather than the uncompressed data.
We need to verify that the encryption is actually being done as expected
in this case. So add a test which verifies it.
For now this is a f2fs-specific test. It's possible that ext4 will
implement compression in the same way as f2fs (in which case this could
be made a generic test), but for now there are no plans for that.
This complements the existing ciphertext verification tests, e.g.
generic/548, which don't handle compression. Encryption+compression has
some unique considerations, so it requires its own test.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Daeho Jeong <daeho43@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Create the file common/f2fs, which will contain f2fs-specific utilities.
Then add a function _require_scratch_f2fs_compression(), which checks
for f2fs compression support on the scratch filesystem.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Daeho Jeong <daeho43@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Currently fscrypt-crypt-util assumes that the number of the first block
encrypted/decrypted is 0. I.e., it replicates either contents
encryption from the start of a file, or encryption of a filename.
However, to easily test compression+encryption on f2fs, we need the
ability to specify a different starting block number.
Add a --block-number option which does this.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Daeho Jeong <daeho43@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
fscrypt-crypt-util treats the "block number" part of the IV as 64-bit
when incrementing it. That's wrong for --iv-ino-lblk-32 and
--iv-ino-lblk-64, as in those cases the block number should be 32-bit.
Fix this by using the correct length for the block number.
For --iv-ino-lblk-64 this doesn't actually matter, since in that case
the block number starts at 0 and never exceeds UINT32_MAX.
But for --iv-ino-lblk-32, the hashed inode number gets added to the
original block number to produce the IV block number, which can later
wrap around from UINT32_MAX to 0. As a result, this change fixes
generic/602, though since the wraparound case isn't specifically tested
currently, the chance of failure was extremely small.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Daeho Jeong <daeho43@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
For --block-size, check for strtoul() reporting an overflow.
For --inode-number, check for strtoull() reporting an overflow.
Also, move the check for 32-bit inode numbers into a more logical place
(the place where we check the encryption format-specific limitations).
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Daeho Jeong <daeho43@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
1) If underlying filesystem is ext4, the lower overlay inodes do not
have the MSB set (e.g. file ino 8590721028 = 0x2000C0004) because
ext4 has a known inode number limit of 32bit (see ovl_can_decode_fh).
2) With nested xino feature, the nested overlay inodes have the MSB set
(e.g. file ino 9223372045445496836 = 0x80000002000C0004).
It is expected different inode numbers which casue the failure of
overlay/071, so fix this failure by removing the unneeded comparision.
Suggested-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Xiao Yang <yangx.jy@cn.fujitsu.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
It appears that the goal of this case was to test balance and
replace concurrency. But these two operations aren't meant to run
concurrently and the replace failing errors are captured in the
seqres.full output. Which are expected errors. To avoid further
confusion, this patch adds comments. The reason to keep this
test case is at the Link.
Link: https://patchwork.kernel.org/patch/11806307/
Reported-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
We have a config check for libaio headers, and don't build certain
tools if it is not present, but this one was missed.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that after replacing a device, if we run fstrim against the filesystem
we do not trim/discard allocated chunks in the new device. We verify that
allocated chunks in the new device were not trim/discarded by mounting the
new device only in degraded mode, as this is the easiest way to verify it.
This currently fails on btrfs (since kernel 5.2) and is fixed by a patch
that has the following subject:
"btrfs: fix filesystem corruption after a device replace"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
btrfs/198 is supposed to be a test for the patch
"btrfs: remove identified alien device in open_fs_devices" but this patch
was never merged in btrfs.
Remove the test from fstests' auto group, as it is constantly failing.
Signed-off-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The current xfstests doesn't support _supported_os() function, the
generic/611 always hit an error:
xfstests-dev/tests/generic/611: line 39: _supported_os: command not found
So remove the "_supported_os Linux" line directly.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Pavel Reichl <preichl@redhat.com>
Reviewed-by: Xiao Yang <yangx.jy@cn.fujitsu.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Verify hat an attempt to create a too-small device with stripe geometry,
is handled gracefully instead of hitting an assert in align_ag_geometry()
Signed-off-by: Pavel Reichl <preichl@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test an incremental send operation after doing a series of changes in a
tree such that one inode gets two hardlinks with names and locations
swapped with two other inodes that correspond to different directories,
and one of these directories is the parent of the other directory.
This currently fails on btrfs, the receive of the incremental send stream
fails. This is fixed by a patchset for btrfs which has two patches with the
following subjects:
"btrfs: send, orphanize first all conflicting inodes when processing references"
"btrfs: send, recompute reference path after orphanization of a directory"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that an incremental send operation emits the correct path for link
and rename operation after swapping the names and locations of several
inodes in a way that creates a nasty dependency of rename and link
operations. Notably one file has its name and location swapped with a
directory for which it used to have a directory entry in it.
This test currently fails but a kernel patch for it exists and has the
following subject:
"btrfs: send, orphanize first all conflicting inodes when processing references"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The fsx contains different read and write operations, especially the
AIO and general IO read/write. The fsx chooses one kind of read/write
from AIO and general IO to run. To make the logic clear, use a common
fsx_rw() function to swith between these two kinds of read/write.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
If io_submit or io_getevents fails, the do_aio_rw() won't free the
"buf" and cause memory leak.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Filipe Manana
Yang Xu
Darrick J. Wong
Vladimir Zapolskiy
Eric Sandeen
Eric Biggers
Xiao Yang
Anand Jain
Johannes Thumshirn
Zorro Lang
Pavel Reichl