Add a new _require function for hardlinks, to test hardlink support
in all tests which need it.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Consistently use _require_symlinks on all generic tests which
create a symlink when they run.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Generally these tests are not restricted to one device or the other;
testing the test device will suffice to determine the capability
but it doesn't need to be named that way.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The rationale behind the proposed changes is to correct and improve
granularity of some generic tests, so it becomes possible to control
lists of run tests better, if there is given additional information
about a test environment and tested filesystems.
* generic/459 test is added to freeze group
* generic/482 test is added to thin group
* generic/529 test is added to acl group
* generic/530 test is added to shutdown group
Signed-off-by: Vladimir Zapolskiy <vladimir@tuxera.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Add a regression test for the bug fixed by commit 10a98cb16d80 ("xfs:
clear PF_MEMALLOC before exiting xfsaild thread").
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Add a regression test for a bug in the FS_IOC_REMOVE_ENCRYPTION_KEY
ioctl fixed by commit 2b4eae95c736 ("fscrypt: don't evict dirty inodes
after removing key").
This ioctl is also tested by generic/580 and generic/581, but they
didn't cover the case where this bug occurs.
This test detects the bug on ext4, f2fs, and ubifs. The multi-threaded
part of the test actually still fails on ubifs even with the fix, due to
another kernel bug which I'm working on fixing.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
If $TEST_DIR is a substring of $SCRATCH_MNT (like /mnt and /mnt2),
this test always fail. Change to use _filter_testdir_and_scratch
which will filter the longer string first if the other string is a
substring of the longer one.
Signed-off-by: Yongcheng Yang <yongcheng.yang@gmail.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Add an option to the locktest program to check for fcntl setlease
support, and skip the generic/571 test on filesystems where the
check returns EINVAL.
Signed-off-by: Scott Mayhew <smayhew@redhat.com>
Reviewed-by: Christoph Hellwig <hch@infradead.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Set different grace time, make sure each of quota (user, group and
project) timers can be set (by setquota) and get (by repquota)
correctly.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Some filesystems do not support negative c/m/atime timestamps. And
for these filesystems, generic/258 will fail.
Since there's currently no way to check sb->s_time_min from
userspace, this patch adds a new common/rc function
_require_negative_timestamps() that will _notrun depending on the
$FSTYP variable.
Signed-off-by: Luis Henriques <lhenriques@suse.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
It turns out that repquota (which reports in units of 1k blocks) reports
rounded up numbers when the fs blocksize is 512 bytes. However, xfs_io
stat always reports block counts in units of 512 bytes. If the number
of (512b) file blocks is not an even number, the "$3 / 2" expression
will round down, causing the test to fail. Round up to the nearest 1k
to match repquota's behavior.
Reported-by: zlang@redhat.com
Fixes: 6b04ed0545 ("generic: test unwritten extent conversion extent mapping quota accounting")
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The 'grep -c "error"' check was causing false positive results for
cifs.ko when running it with 'echo 1 > /proc/fs/cifs/cifsFYI'.
That is, the test would fail when cifs.ko prints out a non-error
message like this:
[ 2320.903987] fs/cifs/smb2maperror.c: Mapping SMB2 status code 0x80000006 to POSIX err -61
Signed-off-by: Paulo Alcantara (SUSE) <pc@cjr.nz>
Suggested-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
If xfs_io's utimes command cannot interpret the arguments that are
given to it, it will print out "Bad value for [am]time". Detect
when this happens and drop the file out of the test entirely.
This is particularly noticeable on 32-bit platforms and the largest
timestamp seconds supported by the filesystem is INT_MAX. In this
case, the maximum value we can cram into tv_sec is INT_MAX, and
there is no way to actually test setting a timestamp of INT_MAX + 1
to test the clamping.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
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>
Eric Sandeen
Vladimir Zapolskiy
Eric Biggers
Yongcheng Yang
Scott Mayhew
Zorro Lang
Luis Henriques
Darrick J. Wong
Paulo Alcantara (SUSE)
Christoph Hellwig
Theodore Ts'o
Filipe Manana
Deepa Dinamani
Yang Xu
Xiao Yang