generic: add mmap CoW test for 'regular' case

Check what happens if we MMAP CoW blocks 2-4 of a page's worth of blocks when
the second block is a regular block.  (MMAP version of generic/205,206)

Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

btrfs: make nospace_cache related test cases to work with latest v2 cache

In the coming btrfs-progs v5.15 release, mkfs.btrfs will change to
use v2 cache by default.

However nospace_cache mount option will not work with v2 cache, as
it would make v2 cache out of sync with on-disk used space.

So mounting a btrfs with v2 cache using "nospace_cache" will make
btrfs to reject the mount.

There are quite some test cases relying on nospace_cache to prevent
v1 cache to take up data space.

For those test cases, we no longer need the "nospace_cache" mount
option if the filesystem is already using v2 cache. Since v2 cache
is using metadata space, it will no longer take up data space, thus
no extra mount options for those test cases.

By this, we can keep those existing tests to run without problem for
both v1 and v2 cache.

Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Anand Jain <anand.jain@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

fstests: check if the scratch device is an lv device for certain tests

I use lvm to carve up a large disk so I can run the btrfs raid related xfstests.
However this messes with tests that try to greate lvm devices ontop of
SCRATCH_DEV.  Handle this by adding a _require_scratch_nolvm helper to skip
tests that are going to try and create lvm devices.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

fstests: print symbolic names for fiemap flags

My nightly btrfs tests are failing on my configs with -o compress because the
extents have FIEMAP_EXTENT_ENCODED set, which throws the golden output off.

Fix this by changing the filter helper to spit out symbolic names for SHARED and
LAST (these tests only care about SHARED).  Then change the golden output to
match the new output of the filter.  With this patch my -o compress configs now
pass these tests.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

generic/643: Fix for 1k block sizes for ext2 and ext3

Currently this test fails on ext2 and ext3 filesystems using 1k block sizes,
because we set the maximum swap size the kernel is allowed to map according to
the mapping kernel created when enabling the original swap file.

But the translation from indirect block mapping to iomap extents associated with
the page alignment requirements imposed by iomap_swapfile_add_extent(), causes
this test to fail. The kernel end up mapping way less pages than the file
actually has.
After the file is extended by the test, the page alignment is not a problem
anymore and the kernel can use the whole space available in the swapfile,
written in its header, and this creates a variance bigger than what the current
test allows, making the tolerance check within the test to fail.

Fix this by using the swap size recorded in the swapfile header (reported by
mkswap), as the maximum swap size the kernel is allowed to map, instead of
reading the swap size mapped by the kernel from /proc. This also makes
the first swap{on/off} cycle unnecessary, so remove it.

Since the size hardcoded in the swapfile header is the limit allowed for the
kernel to map as swap area, this is the real limit the kernel can't map beyond,
and what this test should be checking for.

This patch also slightly changes the way the test check the swap size
'after' the swap file is extended. Instead of retrieving the information
from /proc/swaps directly, the test now relies on 'swapon' tool. This
enables the test to retrieve the swap size in bytes directly, same unit
returned by _format_swapfile. This avoid possible miscalculations caused by
retrieving swap size in different units.

Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

common/rc: Enable _format_swapfile to return the swap size

Once the kernel is free to not map the full swap file during a swapon call,
it can be useful to know the exact size of the swap area created during
_format_swapfile().

To achieve this, it is needed to change other _format_swapfile() callers to drop
the return value if not required, otherwise, it will be printed to stdout making
such tests to fail.

Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

common/renameat2: use mktemp(1) to create temporary directory

Instead of using $TEST_DIR/$$, use the _correct_ way to create temporary
directories.  I've seen generic/626 failing with:

  QA output created by 626
  mkdir: cannot create directory '/media/test/471': File exists
  Silence is golden

which was likely due to another test that used the same directory name and
didn't do the clean-up.

Signed-off-by: Luís Henriques <lhenriques@suse.de>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

ext4: add test for all ext4/ext3/ext2 mount options

Add test to validate that all the ext4, ext3 and ext2 are properly
recognized, validate and applied to avoid regressions as ext4 moves to
the new mount API.

Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

common/rc: add _require_kernel_config and _has_kernel_config

Add _require_kernel_config() and _has_kernel_config() helpers to check
whether a specific kernel configuration is enabled on the kernel.

Signed-off-by: Lukas Czerner <lczerner@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

ext4/051: correct kernel commit

ext4/051 fails on my test machine, but I can't find commit in
e2fsprogs according to commit log that said it is a e2fsprog
regression test. Actually, it is a kernel regression test.  So
remind user it is a kernel regression test and use correct fix
kernel commit[1].

[1]https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b2bbb92f

Signed-off-by: Yang Xu <xuyang2018.jy@fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

generic/648: dmerror must be unmounted

Sometimes g/648 fail to unmount dmerror with this error:

   umount: /mnt/xfstests/scratch: target is busy.

Even worse, it will cause all later test cases fail as:

  mount: bad usage
  Try 'mount --help' for more information.
  check: failed to mount $SCRATCH_DEV using specified options
  Interrupted!

So we shouldn't _fail directly if dmerror_unmount fails, use a while
loop to try to unmount it enough times.

Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

generic/574: remove invalid test of read completely past EOF

One of the test cases in generic/574 tests that if a file of length
130999 has fs-verity enabled, and if bytes 131000..131071 (i.e. some
bytes past EOF and in the same block as EOF) are corrupted with nonzero
values, then reads of the corrupted part should fail with EIO.

This isn't a valid test case, because reads that start at or past EOF
are allowed to simply return 0 without doing any I/O.

Therefore, don't run this test case.

This fixes a test failure caused by the kernel commit 8c8387ee3f55
("mm: stop filemap_read() from grabbing a superfluous page").

Note that the other test cases for this same corrupted file remain
valid, including testing that an error is reported during full file
reads and during mmap "reads".  This is because the fs-verity Merkle
tree is defined over full blocks, so the file's last block won't be
readable if it contains corrupted (nonzero) bytes past EOF.  This may
seem odd, but it's working as intended, especially considering that
bytes past EOF in a file's last block are exposed to userspace in mmaps.

Signed-off-by: Eric Biggers <ebiggers@google.com>

generic/528: take fs timestamps granularity into account in tolerance interval

Filesystems timestamps granularity can cause spurious test failures:

  QA output created by 528
  btime has value of 1635818936
  btime is NOT in range 1635818937 .. 1635818942

This test output makes it looks like $testfile was created *before* the
'date' command was executed.  What really happen was that btime was
truncated according to the granularity defined by filesystem (I've seen
this with both ext4 and xfs, but I guess others are also affected).

Since granularity can't be worse than a second, simply adjust the test
tolerance interval by 1 second.

Signed-off-by: Luís Henriques <lhenriques@suse.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

common/btrfs: source module file and remove duplicates

btrfs/249 fails with:

QA output created by 249
./common/btrfs: line 425: _require_loadable_fs_module: command not found
./common/btrfs: line 432: _reload_fs_module: command not found
ERROR: not a btrfs filesystem: /media/scratch

This is because the test is failing to source common/module.
Fix this by sourcing common/module in the btrfs common file.

While it it remove duplication of sourcing this file from other
tests in btrfs so that this is only done once in one place.

Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

fsstress: improve error message on check_cwd() error

I ran into an error with generic/083 with xfs due to check_cwd() but
why it failed is not clear because there are two types of
failures:

  o stat64() failed (likely -ENOMEM is my guess)
  o the inode actually changed

Throw a bone out to developers so that in case en error does happen
they know which rabbit hole to go into.

Cc: Anthony Iliopoulos <ailiopoulos@suse.de>
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

fsstress: run more than 2^32 operations

Now that storage has gotten really really fast, we have to crank up
TIME_FACTOR to amusingly huge values to do things such as 10-day soak
testing.  "Un"fortunately, fsstress uses 'int' to count operations,
which means we get close to maxing out the 2^31 limit on operations in
fsstress.  Widen it to a long long value to take us to the heat death of
the universe, like we did for fsx a while back. ;)

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

common/rc: Fix check for SCRATCH_DEV_POOL presence in _scratch_dev_pool_get

Current check is buggy because it can never trigger as even if
SCRATCH_DEV_POOL is not defined config_ndevs will get a value of 0
from 'wc -w', this in turn makes 'typeset -p config_ndevs' always
return 0, triggering the existing check a noop.

Fix this by explicitly checking for the presence of SCHRATC_DEV_POOL

Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

generic/201: fix the description

This case is test for 'unlink', and there is no umount operation here.

Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

generic: fix description or typo in head comment

1. update description according to the current testcase
2. "ENSPC" -> "ENOSPC" ,"an the end -> at the end"

Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

generic/138,139,140: fix the name for check file

The original 'file3' is used to check if the result after operation on
file2 is correct.  So, rename it to be 'file2.chk' to make it easier to
understand.

Signed-off-by: Shiyang Ruan <ruansy.fnst@fujitsu.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

btrfs: test direct IO write on NOCOW file when low on unallocated space

Test that if we write to a range of a NOCOW file that has allocated
extents and there is not enough available free space for allocating new
data extents, the write succeeds. Test for direct IO and buffered IO
writes.

This currently fails on btrfs for the direct IO write scenario, only, but
while at it also test a buffered IO write, to help prevent regressions in
the future.

The patch that fixes the direct IO case has the following subject:

 "btrfs: fix ENOSPC failure when attempting direct IO write into NOCOW range"

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

dmflakey: fix environment-destroying mistakes in _cleanup_flakey

_cleanup_flakey can be called even when _init_flakey hasn't been called.
For example, _require_flakey_with_error_writes does this.

Unfortunately, the patch to add support for external logs and rt devices
will "reset" the SCRATCH_LOGDEV/SCRATCH_RTDEV variables without noticing
that _init_flakey hasn't been called yet.  When this happens, those two
variables will be set to the empty string, with the result that the rest
of the test doesn't use those devices.

To fix this, only reset SCRATCH_LOGDEV/RTDEV to the "NON_FLAKEY" value
if we actually set one.

Fixes: 9c1f3149 ("dmflakey: support external log and realtime devices")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

fstests: _require_dm_target should not always skip DAX capable devices

Recent changes have turned off all dm-error, dm-thin and dm-flakey
tests on pmem devices even when we are not explicitly testing DAX.
This is a regression resulting in a large number of log recovery
tests no longer running on my pmem-based test VMs. I added the "-o
dax=never" mount options to these test configs, only to find it
still would not run the dm tests even though the filesystem will
never use DAX.

Fix this so that the dm target DAX test explicitly ignores the
the block device DAX capability when the filesystem is mounted with
dax=never and hence we can use all the dm targets when the tests are
being run with FSDAX disabled.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

btrfs/012: check size after mounted

move '_require_fs_space'  after mounted.

==before patch==
btrfs/012       [not run] This test requires at least 0GB free on /fs/scratch to run

==after patch==
btrfs/012 189s ...  194s
Ran: btrfs/012
Passed all 1 tests

Signed-off-by: Zhu Yifei <yifeix.zhu@intel.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

btrfs/091: remove noinode_cache option

inode cache feature has been removed

Link: https://www.spinics.net/lists/linux-btrfs/msg107910.html
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Ma Xinjian <xinjianx.ma@intel.com>
Acked-by: David Sterba <dsterba@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

btrfs: test btrfs filesystem usage command on missing seed device

If there is a missing seed device in a sprout, the btrfs filesystem usage
command fails, which is fixed by the following patches:

  btrfs: sysfs add devinfo/fsid to retrieve fsid from the device
  btrfs-progs: read fsid from the sysfs in device_is_seed

Test if it works now after these patches in the kernel and in the
btrfs-progs respectively.

Suggested-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

btrfs: validate sysfs fsid

Validate if the sysfs fsid is the same as fsid as obtained from the
superblock.

Suggested-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

common/btrfs: add _require_btrfs_sysfs_fsid helper

It checks if the kernel has the following patch
 btrfs: sysfs add devinfo/fsid to retrieve fsid from the device
that added sysfs interface to get fsid.

Signed-off-by: Anand Jain <anand.jain@oracle.com>
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

fstests: groupfile generation needs force overwrite

Having built fstests as root as part of a run script, I get failures
then trying to run it as a user because of the group list
generation. The issue occurs because the group list files are owned
by root, and so I get an interactive prompt to overwrite them such
as:

Building btrfs
 [GROUP] /home/dave/src/xfstests-dev/tests/btrfs/group.list
mv: replace 'group.list', overriding mode 0644 (rw-r--r--)? y
Building ceph
 [GROUP] /home/dave/src/xfstests-dev/tests/ceph/group.list
mv: replace 'group.list', overriding mode 0644 (rw-r--r--)? y
Building cifs
 [GROUP] /home/dave/src/xfstests-dev/tests/cifs/group.list
mv: replace 'group.list', overriding mode 0644 (rw-r--r--)? y
Building ext4
 [GROUP] /home/dave/src/xfstests-dev/tests/ext4/group.list
...

Use 'mv -f' to ignore such trivial issues so that the new group
lists are written correctly.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

fstests: autoconf has deprecated a bunch of macros

Latest debian unstable environment results in these build warnings:

autoconf
configure.ac:8: warning: The macro `AC_HEADER_STDC' is obsolete.
configure.ac:8: You should run autoupdate.
./lib/autoconf/headers.m4:704: AC_HEADER_STDC is expanded from...
configure.ac:8: the top level
configure.ac:50: warning: The macro `AC_TRY_LINK' is obsolete.
configure.ac:50: You should run autoupdate.
./lib/autoconf/general.m4:2920: AC_TRY_LINK is expanded from...
m4/package_xfslibs.m4:95: AC_PACKAGE_NEED_XFSCTL_MACRO is expanded from...
configure.ac:50: the top level
configure.ac:63: warning: The macro `AC_TRY_LINK' is obsolete.
configure.ac:63: You should run autoupdate.
./lib/autoconf/general.m4:2920: AC_TRY_LINK is expanded from...
acinclude.m4:19: AC_PACKAGE_WANT_FALLOCATE is expanded from...
configure.ac:63: the top level
configure.ac:64: warning: The macro `AC_TRY_LINK' is obsolete.
configure.ac:64: You should run autoupdate.
./lib/autoconf/general.m4:2920: AC_TRY_LINK is expanded from...
acinclude.m4:32: AC_PACKAGE_WANT_OPEN_BY_HANDLE_AT is expanded from...
configure.ac:64: the top level
configure.ac:69: warning: The macro `AC_TRY_LINK' is obsolete.
configure.ac:69: You should run autoupdate.
./lib/autoconf/general.m4:2920: AC_TRY_LINK is expanded from...
m4/package_libcdev.m4:106: AC_HAVE_COPY_FILE_RANGE is expanded from...
configure.ac:69: the top level
configure.ac:107: warning: The macro `AC_CONFIG_HEADER' is obsolete.
configure.ac:107: You should run autoupdate.
./lib/autoconf/status.m4:719: AC_CONFIG_HEADER is expanded from...
configure.ac:107: the top level

So, run autoupdate and then fix all the warnings.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

generic/095: align DIO read/writes with the supported sector size for the device

This test creates fio DIO jobs with bs=1k, which will fail when using block
devices that have logical sector size bigger than 1k (such as zram, advanced
format HDD's with 4k sectors, DASD's on mainframes with 2k sectors, etc).

Fix the test by using _min_dio_alignment instead to get the correct size.

Signed-off-by: Luís Henriques <lhenriques@suse.de>
Reviewed-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

btrfs/049: remove the test

inode_cache is deprecated and will never appear in mount
options; remove it entirely

Link: https://www.spinics.net/lists/linux-btrfs/msg107910.html
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Ma Xinjian <xinjianx.ma@intel.com>
Acked-by: David Sterba <dsterba@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

common/log: fix *_dump_log routines for ext4

dumpe2fs -h displays the superblock contents, not the journal
contents.  Use the logdump utility to dump the contents of the
journal.

Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Allison Henderson <allison.henderson@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

common/log: move *_dump_log routines to common/log

Move _scratch_remount_dump_log and _test_remount_dump_log from
common/inject to common/log. These routines do not inject errors and
should be placed with other common log functions.

Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com>
Reviewed-by: Allison Henderson <allison.henderson@oracle.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

fstests: rename _test_inject_logprint to _test_remount_dump_log

Rename _test_inject_logprint to _test_remount_dump_log to better
describe what this function does. _test_remount_dump_log unmounts
and remounts the test device, dumping the log.

Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com>
Reviewed-by: Allison Henderson <allison.henderson@oracle.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

fstests: rename _scratch_inject_logprint to _scratch_remount_dump_log

Rename _scratch_inject_logprint to _scratch_remount_dump_log to
better describe what this function does. _scratch_remount_dump_log
unmounts and remounts the scratch device, dumping the log.

Signed-off-by: Catherine Hoang <catherine.hoang@oracle.com>
Reviewed-by: Allison Henderson <allison.henderson@oracle.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

xfs/540: use _scratch_xfs_set_metadata_field api

With older xfsprogs, xfs_db write subcmd doesn't -d option. So this
case fails.  Use _scratch_xfs_set_metadata_field api to avoid this.

Signed-off-by: Yang Xu <xuyang2018.jy@fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

generic/079: make sure users 'nobody' and 'daemon' exist

Test 'src/t_immutable' assumes the existence of users 'nobody' and
'daemon' on the system.  If any of these users don't exist, the test will
fail with:

  add_acl(/media/scratch/079/immutable.f) did not set errno == EPERM
  ...

because it tries to set ACLs such as:

  u::rwx,g::rwx,o::rwx,u:daemon:rwx,m::rwx

Use the new _require_user_exists() function to ensure these users exist.

Signed-off-by: Luis Henriques <lhenriques@suse.de>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

common/rc: add _require_user_exists() to check if a user exists

Function _require_user() does check if a user exists *and* if it is able
to execute commands.  Add a new function to simply check if a user exists.

Signed-off-by: Luis Henriques <lhenriques@suse.de>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

new: don't allow new tests in group 'other'

The 'other' group is vaguely defined at best -- other than what?  It's
not clear what tests belong in this group, and it has become a dumping
ground for random stuff that are classified in other groups.  Don't let
people create new other group tests.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

new: standardize group name checking

Use the same group name validation when reading group names from
standard input or from the command line.  Now that we require all group
names to be documented, there's no reason to leave these separate
requirements.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

new: clean up the group name input code

Clean up the code that reads group names in from the command line to
take advantage of the read command's ability to display a prompt.  While
we're at it, we should abort the script if the group list encounters
EOF, and we can tighten up some of the other sh-isms too.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

new: only allow documented test group names

Now that we require all group names to be listed in doc/group-names.txt,
we can use that (instead of running mkgroupfile) to check if the group
name(s) supplied by the user actually exist.  This has the secondary
effect of being a second nudge towards keeping the description of groups
up to date.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

tools: add missing license tags to my scripts

I forgot to add spdx license tags and copyright statements to some of
the tools that I've contributed to fstests.  Fix this to be explicit.

Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

tools: make sure that test groups are described in the documentation

Create a file to document the purpose of each test group that is
currently defined in fstests, and change mkgroupfile to check that every
group mentioned in the tests is also mentioned in the documentation.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

generic/631: change this test to use the 'whiteout' group

This test isn't really an overlay test; it's a regression test for a bug
that someone found in xfs handling of whiteout files.  Since the
'overlay' group has one member, let's move it to 'whiteout'.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

btrfs: fix incorrect subvolume test group name

The group for testing subvolume functionality is 'subvol', not
'subvolume'.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

xfs: fix incorrect fuzz test group name

The group name for fuzz tests is 'fuzzers'.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

xfs: move reflink tests into the clone group

"clone" is the group for tests that exercise FICLONERANGE, so move these
tests.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

ceph: re-tag copy_file_range as being in the copy_range group

copy_range is the group name for copy_file_range tests, so reclassify
these tests.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

generic: fsstress with cpu offlining

Exercise filesystem operations when we're taking CPUs online and offline
throughout the test.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

xfs: test adding realtime sections to filesystem

Add a functional test to exercise using "xfs_growfs -e XXX -r" to add a
realtime section to a filesystem while changing the extent size.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

xfs: test correct propagation of rt extent size hints on rtinherit dirs

This is a regression test for the following fixes:

 xfs: standardize extent size hint validation
 xfs: validate extsz hints against rt extent size when rtinherit is set
 mkfs: validate rt extent size hint when rtinherit is set

These patches fix inadequate rtextsize alignment validation of extent
size hints on directories with the rtinherit and extszinherit flags set.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

xfs: test fsx with extent size hints set on a realtime file

This is a regression test for the two realtime allocator bug fixes:

xfs: adjust rt allocation minlen when extszhint > rtextsize
xfs: retry allocations when locality-based search fails

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

common/rc: use directio mode for the loop device when possible

Recently, I've been observing very high runtimes of tests that
format a filesystem atop a loop device and write enough data to fill
memory, such as generic/590 and generic/361.  Logging into the test
VMs, I noticed that the writes to the file on the upper filesystem
started fast, but soon slowed down to about 500KB/s and stayed that
way for nearly 20 minutes.  Looking through the D-state processes on
the system revealed:

/proc/4350/comm = xfs_io
/proc/4350/stack : [<0>] balance_dirty_pages+0x332/0xda0
[<0>] balance_dirty_pages_ratelimited+0x304/0x400
[<0>] iomap_file_buffered_write+0x1ab/0x260
[<0>] xfs_file_buffered_write+0xba/0x330 [xfs]
[<0>] new_sync_write+0x119/0x1a0
[<0>] vfs_write+0x274/0x310
[<0>] __x64_sys_pwrite64+0x89/0xc0
[<0>] do_syscall_64+0x35/0x80
[<0>] entry_SYSCALL_64_after_hwframe+0x44/0xae

Here's the xfs_io process performing a buffered write to the file on the
upper filesystem, which at this point has dirtied enough pages to be
ratelimited.

/proc/28/comm = u10:0+flush-8:80
/proc/28/stack : [<0>] blk_mq_get_tag+0x11c/0x280
[<0>] __blk_mq_alloc_request+0xce/0xf0
[<0>] blk_mq_submit_bio+0x139/0x5b0
[<0>] submit_bio_noacct+0x3ba/0x430
[<0>] iomap_submit_ioend+0x4b/0x70
[<0>] xfs_vm_writepages+0x86/0x170 [xfs]
[<0>] do_writepages+0xcc/0x200
[<0>] __writeback_single_inode+0x3d/0x300
[<0>] writeback_sb_inodes+0x207/0x4a0
[<0>] __writeback_inodes_wb+0x4c/0xe0
[<0>] wb_writeback+0x1da/0x2c0
[<0>] wb_workfn+0x2ad/0x4f0
[<0>] process_one_work+0x1e2/0x3d0
[<0>] worker_thread+0x53/0x3c0
[<0>] kthread+0x149/0x170
[<0>] ret_from_fork+0x1f/0x30

This is a flusher thread that has invoked writeback on the upper
filesystem to try to clean memory pages.

/proc/89/comm = u10:7+loop0
/proc/89/stack : [<0>] balance_dirty_pages+0x332/0xda0
[<0>] balance_dirty_pages_ratelimited+0x304/0x400
[<0>] iomap_file_buffered_write+0x1ab/0x260
[<0>] xfs_file_buffered_write+0xba/0x330 [xfs]
[<0>] do_iter_readv_writev+0x14f/0x1a0
[<0>] do_iter_write+0x7b/0x1c0
[<0>] lo_write_bvec+0x62/0x1c0
[<0>] loop_process_work+0x3a4/0xba0
[<0>] process_one_work+0x1e2/0x3d0
[<0>] worker_thread+0x53/0x3c0
[<0>] kthread+0x149/0x170
[<0>] ret_from_fork+0x1f/0x30

Here's the loop device worker handling the writeback IO submitted by the
flusher thread.  Unfortunately, the loop device is using buffered write
mode, which means that /writeback/ is dirtying pages and being throttled
for that.  This is stupid.

Fix this by trying to enable "directio" mode on the loop device, which
delivers two performance benefits: setting directio mode also enables
async io mode, which will allow multiple IOs at once; and using directio
nearly eliminates the chance that writeback will get throttled.

On the author's system with fast storage, this reduces the runtime of
g/590 from 20 minutes to 12 seconds, and g/361 from ~30s to ~3s.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

common/rc: re-fix detection of device-mapper/persistent memory incompatibility

In commit e05491b3, I tried to resolve false test failures that were
a result of device mapper refusing to change access modes on a block
device that supports the FSDAX access mode.  Unfortunately, I did
not realize that there are two ways that fsdax support can be
detected via sysfs: /sys/block/XXX/queue/dax and /sys/block/XXX/dax/,
so I only added a test for the latter.

As of 5.15-rc1 this doesn't seem to work anymore for some reason.  I
don't know enough about the byzantine world of pmem device driver
initialization, but fsdax mode actually does work even though the
/sys/block/XXX/dax/ path went away.  So clearly we have to detect it
via the other sysfs path.

Fixes: e05491b3 ("common/rc: fix detection of device-mapper/persistent memory incompatibility")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

btrfs/179: fix test failure when there are no snapshots to delete

It's very rare, but we can end up in a situation where there are no
snapshots to delete, in which case the $victim variable of the function
delete_workload() ends up being assigned with an empty string. When
that happens we end up running the command:

   btrfs subvolume delete "$SCRATCH_MNT/snapshots/"

Which fails since the argument is not a subvolume or a snapshot.
This causes the test to fail due to an unexpected error message from
the subvolume delete command:

  btrfs/179 129s ... - output mismatch (see /home/fdmanana/git/hub/xfstests/results//btrfs/179.out.bad)
      --- tests/btrfs/179.out 2020-10-16 23:13:46.546152332 +0100
      +++ /home/fdmanana/git/hub/xfstests/results//btrfs/179.out.bad 2021-09-24 11:15:01.404863801 +0100
      @@ -1,2 +1,3 @@
       QA output created by 179
      +ERROR: Not a Btrfs subvolume: Invalid argument
       Silence is golden
      ...

Fix that by making the delete_workload() loop skip the deletion attempt
when there are no snapshots.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

fsstress: fix bogus compile warning do_renameat2()

gcc complains with:

fsstress.c:4629:4: warning: 'oldparid' may be used uninitialized in this function [-Wmaybe-uninitialized]
 4629 |    printf("%d/%d: rename source entry: id=%d,parent=%d\n",
      |    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 4630 |     procid, opno, oldid, oldparid);
      |     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
fsstress.c:4629:4: warning: 'oldid' may be used uninitialized in this function [-Wmaybe-uninitialized]

But the varaibles are sure to be initialized, it is just that the
heuristics are broken since another check is used later which confuses
gcc. So just initialize the variables, to shup the compile warning.

Cc: kaixuxia <kaixuxia@tencent.com>
Cc: Brian Foster <bfoster@redhat.com>
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

common/module: use patient module removal

Now that scsi_debug has been using the patient module removal
for a while, let's generalize its use for the other use cases.
This likey will fix some odd false positives due to races.

Suggested-by: Eryu Guan <guan@eryu.me>
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

xfs: regresion test for fsmap problems with realtime

This is a regression test for:

c02f6529864a ("xfs: make xfs_rtalloc_query_range input parameters const")
9ab72f222774 ("xfs: fix off-by-one error when the last rt extent is in use")
7e1826e05ba6 ("xfs: make fsmap backend function key parameters const")

In which we synthesize an XFS with a realtime volume and a special
realtime volume to trip the bugs fixed by all three patches that
resulted in incomplete fsmap output.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

xfs/108: sync filesystem before querying quota

The new deferred inactivation code is lazy about deallocating
deleted files, which means that we need to be more proactive about
syncing the filesystem after deleting things.  When reporting quotas,
XFS only flushes the deferred work if we query quota id 0, so we
need the explicit sync to ensure the quota numbers are not affected
by laziness.

[Eryu: replace the global sync with xfs_io syncfs command]

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

xfs: test DONTCACHE behavior with the inode cache

Basic testing that DONTCACHE affects the XFS inode cache in the manner
that we expect.  The only way we can do that (for XFS, anyway) is to
play around with the BULKSTAT ioctl.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

generic: regression test for a FALLOC_FL_UNSHARE bug in XFS

This is a regression test for commit 72a048c1056a ("xfs: only set
IOMAP_F_SHARED when providing a srcmap to a write").

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

overlay: fix documented kernel commit ids

Fix documented commit ids for test overlay/078 following rebase of
overlayfs-next branch before merge to v5.15-rc1.

Document an additional kernel fix commit id for test overlay/077.

Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

btrfs/146: require scratch dev and pool before _require_dm_target

The test case btrfs/146 calls _require_dm_target which depends on
SCRATCH_DEV. The test case assumes that valid devices are set in
SCRATCH_DEV_POOL, and one of the devices is propagated to
SCRATCH_DEV.  However, when SCRATCH_DEV_POOL is not set, valid value
is not propagated to SCRATCH_DEV and _require_dm_target causes
unexpected test case failure.

To avoid the failure, move _require_scratch and
_require_scratch_dev_pool calls before _require_dm_target call to
detect invalid SCRATCH_DEV_POOL beforehand.

Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

generic/{628,629}: fix order of _require_scratch* and _require_dm_target

Test cases with dm_target shall call _require_scratch* before
_require_dm_target to ensure that valid SCRATCH_DEV is available for
dm_target. However, the test cases generic/628 and generic/629 call
_require_dm_target before _require_scratch*, then unexpected failure
was reported when SCRATCH_DEV is not specified. Fix the order of
function calls.

Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Reviewed-by: Johannes Thumshirn <johannes.thumshirn@wdc.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

generic/361: require sparse file support and fix mounting the volume.

The test case generic/361 fails on multiple filesystem
implementations due to two issues:

1. A file is created on a 512 MB volume by truncating it to
   1 GB. For this to work, the filesystem implementation must
   support sparse files. However, the test case does not check
   for sparse file support.
2. A loop device, backed by the 1 GB file, is created, mkfs is
   run on it and it is mounted. However, the mount command does
   not specify the filesystem type. This doesn't always work
   properly, as the kernel may pick the wrong driver if there
   are multiple implementations for a particular filesystem,
   or not find a driver at all in some cases.

To fix the behavior of the test case, this commit adds a requirement
for sparse file support to the test case, and explicitly specifies
the filesystem type as $FSTYP when mounting the loop device.

Signed-off-by: Ari Sundholm <ari@tuxera.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

xfs/449: filter out deprecation warnings from mkfs

To avoid regressing this test when testing XFS v4 when mkfs is new
enough to whine about creating new deprecated filesystems, filter out
the deprecation warning.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

generic: test shutdowns of a nested filesystem

generic/475, but we're running fsstress on a disk image inside the
scratch filesystem

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

idmapped-mounts: Fix build error because of undefined reallocarray

On old glibc, reallocarray was not introduced, so this case compiles
failed.  We should use reallocarray if glibc supports and use
realloc if glibcs doesn't support reallocarray.

Signed-off-by: Yang Xu <xuyang2018.jy@fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

idmapped-mounts: Use renameat instead of renameat2

We don't add fallback for renameat2, so it build failed on old
kernel. So use renameat instead.

Signed-off-by: Yang Xu <xuyang2018.jy@fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

configure.ac: Fix uncorrect detection because of linux/btrfs.h

On old distros, we can't detect some btrfs structs because of
undeclared 'NULL' in btrfs_err_str function. This function has been
removed after kernel commit 68598d2ea8863 ("btrfs: remove
btrfs_err_str function from uapi/linux/btrfs.h").

Fix this bug in xfstests layer by adding stddef.h because NULL is
defined in stddef.h(it is in /usr/lib/gcc*/ directory).

Signed-off-by: Yang Xu <xuyang2018.jy@fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

src/idmapped-mounts: Fix an error for the loop initialization declaration

Signed-off-by: Yang Xu <xuyang2018.jy@fujitsu.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

btrfs: test for rename/exchange behavior between subvolumes

This tests ensures that renames/exchanges across subvolumes work
only for other subvolumes and are otherwise forbidden and fail.

Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

common/renameat2: Make _rename_tests_source_dest take flags as 4th arguement

Currently this function takes the flags parameter to be passed to the
renameat program by assuming there exists a 'flags' variable. Instead,
make the flags being passed as 4th argument to the function.

Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

common/rc: fix MKSWAP_PROG quoting

After commit
  0e4dd8b9 common/rc: fix ignoring of errors on
we are getting this error message when running swapfiles tests:
  +./common/rc: line 2553: MKSWAP_PROG: command not found

Rewrite the line.

Signed-off-by: Murphy Zhou <xzhou@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

generic/643: fix weird problems on 64k-page arm systems

I noticed the following regression on an arm64 system with 64k pages:

  --- generic/643.out
  +++ generic/643.out.bad
  @@ -1,2 +1,3 @@
   QA output created by 643
  +swapon added 960 pages, expected 896
   Silence is golden

Evidently mkswap writes the swapfile header advertising one memory page
less than the size of the file, and on some architectures the kernel
can sometimes grab one page less than what's advertised.  This variance
is weird but tolerable; we simply don't want to see the page count
doubling when the file size doubles.

While we're at it, include the commit id of the fix in the commit
message.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

common/xfs: skip xfs_check unless the test runner forces us to

At long last I've completed my quest to ensure that every corruption
found by xfs_check can also be found by xfs_repair.  Since xfs_check
uses more memory than repair and has long been obsolete, let's stop
running it automatically from _check_xfs_filesystem unless the test
runner makes us do it.

Tests that explicitly want xfs_check can call it via _scratch_xfs_check
or _xfs_check; that part doesn't go away.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

fstests: which has been deprecated by Debian

This patch is brought to you by the Department That Hates Users.

The latest debian unstable release is now causing a bunch of new
test failures because they have deprecated the which command.

Rather than make everyone jump through hoops chasing problems with
'which' while debian decides to how to package at least three
variants of 'which' - each which will different semantics, behaviour
and support - as alternatives users then have to opt into, let's
just remove the remaining uses of the shell independent 'which'
command and replace them with bash builtin 'type -P' operations.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

generic/081: clean up snapshot devices correctly

I recently updated the userspace on a DAX-capable test VM, and no
g/081 fails to release the SCRATCH_DEV correctly. g/081 fails on dax
capable devices because DM rejects one of the setup operations:

The 081.full output file shows setup failure and then snapshot
creation failure:

  Wiping xfs signature on /dev/pmem1.
  Physical volume "/dev/pmem1" successfully created.
  Volume group "vg_081" successfully created
  Logical volume "base_081" created.
  device-mapper: reload ioctl on  (251:0) failed: Invalid argument
  Failed to suspend logical volume vg_081/base_081.
  Device vg_081-base_081-real (251:1) is used by another device.
  Failed to revert logical volume vg_081/base_081.
  Aborting. Manual intervention required.
Failed to create snapshot
.....

And dmesg tells us the reload ioctl failed because:

[ 2977.522306] device-mapper: ioctl: can't change device type (old=3 vs new=1) after initial table load.

DM table types are:

enum dm_queue_mode {
        DM_TYPE_NONE             = 0,
        DM_TYPE_BIO_BASED        = 1,
        DM_TYPE_REQUEST_BASED    = 2,
        DM_TYPE_DAX_BIO_BASED    = 3,
};

which indicates that the original table is DAX_BIO based (correct,
this is a pmem device) but then one of the setup operations is for
a type that is not DAX capable. Hence it fails and then things go
bad.

But the test has actually created the snapshot device and it's COW
target, so now when the _cleanup() function is called, the vgremove
command fails because the VG is busy (still has snapshot devices
attached to it) and at this point $SCRATCH_DEV is now unusable
without manual cleanup.

Manual cleanup just needs to remove the snapshot and logical base
volumes before trying to remove the vg and pv.  With this change, we
now see the teardown do:

....
Failed to create snapshot
umount: /mnt/test/mnt_081: not mounted.
  Logical volume "snap_081" successfully removed
  Logical volume "base_081" successfully removed
  Volume group "vg_081" successfully removed
  Labels on physical volume "/dev/pmem1" successfully wiped.

And future tests are able to use the SCRATCH_DEV normally.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

btrfs: make sure btrfs can create compressed inline extent

Btrfs has the ability to inline small file extents into its metadata,
and such inlined extents can be further compressed if needed.

The new test case is for a regression caused by commit f2165627319f
("btrfs: compression: don't try to compress if we don't have enough
pages").

That commit prevents btrfs from creating compressed inline extents, even
"-o compress,max_inline=2048" is specified, only uncompressed inline
extents can be created.

The test case will make sure that the content of the small file is
consistent between cycle mount, then use "btrfs inspect dump-tree" to
verify the created extent is both inlined and compressed.

The regression is fixed by commit 4e9655763b82 ("Revert "btrfs:
compression: don't try to compress if we don't have enough pages"")

Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

generic: Test page faults during read and write

Some filesystems have problems when the buffer passed to read or
write is memory-mapped to the file being read from or written to,
and the buffer needs to be faulted in during the read or write.
That's not common, but filesystems are still required to cope with
it, and if they fail this test, then they will also fail more
complex scenarios that involve multiple files.

Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

generic: check log recovery with readonly mount

And followed by a rw mount. After log recovery by these 2 mounts,
the filesystem should be in a consistent state.

Suggested-by: Donald Douwsma <ddouwsma@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Murphy Zhou <xzhou@redhat.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

common/rc: fix ignoring of errors on

Commit 0c95c8acb ("common: hide permision warning from mkswap for
exfat") and commit 08e93fa7c ("generic/554: hide permision warning on
exfat") removed a warning by grepping an error out. It however broke
use on older versions of bash such as 4.4.23:

./common/rc: line 2554: syntax error near unexpected token `>'
./common/rc: line 2554: `       MKSWAP_PROG "$fname" 2> >(grep -v 'insecure permission' >&2) >> $seqres.full'

Fix both instances by using a $(foo) to run the executable.

Cc: Pavel Reichl <preichl@redhat.com>
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

idmap: override btrfs_ioctl_vol_args_v2 if system header doesn't have subvolid

The struct btrfs_ioctl_vol_args_v2 in /usr/include/linux/btrfs.h on
my system predates the inclusion of the "subvolid" field.  This
causes the following build failure:

idmapped-mounts.c: In function 'btrfs_delete_subvolume_id':
idmapped-mounts.c:9730:6: error: 'struct btrfs_ioctl_vol_args_v2' has no member named 'subvolid'
 9730 |  args.subvolid = subvolid;
      |      ^

Since this source file contains its own more uptodate copy of that
structure, add some more autoconf/cpp magic so that we can override
the struct definition if the system header doesn't have the desired
field.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Acked-by: Christian Brauner <christian.brauner@ubuntu.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Anju T Sudhakar<anju@linux.vnet.ibm.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

ext4: add test to validate the large_dir feature

The ext4 large_dir feature supports a directory hash tree with a depth
greater than 2.  Reuse the dirstress program to create a sufficiently
large directory in order to exercise the large_dir code paths.

Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

btrfs: introduce btrfs specific idmapped mounts tests

While core vfs functionality that btrfs implements is completely covered
by the generic test-suite the btrfs specific ioctls are not.
This patch expands the test-suite to cover btrfs specific ioctls that
required changes to work on idmapped mounts. We deliberately don't use
the libbtrfsutil library as we need to know exactly what ioctl's are
issued and we need to be in control of all privileges at all times. This
test-suite currently tests:

- BTRFS_IOC_{SNAP,SUBVOL}_CREATE_V2
  - subvolume creation on idmapped mounts where the fsids do have a
    mapping in the superblock
  - snapshot creation on idmapped mounts where the fsids do have a
    mapping in the superblock
  - subvolume creation on idmapped mounts where the fsids do not have a
    mapping in the superblock
  - snapshot creation on idmapped mounts where the fsids do not have
    a mapping in the superblock
  - subvolume creation on idmapped mounts where the caller is
    located in a user namespace and the fsids do have a mapping
    in the superblock
  - snapshot creation on idmapped mounts where the caller is located
    in a user namespace and the fsids do have a mapping in the
    superblock
  - subvolume creation on idmapped mounts where the caller is
    located in a user namespace and the fsids do not have a mapping
    in the superblock
  - snapshot creation on idmapped mounts where the caller is located
    in a user namespace and the fsids do not have a mapping in the
    superblock

- BTRFS_IOC_SNAP_DESTROY_V2
  - subvolume deletion on idmapped mounts where the fsids do have a
    mapping in the superblock
  - snapshot deletion on idmapped mounts where the fsids do have a
    mapping in the superblock
  - subvolume deletion on idmapped mounts where the fsids do not have a
    mapping in the superblock
  - snapshot deletion on idmapped mounts where the fsids do not have
    a mapping in the superblock
  - subvolume deletion on idmapped mounts where the caller is
    located in a user namespace and the fsids do have a mapping
    in the superblock
  - snapshot deletion on idmapped mounts where the caller is located
    in a user namespace and the fsids do have a mapping in the
    superblock
  - subvolume deletion on idmapped mounts where the caller is
    located in a user namespace and the fsids do not have a mapping
    in the superblock
  - snapshot deletion on idmapped mounts where the caller is located
    in a user namespace and the fsids do not have a mapping in the
    superblock
  - unprivileged subvolume deletion on idmapped mounts where the fsids
    do have a mapping in the superblock and the filesystem is mounted
    with "user_subvol_rm_allowed"
  - unprivileged snapshot deletion on idmapped mounts where the fsids do
    have a mapping in the superblock and the filesystem is mounted with
    "user_subvol_rm_allowed"
  - subvolume deletion on idmapped mounts where the caller is
    located in a user namespace and the fsids do have a mapping
    in the superblock and the filesystem is mounted with
    "user_subvol_rm_allowed"
  - snapshot deletion on idmapped mounts where the caller is located
    in a user namespace and the fsids do have a mapping in the
    superblock and the filesystem is mounted with
    "user_subvol_rm_allowed"

- BTRFS_IOC_SUBVOL_SETFLAGS
  - subvolume flags on idmapped mounts where the fsids do have a mapping
    in the superblock
  - snapshot flags on idmapped mounts where the fsids do have a mapping
    in the superblock
  - subvolume flags on idmapped mounts where the fsids do not have a
    mapping in the superblock
  - snapshot flags on idmapped mounts where the fsids do not have a
    mapping in the superblock
  - subvolume flags on idmapped mounts where the caller is located in a
    user namespace and the fsids do have a mapping in the superblock
  - snapshot flags on idmapped mounts where the caller is located in a
    user namespace and the fsids do have a mapping in the superblock
  - subvolume flags on idmapped mounts where the caller is located in a
    user namespace and the fsids do not have a mapping in the superblock
  - snapshot flags on idmapped mounts where the caller is located in a
    user namespace and the fsids do not have a mapping in the superblock

- BTRFS_IOC_INO_LOOKUP_USER
  - subvolume lookup on idmapped mounts where the fsids do have a mapping
    in the superblock
  - subvolume lookup on idmapped mounts where the fsids do not have a
    mapping in the superblock
  - subvolume lookup on idmapped mounts where the caller is located in a
    user namespace and the fsids do have a mapping in the superblock
  - subvolume lookup on idmapped mounts where the caller is located in a
    user namespace and the fsids do not have a mapping in the superblock

Cc: Christoph Hellwig <hch@infradead.org>
Cc: Chris Mason <clm@fb.com>
Cc: David Sterba <dsterba@suse.com>
Cc: fstests@vger.kernel.org
Cc: linux-btrfs@vger.kernel.org
Reviewed-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

generic: add nested user namespace tests

Test ownership and ownership changes in a complex user namespace
hierarchy.

Cc: fstests@vger.kernel.org
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

idmapped-mounts: add nested userns creation helpers

Add a helper to create a nested userns hierarchy. This will be used in
follow-up tests.

Cc: fstests@vger.kernel.org
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

idmapped-mounts: refactor helpers

Make all userns creation helpers share a commond codebase and move a
bunch of code into utils.{c,h}. This simplifies a bunch of things and
makes it easier to create nested user namespaces in follow up patches.

Cc: fstests@vger.kernel.org
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

generic: add fscaps regression test

Add a test to verify that setting a v3 fscap from an idmapped mount
works as expected. This and other related use-cases were regressed by
commit [1] which was reverted in [2] and the proper fix merged right
before v5.12 was released in [3].

[1]: commit 3b0c2d3eaa83 ("Revert 95ebabde382c ("capabilities: Don't allow writing ambiguous v3 file capabilities")")
[2]: commit 95ebabde382c ("capabilities: Don't allow writing ambiguous v3 file capabilities")
[3]: commit db2e718a4798 ("capabilities: require CAP_SETFCAP to map uid 0")

Cc: fstests@vger.kernel.org
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

idmapped-mounts: introduce an explicit command line switch for testsuite

Introduce an explicit command line switch to runs the basic test suite.
This prepares for the introduction of additional command line switches
to run additional tests.

Cc: fstests@vger.kernel.org
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

idmapped-mounts: switch to getopt_long_only()

We're not using the shortopts anywhere anyway  and shouldn't encourage
using shortopts.  It's much more descriptive to see:

$here/src/idmapped-mounts/idmapped-mounts \
        --test-btrfs \
        --device "$TEST_DEV" \
        --mountpoint "$TEST_DIR" \
        --scratch-device "$SCRATCH_DEV" \
        --scratch-mountpoint "$SCRATCH_MNT"
        --fstype "$FSTYP"

in a test than it is to see:

$here/src/idmapped-mounts/idmapped-mounts \
        -b
        -d "$TEST_DEV" \
        -m "$TEST_DIR" \
        -s "$SCRATCH_DEV" \
        -a "$SCRATCH_MNT" \
        -f "$FSTYP"

In the second case one has to go consult the source code to make sure
that the correct option is passed. In the first case one can just see it
directly.

Cc: fstests@vger.kernel.org
Suggested-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

idmapped-mounts: use die() helper

Use the dedicated helper to report an error and exit with failure
instead of hand-rolling it.

Cc: fstests@vger.kernel.org
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Christian Brauner <christian.brauner@ubuntu.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

common/scsi_debug: use the patient module remover

If you try to run tests such as generic/108 in a loop
you'll eventually see a failure, but the failure can
be a false positive and the test was just unable to remove
the scsi_debug module.

We need to give some time for the refcnt to become 0. For
instance for the test generic/108 the refcnt lingers between
2 and 1. It should be 0 when we're done but a bit of time
seems to be required. The chance of us trying to run rmmod
when the refcnt is 2 or 1 is low, about 1/30 times if you
run the test in a loop on linux-next today.

Likewise, even when its 0 we just need a tiny breather before
we can remove the module (sleep 10 suffices) but this is
only required on older kernels. Otherwise removing the module
will just fail.

Some of these races are documented on the korg#212337, and
Doug Gilbert has posted at least one patch attempt to try
to help with this [1]. The patch does not resolve all the
issues though, it helps though.

This let's us remove the cheesy try loop. We keep the
udevadm settle call as it can help salvage buggy tests
which forgot to call it.

We also special-case where MODPROBE_PATIENT_RM_TIMEOUT_SECONDS
is set to "forever" and the initial module check finds its
in use, for that case we just try removing the module once
since fstests would not be the one leaving modues lingering
around, and waiting forever could mean you won't discover
the issue for a while.

[0] https://bugzilla.kernel.org/show_bug.cgi?id=212337
[1] https://lkml.kernel.org/r/20210508230745.27923-1-dgilbert@interlog.com

Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

common/module: add patient module rmmod support

When we call rmmod it will fail if the refcnt is greater than 0.
This is expected, however, if using test modules such as scsi_debug,
userspace tests may expect that once userspace is done issuing out
commands it can safely remove the module, and the module will be
removed.

This is not true for few reasons. First, a module might take a while
to quiesce after its used. This varies module by module. For example,
at least for scsi_debug there is one patch to help with this but
that is not sufficient to address all the removal issues, it just helps
quiesce the module faster. If something like LVM pvremove is used, as in
the case of generic/108, it may take time before the module's refcnt goes
to 0 even if DM_DEFERRED_REMOVE is *not* used and even if udevadm settle
is used. Even *after* all this... the module refcnt is still very
fickle. For example, any blkdev_open() against a block device will bump
a module refcnt up and we have little control over stopping these
sporadic userspace calls after a test. A failure on module removal then
just becomes an inconvenience on false positives.

This was first observed on scsi_debug [0]. Doug worked on a patch to
help the driver quiesce [1]. Later the issue has been determined to be
generic [2]. The only way to properly resolve these issues is with a
patient module remover. The kernel used to support a wait for the
delete_module() system call, however this was later deprecated into
kmod with a 10 second userspace sleep. That 10 second sleep is long gone
from kmod now though. I've posted patches now for a kmod patient module
remover then [3], in light of the fact that this issue is generic and
the only way to then properly deal with this is implementing a userspace
patient module remover.

Use the kmod patient module remover when supported, otherwise we open
code our own solution inside fstests. We default to a timeout of 100
seconds. Each test can override the timeout by setting the variable
MODPROBE_PATIENT_RM_TIMEOUT_SECONDS or setting it to "forever" if they
wish for the patience to be infinite.

This uses kmod's patient module remover if you have that feature,
otherwise we open code a solution in fstests which is a simplified
version of what has been proposed for kmod.

[0] https://bugzilla.kernel.org/show_bug.cgi?id=212337
[1] https://lore.kernel.org/linux-scsi/20210508230745.27923-1-dgilbert@interlog.com/
[2] https://bugzilla.kernel.org/show_bug.cgi?id=214015
[3] https://lkml.kernel.org/r/20210810051602.3067384-1-mcgrof@kernel.org

Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

generic/457: post-check fs on thin-vol device instead of scratch device

Recently, we found that this test running with btrfs didn't
pass the post-check fsck on scratch device.  This issue occured
due to the commit 5faafc77f ("dm space maps: don't reset space map
allocation cursor when committing") and the use of SSD as scratch
device.

In this test, it does not directly use the filesystem on scratch
device. It runs test on dm-thin volume tying two linear-mapping
devices, and those two linear devices are created from the scratch
device.  When the test runs, it will write data on dm-thin volume,
and dirty the underlying scratch device.

Since the commit (5faafc77f) changes the dm space allocation policy,
it may cause more dirty blocks on underlying scratch device when we
write data on thin volume.  So it makes more chance to overwrite the
position of btrfs-meta on the scratch device.  Besides, our scratch
device is SSD, so there is only one copy of btrfs meta on the scratch
device.  Once the btrfs-meta is overwritten, the btrfs volume will
crash, and cannot pass the fsck check.

Because, this test won't directly use the fs on scratch device.  We
just disable the post-check fsck on scratch device, instead, we run
post-check fsck on thin-vol device.

Reviewed-by: Chung-Chiang Cheng <cccheng@synology.com>
Reviewed-by: Robbie Ko <robbieko@synology.com>
Signed-off-by: Kai-Wen Hu <kevinhu@synology.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

xfs/176: fix the group name

Filesystem shrink tests for xfs are supposed to be in the 'shrinkfs'
group, not 'shrink'.

Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

xfs/187: remove the test

Upstream changes mean that "-o noattr2" no longer removes the
on-disk ATTR2 feature bit from the superblock and so the failure
case this test exercises is no longer guaranteed to be a failure
case. Hence the test is now useless as a regression test, so remove
it.

Signed-off-by: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>

ext4: regression test for "tune2fs -l" after ext4 shutdown

Regression test for e2fsprogs commit:

e905fbe3fd0f ext4: Fix tune2fs checksum failure for mounted filesystem

This test runs "tune2fs -l" after ext4 shutdown. tune2fs reads
superblock checksum from the buffer cache. On unfixed kernels, the
checksum is incorrect until the writeout happens, so tune2fs fails
with "superblock checksum does not match" in this case.

Signed-off-by: Boyang Xue <bxue@redhat.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>