This IRIX-specific test mainly tested whether a file's capabilities are
cleared when it is written to. Port the test to the Linux libcap tools
and update it to expect the Linux semantics which are a little simpler:
capabilities are always cleared even if the program is root (or has
CAP_FSETID). The test also tests that chmod doesn't affect open file
descriptors; this is mostly unrelated, but keep it in for now.
[eguan: add _require_test_program rule for src/writemod]
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Check that the group permission bits of a file are not altered when
setfacl fails. At the time of this patch the test fails for at least
ext2, ext4, jfs and btrfs.
The failure in setfacl is induced by filling the device and setting
as many user attributes to the file as possible. For xfs this is not
enough, and the test will not run.
[eguan replaced setfattr with $SETFATTR_PROG and added enospc group]
Signed-off-by: Ernesto A. Fernández <ernesto.mnd.fernandez@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Check that we get -ENXIO if the user calls SEEK_HOLE/SEEK_DATA with
a negative file offset.
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>
Test a regression in XFS where we blow out a transaction reservation if
we create a big file, share every other block, and delete the first
file. There's nothing particularly fs-specific about this stress test,
so put it in generic.
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>
This test reproduces a race between a direct I/O read and
a mapped write to a hole in a file. On xfs filesystem, it
will trigger a BUG_ON(), and this XFS bug has been fixed by:
04197b3 ("xfs: don't BUG() on mixed direct and mapped I/O")
[ eguan: umount before check dmesg log, and add rw group ]
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>
Both ext4 and xfs have a bug in the page cache scanning code for
SEEK_HOLE / SEEK_DATA in unwritten extents: the start offset isn't
taken into account when scanning a page, so seeking can fail on
filesystems with a block size less than half of the page size. For
example, the following command fails on a filesystem with a block
size of 1k:
xfs_io -f -c "falloc 0 4k" \
-c "pwrite 1k 1k" \
-c "pwrite 3k 1k" \
-c "seek -a -r 0" foo
Like with generic/436, the actual tests are added to seek_sanity_test.
Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test that subdirectory properly inherits SGID bit even if parent
directory has default ACLs.
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
We met a kernel assertion failure recently as below:
XFS: Assertion failed: tp->t_blk_res_used <= tp->t_blk_res, file: fs/xfs/xfs_trans.c, line: 309
Eric Sandeen digged into it and find a good reproducer.
The problem comes when the several IO vectors are copied in, and
it runs into page faults, which stops the copy before all vectors
are copied. XFS sees this as a failed/short write, and so tries
to unmap the blocks & truncate away the pages in xfs_vm_write_end.
generic_perform_write is looping, and comes back around for the
other iovecs, but the page is still there, the buffer head is still
mapped, and so a new delalloc block isn't allocated - and ends up
being allocated at writeback time, despite the fact that we "should"
have accounted for it all at delalloc write time, and trips the
assert.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Ensure that we get an error back on all fds when a block device is
open by multiple writers and writeback fails.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
I'm working on a set of kernel patches to change how writeback errors
are handled and reported in the kernel. Instead of reporting a
writeback error to only the first fsync caller on the file, it has
the the kernel report them once on every file description that was
open at the time of the error.
This patch adds a test for this new behavior. Basically, open many fds
to the same file, turn on dm_error, write to each of the fds, and then
fsync them all to ensure that they all get an error back.
To do that, I'm adding a new tools/dmerror script that the C program
can use to load the error table from the script. It's also suitable for
setting up, frobbing and tearing down a dmerror device for by-hand testing.
For now, only ext2/3/4 and xfs are whitelisted on this test, since those
filesystems are included in the initial patchset. We can add to that as
we convert filesystems, and eventually make it a more general test.
Signed-off-by: Jeff Layton <jlayton@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Add a regression test for a bug where ->lookup() in an encrypted
directory would incorrectly return EPERM, depending on which inodes
happened to have their keys still cached in memory following removal of
the keyring key. This bug was fixed in v4.12-rc1, v4.9.29, and v4.4.70.
Cc: linux-fscrypt@vger.kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test that if we punch a hole in a file, with either a range that goes
beyond the file's size or covers a file range that is already a hole,
and that if after we do some buffered write operations that cover
different parts of the hole, no warnings are emmitted in syslog/dmesg
and the file's content is correct after remounting the filesystem.
This test is motivated by a bug in btrfs that is manifested in kernel
4.12-rc1 onwards (the bug existed long time ago but was not so easy
to expose before 4.12-rc1). The btrfs patch that fixes the issue is
titled: "Btrfs: fix invalid extent maps due to hole punching".
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Add test checking for a race in ext4 writeback that could result in
zeroing too much from the tail page during writeback.
[eguan: removed from quick group, it needs longer time on xfs and
btrfs]
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This adds a regression test for the following kernel patches:
mm: avoid spurious 'bad pmd' warning messages
dax: Fix race between colliding PMD & PTE entries
The above patches fix two related PMD vs PTE races in the DAX code.
These can both be easily triggered by having two threads reading and
writing simultaneously to the same private mapping, with the key
being that private mapping reads can be handled with PMDs but
private mapping writes are always handled with PTEs so that we can
COW.
Without this 2-patch kernel series, the newly added test will result
in the following errors:
run fstests generic/437 at 2017-05-16 16:53:43
mm/pgtable-generic.c:39: bad pmd ffff8808daa49b88(84000001006000a5)
... a bunch of the bad pmd messages ...
BUG: Bad rss-counter state mm:ffff8800a8c1b700 idx:1 val:1
BUG: non-zero nr_ptes on freeing mm: 38
XFS (pmem0p1): Unmounting Filesystem
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>
Add tests for bugs found in ext4 & xfs SEEK_HOLE implementations
fixed by following patches:
xfs: Fix missed holes in SEEK_HOLE implementation
ext4: Fix SEEK_HOLE
We add tests to seek_sanity_test as it is easiest to reuse its
infrastructure for seek tests, however not to regress generic/285
which uses seek_sanity_test we don't run new tests by default.
Instead we add options to select a range of tests to run and run new
tests from this new test.
[eguan: add $tmp definition and cleanup $tmp.* on exit]
Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Add a test which creates many similarly-named files in an encrypted
directory, then verifies they can be deleted without access to the
encryption key. This is a regression test for two related bugs which
caused presented names to "collide" and point to the wrong inodes.
These bugs were present in the original versions of ext4 and f2fs
encryption, and they were fixed in v4.12-rc1.
Cc: linux-fscrypt@vger.kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This test passes invalid argumnt combinations to the copy_file_range()
system call to test that input is verified before attempting to copy.
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This test is similar to the previous one, except that it copies one
byte at a time to make sure that this case works as expected.
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Using copy to overwrite data in the destination file is perfectly
valid, so let's make sure this case works as expected.
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This test copies single bytes from a source file into various new
files just to make sure that we can handle very small copies.
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This test copies data from various points in a source file to a new
file. This is useful for testing the basics of copy_file_range().
Signed-off-by: Anna Schumaker <Anna.Schumaker@Netapp.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Add a test which verifies that dentries in an encrypted directory
are invalidated when an encryption key is added --- which should
cause the plaintext filenames to be visible and accessible,
replacing the encoded ciphertext filenames and any negative dentries
for the plaintext names. This primarily tests for a bug which was
fixed in the v4.5 kernel, plus a v4.6 fix for incorrect RCU usage in
the earlier fix.
Cc: linux-fscrypt@vger.kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.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>
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>
Eric Biggers
Ernesto A. Fernández
Darrick J. Wong
Xiao Yang
Andreas Gruenbacher
Jan Kara
Zorro Lang
Jeff Layton
Filipe Manana
Ross Zwisler
Anna Schumaker
Amir Goldstein