Regression test for kernel commit:
023cc840 xfs: handle array index overrun in xfs_dir2_leaf_readbuf()
See commit for detailed problem description.
tl;dr: readahead on weirdly fragmented multi-block directories
was broken.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Overlayfs directory inodes are constant across copy up,
but not persistent on mount cycle.
Compare the inode numbers before and after mount cycle.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
The test verifies constant inode number after copy up.
Verify that inode number remains constant also after rename
and drop caches (when overlayfs needs to find the lower
inodes in another location).
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Use helpers to records and check inode numbers so we can repeat
the same test after rename and mount cycle.
Suggested-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Align all comments to the term 'constant inode numbers' and
explain why hardlinks are excluded from this test.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Change test to output golden silence on success.
We are going to run the same check several times,
so instead of cloning the test output, cloning the
silence will be more conveniet.
Generalize cleanup of temp files for the same reason.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
xfs_growfs manpage clearly states that the target path must be an
active xfs mountpoint. This is a test to ensure that if the target
path isn't an active xfs mountpoint, the command is rejected. The
purpose is to check the command response, but not necessarily the
functionality of xfs_growfs. Test cases include absolute paths,
relative paths, symbolic links, and bind mounts.
Signed-off-by: Bill O'Donnell <billodo@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This adds a regression test for the following kernel patch:
dax: fix data corruption due to stale mmap reads
The above patch fixes an issue where users of DAX can suffer data
corruption from stale mmap reads via the following sequence:
- open an mmap over a 2MiB hole
- read from a 2MiB hole, faulting in a 2MiB zero page
- write to the hole with write(3p). The write succeeds but we incorrectly
leave the 2MiB zero page mapping intact.
- via the mmap, read the data that was just written. Since the zero page
mapping is still intact we read back zeroes instead of the new data.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
It's possible for post-eof blocks to end up being used for direct
I/O writes. dio write performs an upfront unwritten extent
allocation, sends the dio and then updates the inode size (if
necessary) on write completion. If a file release occurs while a
file extending dio write is in flight, it is possible to mistake the
post-eof blocks for speculative preallocation and incorrectly
truncate them from the inode. This means that the resulting dio
write completion can discover a hole and allocate new blocks rather
than perform unwritten extent conversion.
A kernel warning can be reproduced by generic/299 on XFS:
XFS: Assertion failed: tp->t_blk_res_used <= tp->t_blk_res, \
file: fs/xfs//xfs_trans.c, line: 309
The root cause is that xfs_free_eofblocks() uses i_size to truncate
post-eof blocks from the inode, but async, file extending direct
writes do not update i_size until write completion, long after inode
locks are dropped. Therefore, xfs_free_eofblocks() effectively
truncates the inode to the incorrect size.
Besides reproduce above kernel warning, the verification of written
data is an important distinction between this test and generic/299.
For cover this filesystem corruption testing, write this new case to
check data integrality manually, not only depend on a kernel
warning.
To increase the test stress of aio-dio-eof-race, add two arguments
to this source code to change the file size will be written.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
There was a bug during log replay, the attr/attr3 leaf verifier
reported corruption when encountering a leaf attribute with a
count of 0 in the header, as below:
Metadata corruption detected at xfs_attr3_leaf block 0x480988/0x1000
commit f714016 from xfsprogs has fixed this bug. This test case
will emulate this corruption by xfs_db and use xfs_repair to fix
it.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
We were declaring local arrays using a notation that does not seem to be
standard resulting in failures on some systems, like for example in a
Debian Stretch installation with bash version 4.4.11(1)-release:
$ ./check btrfs/003 btrfs/027
FSTYP -- btrfs
PLATFORM -- Linux/x86_64 debian3 4.10.0-rc8-btrfs-next-37+
MKFS_OPTIONS -- /dev/sdc
MOUNT_OPTIONS -- /dev/sdc /home/fdmanana/btrfs-tests/scratch_1
btrfs/003 45s ... [failed, exit status 1] - output mismatch (see /home/fdmanana/git/hub/xfstests/results//btrfs/003.out.bad)
--- tests/btrfs/003.out 2016-08-23 10:17:35.027012095 +0100
+++ /home/fdmanana/git/hub/xfstests/results//btrfs/003.out.bad 2017-04-21 15:53:58.807366940 +0100
@@ -1,2 +1,4 @@
QA output created by 003
-Silence is golden
+./tests/btrfs/003: line 102: devs[]: bad array subscript
+dev balance failed
+(see /home/fdmanana/git/hub/xfstests/results//btrfs/003.full for details)
...
(Run 'diff -u tests/btrfs/003.out /home/fdmanana/git/hub/xfstests/results//btrfs/003.out.bad' to see the entire diff)
btrfs/027 7s ... [failed, exit status 1] - output mismatch (see /home/fdmanana/git/hub/xfstests/results//btrfs/027.out.bad)
--- tests/btrfs/027.out 2016-08-23 10:17:35.035012077 +0100
+++ /home/fdmanana/git/hub/xfstests/results//btrfs/027.out.bad 2017-04-21 15:53:59.835367271 +0100
@@ -1,2 +1,7 @@
QA output created by 027
Silence is golden
+./common/rc: line 935: devs[]: bad array subscript
+./common/rc: line 893: devs[]: bad array subscript
+mkfs -m raid1 -d raid1 failed
+Bug: str empty, must call _spare_dev_get before its put
+(see /home/fdmanana/git/hub/xfstests/results//btrfs/027.full for details)
...
(Run 'diff -u tests/btrfs/027.out /home/fdmanana/git/hub/xfstests/results//btrfs/027.out.bad' to see the entire diff)
Ran: btrfs/003 btrfs/027
Failures: btrfs/003 btrfs/027
Failed 2 of 2 tests
So fix this by changing the declaration pattern "local dev[]=..." to the
standard way of "local -a dev=...".
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
On ext4 filesystem, the kernel carshes at mount time when
s_first_meta_bg's value exceeds the largest possible meta_bg
number. This kernel bug has been fixed in:
3a4b77c ext4: validate s_first_meta_bg at mount time
[eguan: add comments on the first_meta_bg value]
Signed-off-by: Xiao Yang <yangx.jy@cn.fujitsu.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
xfs/293 is supposed to make sure every command in xfs_io
is documented, but it was missing the inode command because
it's a common word, and depending on how man formatted the
page, the magic " inode" string could show up and appear
to indicate that documentation is present for the command
when it's not actually there.
Change the test to inspect the manpage source directly, with
the assumption that each documented command will start
with ^\.B.*$COMMAND on a manpage line.
This handles a few different compressed manpage formats -
I don't know if anybody uses bz2 or xz, but hey.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Cloned from xfs specific test xfs/238, which checks
stale file handles of deleted files.
This test uses the generic open_by_handle_at() syscall
and also tests for non-stale file handles of linked files.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
We introduced the inline directory verifier in 4.11 to prevent the
system from trying to use corrupt inline directories. This has the
effect of changing the error message in one step of the i_mode fuzz
tester, so update the test accordingly.
Note that prior to the existence of the verifier, this test would
occasionally result in memory corruption that did not become evident
until later.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Make sure that FIEMAP produces some output when we add enough xattrs
to force the xattrs to be stored in an external block.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Since snapshot aware defrag has been disabled in kernel, and we all
have learned to ignore the failure of btrfs/010, lets just remove
it.
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Check the stx_attributes that can be set by calling chattr.
The script probes the filesystem with chattr to find out which of
+a, +c, +d and +i are supported before testing combinations of
attrs. Note that if a filesystem supports chattr with these, but
doesn't paste the flag values into stx_attributes, the test will
fail as there's no way to distinguish cleared from unset.
Certain chattr flags are reflected in specific stx_attributes flags:
chattr flag stx_attributes flag
+a STATX_ATTR_APPEND
+c STATX_ATTR_COMPRESSED
+d STATX_ATTR_NODUMP
+i STATX_ATTR_IMMUTABLE
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Add a statx test script that does the following:
(1) Creates one each of the various types of file object and creates a
hard link to the regular file.
Note that the creation of an AF_UNIX socket is done with netcat in a
bash coprocessing thread. This might be best done with another
in-house helper to avoid a dependency on nc.
(2) Invokes the C test program included in this patch after the creation
and hands it a list of things to check appropriate to each object.
(3) Asks the test program to check the creation time of each object
against that of the preceding object.
(4) Makes various tests on the timestamps of the hardlinked file.
The patch also creates a C[*] test program to do the actual stat checking.
The test program then does the following:
(1) Compares the output of statx() to that of fstatat().
(2) Optionally compares the timestamps to see that they're sensibly
ordered with respect to each other.
(3) Optionally compares the timestamps to those of a reference file.
(4) Optionally compares the timestamps to a specified time.
(5) Optionally compares selected stats to values specified on the command
line.
(6) Optionally compares all the stats to those of a reference file,
requiring them to be the same (hard link checking).
For example:
./src/stat_test /dev/null \
stx_type=char \
stx_rdev_major=3 \
stx_rdev_minor=8 \
stx_nlink=1 \
ref=/dev/zero \
ts=B,b
The test program can also be given a --check-statx parameter to give a
quick exit code-based answer on whether statx() exists within the kernel.
[*] Note that it proved much easier to do this in C than trying to do it in
shell script and trying parsing the output of xfs_io. Using xfs_io has
other pitfalls also: it wants to *open* the file, even if the file is
not an appropriate type for this or does not grant permission to do so.
I can get around this by opening O_PATH, but then xfs_io fails to
handle XFS files because it wants to issue ioctls on every fd it opens.
Signed-off-by: David Howells <dhowells@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This fixes a merge error in last update, "-k" should be passed to
_require_xfs_io_command() as a separate parameter.
Signed-off-by: Eryu Guan <eguan@redhat.com>
Run the t_immutable test program for immutable/append-only files
and directories in an overlayfs upper directory.
This test is similar and was derived from generic/079, but
the original test is _notrun on overlay mount because FS_IOC_GETFLAGS
FS_IOC_SETFLAGS ioctls fail on overlay directory inodes.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
So that the test is skipped for filesystems that don't support it
instead of failing (like NFS 4.2 for example).
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test that a filesystem's implementation of the stat(2) system call
reports correct values for the number of blocks allocated for a file
when there are delayed allocations.
This test is motivated by a bug in btrfs which is fixed by the
following path for the linux kernel:
"Btrfs: fix reported number of inode blocks"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Eric Sandeen
Amir Goldstein
Bill O'Donnell
Ross Zwisler
Zorro Lang
Filipe Manana
Xiao Yang
Eric Sandeen
Darrick J. Wong
Liu Bo
David Howells
Eryu Guan