This tests the fs.protected_regular and fs.protected_fifos
sysctls which restrict access behavior in sticky world-writable
directories as documented in the kernel at
Documentation/admin-guide/sysctl/fs.rst
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This tests the fs.protected_symlinks and fs.protected_hardlinks
sysctls which restrict links behavior in sticky world-writable
directories as documented in the kernel at
Documentation/admin-guide/sysctl/fs.rst
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
New _require_sysctl_variable test to ensure that the sysctl we wish to
test is available on the system.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
These two tests test direct I/O and buffered read repair, respectively,
with fail_make_request. However, by using "fail_make_request/times",
they rely on repair having a specific I/O pattern. My pending Btrfs
direct I/O refactoring patch series changes this I/O pattern and thus
breaks this test.
The dm-dust target (added in v5.2) emulates a device with bad blocks
that are fixed when written to (like a device that remaps bad blocks).
This is exactly what we want for testing repair. Add some common dm-dust
helpers and update the tests to use dm-dust.
Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: Nikolay Borisov <nborisov@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This is a test for whiteout inode sharing feature.
[Amir] added check for whiteout sharing support
and whiteout of lower dir.
Signed-off-by: Chengguang Xu <cgxu519@mykernel.net>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
exfat cannot do sparse files or negative timestamps, so exclude
tests which require these.
Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
_require_prjquota doesn't work on xfs unless the scratch device has
been mounted with project quota, so do that prior to the test.
older chattr/lsattr don't understand project quotas, so use xfs_io
instead for compatibility on older systems.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Add a test for new syncfs error reporting behavior. When an inode fails
to be written back, ensure that a subsequent call to syncfs() will also
report an error.
Kernel with the following patches should pass the test:
vfs: track per-sb writeback errors and report them to syncfs
buffer: record blockdev write errors in super_block that it backs
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Jeff Layton <jlayton@kernel.org>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
fssum currently has a duplicate '-x' flag, which is used for both
excluding paths and including xattrs. As the former is the only one
currently used in xfstests, this patch renames the latter to use '-t'.
Signed-off-by: Arvind Raghavan <raghavan.arvind@gmail.com>
Signed-off-by: Jayashree Mohan <jaya@cs.utexas.edu>
Signed-off-by: Vijay Chidambaram <vijay@cs.utexas.edu>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Reorder the order in which we tweak AGF fields to avoid falling afoul of
the new AGF sanity checks.
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>
It turns out that userspace actually does need the ability to write to
an active swapfile if userspace hibernation (uswsusp) is enabled.
Therefore, this test doesn't apply under those conditions.
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>
The setup code in this regression test case tries to figure out if
certain features known to be incompatible with realtime are known to
mkfs, and if so, to forcibly disable them.
Unfortunately, the reflink feature detection logic here is broken,
because we have no way of distinguishing between the helper function
_scratch_mkfs_xfs_supported returning nonzero because reflink isn't
compatible with mkfs's defaults (e.g. your mkfs has rmapbt=1 by default)
vs. reflink isn't recognized at all vs. something else broke.
However, we can grep the mkfs output to look for reflink support, and if
we find it then we disable it. That's fine for this test, since on XFS
it's trying to set up the exact conditions to test a known bug.
Second, rmapbt isn't currently compatible with realtime either, so we
need to detect and mask that off too.
Third, the test only needs to perform this feature detection if the test
runner didn't set SCRATCH_RTDEV, because we require that if the runner
configured SCRATCH_RTDEV, they also set MKFS_OPTIONS appropriately.
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>
Test that if we fsync a file with prealloc extents that start before and
after the file's size, we don't end up with missing parts of the extents
and implicit file holes after a power failure. Test both without and with
the NO_HOLES feature.
It is fixed commit f135cea30de5 ("btrfs: fix partial loss of
prealloc extent past i_size after fsync")
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Running xfs/126 sometimes fails due to output mismatch. Due to the
randomized nature of the test, periodically the selected bits are not
relevant to the test, or the selected bits are not flipped. Supply an
offset that is close to the start of the metadata block, so that the
test will reliably corrupt the header.
Suggested-by: Darrick J. Wong <darrick.wong@oracle.com>
Link: https://lore.kernel.org/linux-xfs/20200116160323.GC2149943@magnolia
Signed-off-by: Anthony Iliopoulos <ailiop@suse.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
We have very similar code that generates the destination range for clone,
dedupe and copy_file_range operations, so avoid duplicating the code three
times and move it into a helper function.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
While running generic/521 I've had fsx taking a lot of CPU time and not
making any progress for several hours. Attaching gdb to the fsx process
revealed that fsx was in the loop that generates the ranges for a
copy_file_range operation, in particular the loop seemed to never end
because the range defined by 'offset2' kept overlapping with the range
defined by 'offset'.
So far this happened one time only in one of my test VMs with generic/521.
Fix this by breaking out of the loop after trying 30 times, like we
currently do for dedupe operations, which results in logging the operation
as skipped.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
While running generic/457 I've had fsx taking a lot of CPU time and not
making any progress for over an hour. Attaching gdb to the fsx process
revealed that fsx was in the loop that generates the ranges for a clone
operation, in particular the loop seemed to never end because the range
defined by 'offset2' kept overlapping with the range defined by 'offset'.
So far this happened two times in one of my test VMs with generic/457.
Fix this by breaking out of the loop after trying 30 times, like we
currently do for dedupe operations, which results in logging the operation
as skipped.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Currently we are limiting the range for zero range operations to stay
within the i_size boundary. This is not optimal because like this we lose
coverage of the filesystem's zero range implementation, since zero range
operations are allowed to cross the i_size. Fix this by limiting the range
to 'maxfilelen' and not 'file_size', and update the 'file_size' after each
zero range operation if needed.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
This is a variant on test overlay/034.
This variant is mangling upper hardlinks instead of lower hardlinks
and does not require the inodes index feature.
This is a regression test for kernel commit 83552eacdfc0
("ovl: fix WARN_ON nlink drop to zero")
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
When overlayfs nfs_export feature is enabled by default in either kernel
config or module parameters, this test fails:
mount: /tmp/8751/mnt: mount(2) system call failed: Stale file handle.
cat: /tmp/8751/mnt/bar: No such file or directory
The reason is that nfs_export depends on index feature and with index
feature enabled, an upper/work dirs cannot be reused for mounting with
a different lower layer.
To reproduce the failure do:
echo Y > /sys/module/overlay/parameters/index
echo Y > /sys/module/overlay/parameters/nfs_export
before running the test.
Fix the failure by explicitly re-creating upper/work dirs.
Reported-by: Chengguang Xu <cgxu519@mykernel.net>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
The old setquota tool doesn't support project quota, it doesn't has
"-P, --project" option. So _notrun the test to avoid a failure.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that a new snapshot created with qgroup inherit passed should
mark qgroup numbers inconsistent.
Such inconsistent flag is required to show that we need a qgroup
rescan to make qgroup numbers correct again.
This is unavoidable since snapshot creation with qgroup inherit acts
as snapshot creation + qgroup relationship assign.
See btrfs(5) for why such operation needs qgroup rescan.
This test failed on current kernel, the fix is submitted to the btrfs
mail list titled:
"btrfs: qgroup: Mark qgroup inconsistent if we're inherting snapshot to a new qgroup"
Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Eric Sandeen
Omar Sandoval
Chengguang Xu
Eric Sandeen
Jeff Layton
Arvind Raghavan
mafeng 00292095
Darrick J. Wong
Filipe Manana
Anthony Iliopoulos
Yang Xu
Amir Goldstein
Zorro Lang
Qu Wenruo