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>
NFSv4.2 supports reflink but does not support FIBMAP nor FIEMAP.
These 4 tests about file content can pass on NFSv4.2, but filefrag
complaints :
+/mnt/testarea/scratch/test-542/file2: FIBMAP unsupported
which is breaking golden output.
Signed-off-by: Murphy Zhou <xzhou@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Run fsstress, fsync every file and directory, simulate a power failure and
then verify that all files and directories exist, with the same data and
metadata they had before the power failure.
This test has found already 2 bugs in btrfs, that caused mtime and ctime of
directories not being preserved after replaying the log/journal and loss
of a directory's attributes (such a UID and GID) after replaying the log.
The patches that fix the btrfs issues are titled:
"Btrfs: fix wrong ctime and mtime of a directory after log replay"
"Btrfs: fix fsync not persisting changed attributes of a directory"
Running this test 1000 times:
- on xfs, no issues were found
- on ext4 it has resulted in about a dozen journal checksum errors (on a
5.0 kernel) that resulted in failure to mount the filesystem after the
simulated power failure with dmflakey, which produces the following
error in dmesg/syslog:
[Mon May 13 12:51:37 2019] JBD2: journal checksum error
[Mon May 13 12:51:37 2019] EXT4-fs (dm-0): error loading journal
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
commit 34081087 adds more sanity to seek_sanity_test() to prevent
a lseek() implementation regression from being ignored, and a
hardcoded whitelist is maintained to distinguish whether a
filesystem type only supports non-default behavior of SEEK_HOLE
or not.
In commit 34081087, NFS is listed in this whitelist, that is, NFS
is thought supporting non-default behavior only. However as far as
I know, nfsv2 and nfsv3 only support default behavior of SEEK_HOLE
(that is, always returning EOF) in linux.
On the other hand, xfstests uses "mount -t nfs ..." to mount a
NFS mount point. Normally the mount point is mounted as nfsv4,
but it can be mounted mandatorily as nfsv3 if we specify
"Nfsvers=3" in /etc/nfsmount.conf. In this case, a series of
tests fail (including generic/285, generic/448, generic/490, etc.)
with error message "Default behavior is not allowed. Aborting."
So I just make some special handling for NFS in
_fstyp_has_non_default_seek_data_hole(), that is, default behavior
of SEEK_HOLE is acceptable for nfsv2 and nfsv3.
Signed-off-by: Jeffle Xu <jefflexu@linux.alibaba.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Anthony Iliopoulos
Qu Wenruo
Zorro Lang
Eric Biggers
Darrick J. Wong
Luis Henriques
Filipe Manana
Murphy Zhou
Jeffle Xu