Jeff Mahoney pointed out that 'security.evm' actually has an expected
value format, which breaks the test if EVM is enabled. It turns out
that the 'security.evm' setxattr call in the original syzkaller report
was a total red herring, as this bug can be reproduced without it.
Fix the test case to do the minimum amount of work needed to reproduce
the corruption.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Allison Henderson <allison.henderson@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
For the t_open_tmpfiles tests, limit ourselves to half of file-max
so that we don't OOM the test machine.
[Eryu: fix comments too to match the new limit]
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Allison Henderson <allison.henderson@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Copy original offsets and length and use them for logging as in
splice_f. Fix grammar mistakes in the comment about them.
Signed-off-by: Rostislav Skudnov <rostislav@tuxera.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
For some filesystem, such as vfat, the max support file size is 4G.
We limit the max size and let the test go on running.
Fix it by moving the function get_max_file_size() of generci/485 to
common/rc, and add the max filesize limit to generic/299.
Signed-off-by: Yufen Yu <yuyufen@huawei.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Add support for btrfs in shared/298. Achieve this by introducing 2
new awk scripts that parse relevant btrfs structures and print holes.
Additionally modify the test to create larger - 3gb filesystem in the
case of btrfs. This is needed so that distinct block groups are used
for data and metadata.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Compiling t_open_tmpfiles.c failed on older glibc(before glibc v2.17)
because clock_gettime(2) was not linked with -lrt, as below:
--------------------------------------------------------------------
/home/yangxiao/xfstests/src/t_open_tmpfiles.c:36: undefined reference to `clock_gettime'
--------------------------------------------------------------------
According to clock_gettime(2) manpage, we should link clock_gettime(2)
with -lrt on older glibc.
Signed-off-by: Xiao Yang <yangx.jy@cn.fujitsu.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Apparently newer versions of libattr (which haven't yet been picked
up by Debian or Ubuntu) don't ship xattr.h anymore, because we're
supposed to use the libc version in sys/xattr.h. So do that.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
No dedup functionality is exercised by these tests.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
If the caller of t_open_tmpfiles wants to shut down the filesystem,
be sure to flush the log when we shut down so that log recovery will
have to process all the unlinked temporary files.
This is apparently needed to force ext4 to flush updated inode
blocks through the journal at all.
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>
This test needs to check for working falloc command before using it.
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>
A test to perform reads/writes under various cgroups and verify that
I/Os are accounted properly according to cgroup aware writeback.
This is a generic test, but not all commonly used local filesystems
support cgroup aware writeback at the moment (i.e., XFS). Therefore,
this test currently requires ext4 or btrfs for the time being.
The common/cgroup2 file is copied from a separate cgroup related
patch from Shaohua Li that never made it upstream.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Shaohua Li <shli@fb.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Create a test (+ helper program) that opens as many unlinked files as it
possibly can on the scratch filesystem, then closes all the files at
once to stress-test unlinked file cleanup. Add an xfs-specific test to
make sure that the fallback code doesn't bitrot.
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>
If the XFS error injection knob directory exists but the knob itself
doesn't, then we know that this kernel doesn't support the knob and
can skip the test.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
XFS had a use-after-free bug when xfs_xattr_put_listent runs out of
listxattr buffer space while trying to store the name
"system.posix_acl_access" and then corrupts memory by not checking
the seen_enough state and then trying to shove
"trusted.SGI_ACL_FILE" into the buffer as well.
In order to tickle the bug in a user visible way we must have
already put a name in the buffer, so we take advantage of the fact
that "security.evm" sorts before "system.posix_acl_access" to make
sure this happens.
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>
If statx returns inode creation time (aka btime), check it to make
sure that the filesystem is setting a creation time that's
reasonably close to when it creates a file.
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>
Filesystems are not required to try to fill the statx btime field
unless the caller actually sets STATX_BTIME. They're allowed to
volunteer that information "if it's cheap", but XFS doesn't
volunteer and there may be filesystems that support btime but not
cheaply.
Either way, we want to test btime on any filesystem that supports
it, cheaply or otherwise, so set STATX_BTIME when we're trying to
detect support for it.
[Eryu: fix _require_scratch_btime too]
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>
Refactor the kmemleak code to work correctly with sections. This
requires changing the location of the "is kmemleak enabled?" flag to
use /tmp instead of RESULT_BASE, scanning for leaks after every
test, and clarifying which functions get used when.
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>
Currently generic/075 and generic/112 have two extra fsx passes each
that exercise fsx with preallocation, which are only enabled for
XFS.
These tests can also be run with other file systems, given that the
XFS prealloc ioctls are implemented in generic code since the
addition of the fallocate system call. This also means a version of
XFS that does not support preallocation (e.g. because it always
writes out of place) can skip the prealloc tests while still
completing the normal fsx tests just fine.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Regression test for read corruption of compressed and shared extents
after punching holes into a file. The same extent is shared by the
same file in consecutive ranges (without other extents in between).
This is motivated by a bug recently found in btrfs for which there
is a patch for the linux kernel titled:
"Btrfs: fix corruption reading shared and compressed extents after hole
punching"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Test that after a combination of file renames, linking and creating
a new file with the old name of a renamed file, if we fsync the new
file, after a power failure we are able to mount the filesystem and
all file names correspond to the correct inodes.
This test is motivated by a bug found in btrfs, which is fixed by
applying the following two patches to the linux kernel:
"[PATCH 1/2] Btrfs: fix fsync after succession of renames of different files"
"[PATCH 2/2] Btrfs: fix fsync after succession of renames and unlink/rmdir"
The test passes on ext4, xfs and patched btrfs, however at least in
a 5.0-rc5 linux kernel, it fails on f2fs.
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <guaneryu@gmail.com>
Signed-off-by: Eryu Guan <guaneryu@gmail.com>
Darrick J. Wong
Rostislav Skudnov
Yufen Yu
Nikolay Borisov
Xiao Yang
Christoph Hellwig
Brian Foster
Zorro Lang
Filipe Manana