_dump_err2() helper was introduced over two years ago and it broke
the error reporting from _repair_scratch_fs.
Every test that runs:
_repair_scratch_fs >> $seqres.full
and expect to fail if anything is written to stderr is not working
as intended.
Reported-by: zhangyi (F) <yi.zhang@huawei.com>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: zhangyi (F) <yi.zhang@huawei.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This adds a regression test for online resizing maximum blocks
which can trigger a BUG_ON with non-zero s_first_data_block
filesystem.
The bug was fixed by patch:
f96c3ac8dfc2 ("ext4: fix crash during online resizing")
The bug was introduced by patch:
1c6bd7173d66 ("ext4: convert file system to meta_bg if needed during
resizing")
Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Use _scratch_xfs_repair helper instead of calling xfs_repair
directly, as local.config may want to define $XFS_REPAIR_PROG
and override the default binary in the search path.
Signed-off-by: Anthony Iliopoulos <ailiopoulos@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
We found some AIO write related bugs recently, so I think a AIO
random write test is needed. By the new aio-aio-write-verify.c tool,
we can do this easily.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Verify ciphertext for v1 encryption policies that use Adiantum to
encrypt file contents and file names.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Verify ciphertext for v1 encryption policies that use AES-128-CBC-ESSIV
to encrypt file contents and AES-128-CTS-CBC to encrypt file names.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Verify ciphertext for v1 encryption policies that use AES-256-XTS to
encrypt file contents and AES-256-CTS-CBC to encrypt file names.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Introduce a function _verify_ciphertext_for_encryption_policy() which
verifies the correctness of encryption with the specified settings.
Basically, it does the following:
1. If missing any prerequisites, skip the test.
2. Create files in encrypted directories on the scratch device.
3. Unmount the scratch device and compare the actual ciphertext stored
on-disk to the ciphertext computed by the fscrypt-crypt-util program.
Both file contents and names are verified, and non-default encryption
modes are supported. Previously, non-default encryption modes were
untested by xfstests. Also, while there's an existing test generic/399
that checks that encrypted contents seem random, it doesn't actually
test for correctness, nor does it test filenames encryption.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Update _require_scratch_encryption() to support checking for kernel
support for contents and filenames encryption modes besides the default.
This will be used by some of the ciphertext verification tests.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Add a utility program that can reproduce encrypted contents and
filenames. It implements all encryption algorithms currently supported
by fscrypt (a.k.a. ext4, f2fs, and ubifs encryption), and it generates
IVs in the same way. The program takes the algorithm and master key on
the command line, and encrypts stdin to stdout.
A file nonce may also be passed on the command line, and the program
will "tweak" the encryption using this nonce in the same way the kernel
does -- either by deriving a subkey, or by including the nonce in the
IVs. The block size and padding amount may also be specified.
No dependencies are added, as all algorithms implemented from scratch.
Signed-off-by: Eric Biggers <ebiggers@google.com>
For conciseness in tests, add helper functions that wrap the xfs_io
commands 'set_encpolicy' and 'get_encpolicy'. Then update all
encryption tests to use them.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
If the filesystem doesn't support a feature that is required for the tests
to run, they will fail to execute the _cleanup function because it isn't yet
defined:
./common/rc: line 1: _cleanup: command not found
This error became more visible with commit 87a53d2e7c ("generic/{436,445}:
check falloc support").
Cc: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Luis Henriques <lhenriques@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Overlayfs introduces some complexity with regards to what path we have
to use to shut down the scratch filesystem: it's SCRATCH_MNT for regular
filesystems, but it's OVL_BASE_SCRATCH_MNT (i.e. the lower mount of the
overlay) if overlayfs is enabled. The helper works through all that, so
we might as well use it.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
So it turns out that overlayfs can't pass FS_IOC_SHUTDOWN to the lower
filesystems and so xfstests works around this by creating shutdown
helpers for the scratch fs to direct the shutdown ioctl to wherever it
needs to go to shut down the filesystem -- SCRATCH_MNT on normal
filesystems and OVL_BASE_SCRATCH_MNT when -overlay is enabled. This
means that t_open_tmpfiles cannot simply use one of the open tempfiles
to shut down the filesystem.
Commit f8f5774722 tried to "fix" this by ripping the shutdown code out,
but this made the tests useless. Fix this instead by creating a
xfstests helper to return a path that can be used to shut down the
filesystem and then pass that path to t_open_tmpfiles so that we can
shut down the filesystem when overlayfs is enabled.
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>
Commit f8f5774722 ("generic/530: fix shutdown failure of generic/530 in
overlay") improperly clears an overlayfs test failure by shutting down
the filesystem after all the tempfiles are closed, which totally defeats
the purpose of both generic/530 and xfs/501. Revert this commit so we
can fix it properly.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
There are two regressions related to balance resume:
- Kernel NULL pointer dereference at mount time
Introduced in v5.0
- Kernel BUG_ON() just after mount
Introduced in v5.1
The kernel fixes are:
"btrfs: qgroup: Check if @bg is NULL to avoid NULL pointer
dereference"
"btrfs: reloc: Also queue orphan reloc tree for cleanup to
avoid BUG_ON()"
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that an incremental send receive does not issue clone operations
that attempt to clone the last block of a file, with a size not aligned to
the filesystem's sector size, into the middle of some other file. Such
clone request causes the receiver to fail (with EINVAL), for kernels that
include commit ac765f83f1397646 ("Btrfs: fix data corruption due to
cloning of eof block"), or cause silent data corruption for older kernels.
This test is motived by a recent regression introduced in kernel 5.2-rc1,
commit 040ee6120cb6706 ("Btrfs: send, improve clone range"), and the
following patch fixes it:
"Btrfs: incremental send, fix emission of invalid clone perations"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that an incremental send with not corrupt data when the source
filesystem has the no-holes feature enabled, a file has prealloc
(unwritten) extents that start after its size and hole is punched (after
the first snapshot is made) that removes all extents from some offset up
to the file's size.
This currently fails on any kernel version starting from 3.16, and it's
by a patch titled:
"Btrfs: incremental send, fix file corruption when no-holes feature is enabled"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The maximum size for extended attribute values is 65536 (XATTR_SIZE_MAX).
Since there are filesystems that can set blksize to really big values
(CephFS for example has a default of 4M), it's easy to have this test
failing with fsetxattr returning -E2BIG.
Cc: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Luis Henriques <lhenriques@suse.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Amir Goldstein
Yang Xu
Anthony Iliopoulos
Qu Wenruo
Zorro Lang
Eric Biggers
Darrick J. Wong
Luis Henriques
Filipe Manana