Commit Graph

3849 Commits

Author SHA1 Message Date
Jeff Mahoney 33cd745db0 btrfs/023: skip trying to test raid56 without kernel support
Older kernels don't support raid56.  This test is still valid for
other profiles, so skip raid56 if the kernel doesn't support it.

Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-01-27 13:30:35 +08:00
Jeff Mahoney c38ce35516 btrfs: require feature raid56 for raid56 tests
btrfs/125, btrfs/148, btrfs/157, and btrfs/158 test for raid56
behavior.  We shouldn't run if the kernel doesn't have support for
them.

Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-01-27 13:30:28 +08:00
Jeff Mahoney 5b1a503aba btrfs/010: don't run without /sys/fs/btrfs
Older kernels don't have /sys/fs/btrfs.  btrfs/010 will happily run
until it goes to check its work against sysfs and finds those files
don't exist.  This patch introduces a require check to ensure that
the sysfs files are present before running.

Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-01-27 13:30:16 +08:00
Filipe Manana a1c91630a3 btrfs/081: fix killing of reader loop subshell
The test creates a subshell that keeps running the 'cat' command
against a test file in an infinite loop, and after it kills the
subshell it unmounts the filesystem, after which point any 'cat'
subcommand that runs after or at that time will fail resulting in an
unexpected golden output:

  $ ./check btrfs/081
  btrfs/081 3s ... - output mismatch (see /home/fdmanana/git/hub/xfstests/results//btrfs/081.out.bad)
      --- tests/btrfs/081.out	2018-09-16 21:30:48.501104179 +0100
      +++ /home/fdmanana/git/hub/xfstests/results//btrfs/081.out.bad	2019-01-24 20:36:18.989746185 +0000
      @@ -206,5 +206,6 @@
       Verifying file digests after cloning
       14968c092c68e32fa35e776392d14523  SCRATCH_MNT/foo
       14968c092c68e32fa35e776392d14523  SCRATCH_MNT/bar
      +cat: /mnt/scratch/bar: No such file or directory
       Verifying target file digest after umount + mount
       14968c092c68e32fa35e776392d14523  SCRATCH_MNT/bar
      ...
      (Run 'diff -u /home/fdmanana/git/hub/xfstests/tests/btrfs/081.out /home/fdmanana/git/hub/xfstests/results//btrfs/081.out.bad'  to see the entire diff)
  Ran: btrfs/081
  Failures: btrfs/081
  Failed 1 of 1 tests

Fix that by adding a proper trap to the reader loop function so that
the subshell waits for executed 'cat' commands when it receives
SIGTERM.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-01-27 13:18:59 +08:00
Filipe Manana 2223d8fe18 btrfs/081: declare local variables as local
Some variables inside the test's functions were used as local but
were not being declared as such. Add the local declaration for them.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-01-27 13:18:46 +08:00
Zorro Lang 04b405fa1f common/dump: disable splice from FSSTRESS_AVOID
New fsstress operation breaks fs dump/restore testing which use
fsstress, e.g xfs/068.

In _create_dumpdir_stress_num, disable splice in fsstress so that we
dump exactly the same set of files and directories.

Quote Dave's comments for future reference

"
fsstress is just creating regular files differently. It has no
impact on xfsdump does except to change the number of files created
and the directory layout.

If this new functionality were creating a new type of file that
xfsdump has to handle, or adding new attributes or changing the
metadata of the existing files, then we want to make sure xfsdump is
tested against that, and so we'd be changing the golden output after
careful checking that both xfsdump and xfs_restore are working
correctly and the file count is correct.

But when all we are doing is creating normal, regular files just
with a different syscall, it makes no sense to perturb the existing
test then we have to go and validate that the new set of files being
tested is actually scanned correctly, is complete and correct. Using
a blacklist to avoid unnecessary perturbation such as in cases like
this is the right thing to do because we've had to determine if the
new functionality is a useful addition to xfsdump/restore test
coverage or not.
"

[Eryu: add Dave's comments in commit log for future reference]

Signed-off-by: Zorro Lang <zlang@redhat.com>
Suggested-by: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-01-27 11:56:40 +08:00
Zorro Lang 544624ac14 fsstress: add splice support
Support the splice syscall in fsstress.

Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-01-27 11:56:38 +08:00
Vivek Goyal 23703a8d22 overlay: File capabilities should not be lost over copy-up
Make sure file capabilities are not lost over copy-up when file is
opened for WRITE but nothing is actually written to it.

Following commit introduced regression where if a lower file with
CAP_SETUID is opened for writing, and capability is cleared over copy up.

bd64e57586d3 ("ovl: During copy up, first copy up metadata and then data")

A later kernel patch will fix it. This test will help avoid introducing
such regressions again.

Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-01-17 11:15:09 +08:00
Brian Foster be5dedec18 generic: test writepage cached mapping validity
XFS has a bug where page writeback can end up sending data to the
wrong location due to a stale, cached file mapping. Add a test to
trigger this problem by racing background writeback with a
truncate/rewrite of the final page of the file.

Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-01-16 16:20:53 +08:00
Qu Wenruo 8fc1e7c157 btrfs: test for deadlock between snapshot delete and other read-write operations
Commit fb235dc06fac ("btrfs: qgroup: Move half of the qgroup
accounting time out of commit trans") could cause ABBA deadlock
between backref lookup with write lock hold (subvolume deletion) and
other read/write operations.

It's going to be fixed by "btrfs: qgroup: Don't trigger backref walk
at delayed ref insert time".

This test will generate pwrite background workload, along with
constant subvolume creation and deletion to trigger the bug.

It needs some time to generate enough files to bump the tree height
to trigger the bug.

In my test environment, with 'unsafe' cache mode for the VM, it
triggers the bug at around 70~90 seconds. So I leave the default
runtime to 120s to make sure the bug will be triggered.

Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-01-12 15:44:04 +08:00
Qu Wenruo a4235f29f7 btrfs: Make seed device test cases into their own group
btrfs/16[123] are all seed device related test cases, make them into
'seed' group.

Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-01-10 22:14:21 +08:00
Darrick J. Wong e492e5157d generic: test that xattrs can have slashes in their names
Eric Sandeen recently found a bug in xfs_repair that flagged extended
attribute names containing "/" as corrupt and purged them.  There's
nothing in the IRIX or Linux manuals that say anything about slashes not
being allowed (and Linux certainly allows this) so let's make sure this
continues to work.

[Eryu: use $SETFATTR and _getfattr helper]

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Carlos Maiolino <cmaiolino@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-01-10 19:04:45 +08:00
Cui Yue 50076fc291 generic/423: statx mask of the reference file is different from the original file
When running xfstests generic/423 to test system call statx() on
hard link files of NFS, it fails.  error message:

[!] attr 'stx_mask' differs from ref file, 7ff != e0

The values of parameter "mask" between the original file and the
reference file are different.  One is STATX_ALL;
The other is STATX_ATIME | STATX_BTIME | STATX_CTIME | STATX_MTIME.

Modify the function get_reference() to pass the "mask" in, and
change STATX_ATIME | STATX_BTIME | STATX_CTIME | STATX_MTIME to
"mask".

Signed-off-by: Cui Yue <cuiyue-fnst@cn.fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-01-10 16:11:27 +08:00
Nikolay Borisov f3a1213c24 Revert "common/config: create $RESULT_BASE before dumping kmemleak leaks"
This commit tried to fix the brokennes of the kmemleak support but it
inadvertently broke the creation of the RESULT_BASE directory which lead to
problems creating check.time file. Turns out kmemleak support in xfstests has
more problems and it needs to be majorly refactor and this commit doesn't
really solve the problem. For the time being just revert to at least allow
older configuration files, which have explicitly set RESULT_BASE to work.

This reverts commit 7fc034868d.

Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-01-06 22:40:40 +08:00
Hou Tao e18876187c generic/131: wait until the server is ready or timeout
When running xfstests under KVM VM and the load of host is high,
only delaying 1s and checking the readiness of server are not
enough, and the test case will fail early.

Fix it by repeatedly checking the readiness signal until it's found,
or timeout is triggered.

[Eryu: check if lock server died or not, like v1 patch did]

Signed-off-by: Hou Tao <houtao1@huawei.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-01-06 22:40:40 +08:00
Hou Tao 2408f208c1 fsx: check ENOSYS in test_copy_range() & test_fallocate()
In configure script, we only check whether or not the build of test
program succeeds, but that doesn't mean the kernel has implemented
the syscall, so checking for this case.

Signed-off-by: Hou Tao <houtao1@huawei.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-01-06 22:02:53 +08:00
Zorro Lang b0c8dbccf4 xfs/139-140: skip testing on large scratch dev
x/139 and x/140 makes XFS with very small agsize. That agsize is too
small for a large fs. And it's not necessary to test on large fs, so
skip it directly if scratch dev is large dev.

Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-01-06 22:02:53 +08:00
Zorro Lang 6dbca6feb9 generic/474: shift target directory to a sub-dir of SCRATCH_MNT
If testing on large fs (--large-fs option), there's a huge size
.use_space file in $SCRATCH_MNT, then `fssum $SCRATCH_MNT` trys to
read whole huge file. That's wasting time, so change the target path
to a sub-dir of $SCRATCH_MNT.

Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-01-06 22:02:53 +08:00
Hou Tao 46c1a950e3 xfs: only set XFS_MKFS_HAS_NO_META_SUPPORT for XFS
No need to set XFS_MKFS_HAS_NO_META_SUPPORT for all filesystems.

Cc: Dave Chinner <dchinner@redhat.com>
Signed-off-by: Hou Tao <houtao1@huawei.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2019-01-06 22:02:53 +08:00
Hou Tao ff67bfc354 generic/466: explicitly request $SCRATCH_DEV to be a block device
so "blockdev --getsize64 $SCRATCH_DEV" will succeed.

Signed-off-by: Hou Tao <houtao1@huawei.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2018-12-29 16:00:58 +08:00
Hou Tao a6c53104a4 generic/019: require scratch device to be a block device
To ensure "blockdev --getsz $SCRATCH_DEV" will succeed.

Signed-off-by: Hou Tao <houtao1@huawei.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2018-12-29 15:52:15 +08:00
Hou Tao 3f95ea9fb3 check: use _try_scratch_mount instead of _scratch_mount to mount SCRATCH_DEV
Else there won't be any error messages when mounting SCRATCH_DEV
failed, because _scratch_mount exits early by invoking _fail.

Signed-off-by: Hou Tao <houtao1@huawei.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2018-12-29 15:50:55 +08:00
Theodore Ts'o deab8ca02e ext4/034: adjust commit which fixes the problem tested by ext4/034
Also add a requirment that fallocate and fiemap is supported.
(Fallocate isn't the case when we are emulating ext3, for example.)

Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Cc: Liu Bo <obuil.liubo@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
2018-12-29 13:09:08 +08:00
Darrick J. Wong a190cead9e xfs: look for stringified constants in ftrace formats
Look for uninterpretable stringified constants in the ftrace format
description for xfs tracepoints.

[Eryu: add $CC_PROG definition and require it in test, also use
$DEBUGFS_MNT instead of hard coded path]

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>
2018-12-23 22:30:56 +08:00
Darrick J. Wong 3a2aed3ae4 xfs: filter out mount options that don't work on v4 filesystems
A few tests require v4 filesystems and enforce this by disabling
crc's in the _scratch_mkfs call.  However, if the user specified
MOUNT_OPTIONS that only work with v5 filesystems, these tests fail.
If we detect a test creating a v4 scratch filesystem, filter out
incompatible mount options that don't work on v4, such as
simultaneous group/project quota.

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>
2018-12-22 23:45:29 +08:00