Generic/484 tests functionality that isn't really related to file
systems, and has failed every since it was added. Remove it as it
serves no puropse in xfstests.
[Eryu: also remove src/t_locks_execve.c and its entries in
src/Makefile and .gitignore]
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This allows us to run all those tests which simulate disk failures
using dmerror.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Add a test which tests adding a key to a filesystem's fscrypt keyring
via an "fscrypt-provisioning" keyring key. This is an alternative to
the normal method where the raw key is given directly.
For more details, see kernel commit 93edd392cad7 ("fscrypt: support
passing a keyring key to FS_IOC_ADD_ENCRYPTION_KEY").
This test depends on an xfs_io patch which adds the '-k' option to the
'add_enckey' command, e.g.:
xfs_io -c "add_enckey -k KEY_ID" MOUNTPOINT
This test is skipped if the needed kernel or xfs_io support is absent.
This has been tested on ext4, f2fs, and ubifs.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
For some encryption tests it's helpful to always use the same key so
that the test's output is always the same.
generic/580 already defines such a key, so move it into common/encrypt
so that other tests can use it too.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
generic/581 passes for me, but Murphy Zhou reported that it started
failing for him. The part that failed is the part that sets the key
quota to the fsgqa user's current number of keys plus 5, then tries to
add 6 filesystem encryption keys as the fsgqa user. Adding the 6th key
unexpectedly succeeded.
What I think is happening is that because the kernel's keys subsystem
garbage-collects keys asynchronously, the quota may be freed up later
than expected after removing fscrypt keys. Thus the test is flaky.
It would be nice to fix this in the kernel, but unfortunately there
doesn't seem to be an easy fix, and the keys subsystem has always worked
this way. And it seems unlikely to cause real-world problems, as the
keys quota really just exists to prevent denial-of-service attacks.
So, for now just try to make the test more reliable by:
(1) Reduce the scope of the modified keys quota to just the part of the
test that needs it.
(2) Before getting the current number of keys for the purpose of setting
the quota, wait for any invalidated keys to be garbage-collected.
Tested with a kernel that has a 1 second sleep hacked into the beginning
of key_garbage_collector(). With that, this test fails before this
patch and passes afterwards.
Reported-by: Murphy Zhou <xzhou@redhat.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Acked-by: Murphy Zhou <xzhou@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Add a similar test to the existing one but with a file that has a
hardlink as well. This is motivated by a bug found in btrfs where
a fsync on a file that has the old name of another file results
in the logging code to hit an infinite loop. The patch that fixes
the bug in btrfs has the following subject:
"Btrfs: fix infinite loop during fsync after rename operations"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Addition of fs-specific timestamp range checking was added
in 188d20bcd1eb ("vfs: Add file timestamp range support").
Add a check for whether the kernel supports the limits check
before running the associated test.
Based on an off-list discussion, we use a simpler interim approach
until fsinfo syscall would provide fs timestamp limits info.
This isn't perfect, but works for filesystems expiring in 2038.
Suggested-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Correct the logic in this test that detects failed scsi_debug
initializations. Downgrade the reaction to _notrun since the filesystem
under test did not fail, just our mockup disk.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
When I test this case on xfs, it may fail as below:
--------------------------------------------
=== link SCRATCH_MNT/A/foo SCRATCH_MNT/bar with fsync SCRATCH_MNT/A ===
+umount: /mnt/xfstests/scratch: target is busy.
+ (In some cases useful info about processes that use
+ the device is found by lsof(8) or fuser(1))
---------------------------------------------
It fails because somethings is still using the fs when we call sync and then
try to unmount it. We can simply remove sync as the unmount is supposed to
persist the file/directory removals.
Signed-off-by: Yang Xu <xuyang2018.jy@cn.fujitsu.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Tests need the exact operations to reproduce some issues by
--replay-ops so skip tests rather than one operation if a required
operation/flag in tests is not supported.
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>
IMHO, if kernel doesn't supprt realtime, we should skip test.
So add it. Also, when we use _scratch_mkfs on xfs, we will get
the following error:
mkfs failed with extra mkfs options added to "-bsize=4096" by test 590 **
This failure occurs because we have used "export XFS_MKFS_OPTIONS=
${XFS_MKFS_OPTIONS:=-bsize=4096}" in common/config, we don't need to
set it again in extra_options, so remove it.
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>
Verify ciphertext for v2 encryption policies that use the IV_INO_LBLK_64
flag and 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>
The generic/386 test was checking the "Available" field when it
should have been checking the "1k-blocks" field, which represents
the project quota's hard limit. On xfs, an empty directory takes no
space, so it doesn't matter. But for ext4, an empty directory still
takes 4k (or whatever the file system's block size happens to be):
Filesystem 1K-blocks Used Available Use% Pathname
/dev/vdc 512000 4 511996 0% /vdc/test
This causes generic/386 to falsely fail.
This fix is needed to fix generic/386 from failing on ext4:
hard limit 524283904 bytes, expected 524288000
[Eryu: Used $(NF-4) instead of $2 as Eric Sandeen and Yang Xu
suggested]
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This reverts commit 37520a314b.
This commit has been reported to regress, at least, xfs/139 and
btrfs/09[58]. Let's revert it for now.
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Without this check the test will fail with message:
fallocate: Operation not supported
Instead, with this _require_xfs_io_command, the test will be skipped
instead if falloc isn't supported.
Signed-off-by: Luis Henriques <lhenriques@suse.com>
Reviewed-by: Omar Sandoval <osandov@fb.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Andreas Grünbacher reports that on the two filesystems that support
iomap directio, it's possible for splice() to return -EAGAIN (instead of
a short splice) if the pipe being written to has less space available in
its pipe buffers than the length supplied by the calling process.
This is a regression test to check for correct operation. Kernel
needs commit 3253d9d09337 ("splice: only read in as much information
as there is pipe buffer space") to pass.
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>
The only XFS-specific part of this test is the setup, so we can make
the rest a generic test. It's slow, though, as it needs to write 8GB
to convert a big unwritten extent to written.
Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This's a functional test case for mount --move operation, it verifies
below semantics:
---------------------------------------------------------------------------
| MOVE MOUNT OPERATION |
|**************************************************************************
|source(A)->| shared | private | slave | unbindable |
| dest(B) | | | | |
| | | | | | |
| v | | | | |
|**************************************************************************
| shared | shared | shared | shared & slave | invalid |
| | | | | |
|non-shared| shared | private | slave | unbindable |
***************************************************************************
NOTE: moving a mount residing under a shared mount is invalid.
This case uses fsstress to produce a little random load, to make
sure basic operations won't break the the moved mountpoints.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that if we clone part of an extent from a file to itself at a
different offset, fsync it, rewrite (COW) part of the extent from the
former offset, fsync it again, power fail and then mount the filesystem,
we are able to read the whole file and it has the correct data.
This is motivated by a bug found in btrfs which is fixed by a kernel patch
that has the following subject:
"Btrfs: fix missing data checksums after replaying a log tree"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
generic/551 sometimes fails because it's killed by OOM killer.
That is because aio-dio-write-verify, which is called by
generic/551, tries to allocate memory even though the total
allocation size exceeds the available memory.
aio-dio-write-verify allocates memory according to the 'size'
argument, and generic/551 passes the argument.
Stop adding the argument when the total size is exceeds
the available memory.
Signed-off-by: Masayoshi Mizuma <m.mizuma@jp.fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Regression test to ensure that dquots are attached to the inode when
we're performing unwritten extent conversion after a directio write
and the extent mapping btree splits.
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>
Christoph Hellwig
Theodore Ts'o
Eric Biggers
Filipe Manana
Deepa Dinamani
Darrick J. Wong
Yang Xu
Xiao Yang
Eryu Guan
Luis Henriques
Kusanagi Kouichi
Omar Sandoval
Zorro Lang
Masayoshi Mizuma