Add a test which revokes a keyring key while other processes are
performing I/O on an encrypted file that was "unlocked" using that key.
The crashes unpatched kernels with filesystem encryption enabled.
This bug was present in kernels v4.2 and later. It has been fixed in
v4.11-rc4, v4.10.7, v4.9.20, and v4.4.59.
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: Richard Weinberger <richard@nod.at>
Cc: Michael Halcrow <mhalcrow@google.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Verify that punching holes at ends of files does not alter st_size
if we pass FALLOC_FL_KEEP_SIZE to fallocate().
[eguan: add comment about xfs_io's fpunch KEEP_SIZE flag]
Signed-off-by: Calvin Owens <calvinowens@fb.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Add a new test to test another behavior when accessing encrypted
files without the key: renames should be forbidden, even though they
may be possible cryptographically. Test both a regular rename and a
cross rename. (It happens that generic/398 also covers the cross
rename case, but it's primarily for a different reason.)
Cc: Theodore Ts'o <tytso@mit.edu>
Cc: Jaegeuk Kim <jaegeuk@kernel.org>
Cc: Richard Weinberger <richard@nod.at>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test if direct write invalidates pagecache correctly, so that
subsequent buffer read reads the correct data from disk.
This test is inspired by LTP tests dio29, and serves as a regression
test for the bug found by it, see kernel commit c771c14baa33
("iomap: invalidate page caches should be after iomap_dio_complete()
in direct write").
The test can be easily expanded to other write/read combinations,
e.g. buffer write + direct read and direct write + direct read, so
they are also being tested.
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
There's a bug in xfs where the orphan inode list
is not processed on a readonly mount, and is still not
processed even if it gets mounted rw. This test exercises
that, and makes sure that the unlinked list is empty after
a transition to rw and an unmount.
While we're at it, sanity check the same thing for pure ro
and rw unmounts.
Now that shutdown is generic, we can test other filesystems
as well, so this is in the generic group.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This test case will test if file system works well when handling
large write while available space are all fragmented.
This can expose a bug in a btrfs unmerged patch, which wrongly
modified the delayed allocation code, to exit before allocating all
space, and cause hang when unmounting.
The wrong patch is:
[PATCH v6 1/2] btrfs: Fix metadata underflow caused by btrfs_reloc_clone_csum error
The test case will:
1) Fill small filesystem with page sized small files
All these files has a sequential number as file name
2) Remove files with odd number as file name
This will free almost half of the space
3) Try to write a file which takes 1/8 of the file system
The method to create fragmented fs may not be generic enough, but
should work for most extent based fs. Unless one file system will
allocate extents from both end of its free space.
Cc: Filipe Manana <fdmanana@kernel.org>
Cc: Liu Bo <bo.li.liu@oracle.com>
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
perform read operation on the target file while
doing write or fpunch operations on the reflinks.
Signed-off-by: Nave Vardy <nave.vardy@plexistor.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
If we reflink a file with N blocks to another file one block at a time,
does the destination file end up with the same number of extents as the
source file? In other words, does the filesystem succeed at combining
adjacent mappings into a maximal extents?
Signed-off-by: Darrick J. Wong <djwong@djwong.org>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Apparently btrfs already has tests marked as belonging in the defrag
group, but none of the ext4 or generic tests were so marked.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Mount TEST_DEV as non-DAX, SCRATCH_DEV as DAX, then
do some IO between them. In this case we use mmap
and dio/buffered IO read/write test programme.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: Xiong Zhou <xzhou@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test that if we have a file with a hole, do a mix of direct IO and
buffered writes to it and truncate the file to a size that lies in
the middle of the hole, after unmounting and mounting again the
filesystem, the file has a correct size and no data loss happened.
This test is motivated by a bug found in btrfs when used with the
no-holes feature (i.e. MKFS_OPTIONS="-O no-holes") which is fixed by
the following patch for the linux kernel:
Btrfs: fix data loss after truncate when using the no-holes feature
[eguan: add _require_odirect]
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This test cover linux commit 7ae8fd0, when mnt_group_id=0, it means
this mount no peers. But this bug treat two zero mnt_group_id as
peers. And it cause a crash by dereference a NULL address.
As below, the crash will happen when mount fs on "B/mnt1/mnt2":
shared New FS shared
-----------------------[A/mnt1]----------------------
| | |
| bind | bind |
[C/mnt1]--[slave C]<------[shared A]------>[slave B]--[B/mnt1]
|
|
[B/mnt1/mnt2]
(New FS)
Signed-off-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This case will do function test for mount --make-* operations, it
will verify below state transition:
------------------------------------------------------------------------
| |make-shared | make-slave | make-private |make-unbindab|
--------------|------------|--------------|--------------|-------------|
|shared |shared |*slave/private| private | unbindable |
| | | | | |
|-------------|------------|--------------|--------------|-------------|
|slave |shared | **slave | private | unbindable |
| |and slave | | | |
|-------------|------------|--------------|--------------|-------------|
|shared |shared | slave | private | unbindable |
|and slave |and slave | | | |
|-------------|------------|--------------|--------------|-------------|
|private |shared | **private | private | unbindable |
|-------------|------------|--------------|--------------|-------------|
|unbindable |shared |**unbindable | private | unbindable |
------------------------------------------------------------------------
This case uses fsstress to produce a small random load, to make sure
basic operations on the mountpoints won't cause hang or panic etc.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This case will do function test for mount bind operation, it will
verify below semantics:
---------------------------------------------------------------------------
| BIND MOUNT OPERATION |
|**************************************************************************
|source(A)->| shared | private | slave | unbindable |
| dest(B) | | | | |
| | | | | | |
| v | | | | |
|**************************************************************************
| shared | shared | shared | shared & slave | invalid |
| | | | | |
|non-shared| shared | private | slave | invalid |
***************************************************************************
This case usees fsstress to produce a small random load, to make
sure basic operations on the bind mountpoints won't cause hang or
panic etc.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
On btrfs, if a large dio write (>=128MB) got splitted, the
outstanding_extents assertion would complain. Note that
CONFIG_BTRFS_ASSERT is required.
Regression test for
Btrfs: adjust outstanding_extents counter properly when dio write is split
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Test mkfs against thin provision device, which has very small
backing size and very big virtual size. mkfs should return error
when it hits EIO.
Signed-off-by: Boyang Xue <bxue@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Regression test which targets two nasty ext4 bugs in a logic which
shifts extents:
1) 14d981f468a1 ("ext4: Include forgotten start block on fallocate insert range")
Test tries to insert many blocks at the same offset to reproduce
the following layout on ext4:
block #0 block #1
|ext0 ext1|ext2 ext3 ...|
^
insert of a new block
Because of an incorrect range first block is never reached,
thus ext1 is untouched, resulting to a hole at a wrong offset:
What we got:
block #0 block #1
|ext0 ext1| ext2 ext3 ...|
^
hole at a wrong offset
What we expect:
block #0 block #1
|ext0 ext1|ext2 ext3 ...|
^
hole at a correct offset
2) 2b3864b32403 ("ext4: do not polute the extents cache while shifting extents")
Extents status tree is filled in with outdated offsets while doing
extent shift, that leads to wrong data blocks. That's why md5sum
of a result file is being checked after each block insert.
Signed-off-by: Roman Pen <roman.penyaev@profitbricks.com>
Cc: "Theodore Ts'o <tytso@mit.edu>"
Cc: Eryu Guan <eguan@redhat.com>
Cc: linux-ext4@vger.kernel.org
Cc: fstests@vger.kernel.org
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This test reproduces a bug in XFS where a getxattr of an existing
xattr returns failure due to a race with a setxattr that causes
inode attribute fork conversion.
Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
The test helps to validate clamping and mount behaviors
according to supported file system timestamp ranges.
Note that the test can fail on 32-bit systems for a
few file systems. This will be corrected when vfs is
transitioned to use 64-bit timestamps.
Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Verify correct d_type values of dir entries.
This test does NOT require that file system support the filetype
feature. It verifies that either all file types are reported as
DT_UNKNOWN or that all file types are reported correctly.
For fs for which we know how to test the filetype feature (xfs|ext*)
verify getting DT_UNKNOWN IFF filetype feature is disabled.
Special dir entries . and .. MAY be reported as DT_UNKNOWN IF
filetype feature is disabled (ext4), but MAY also be reported as
DT_DIR in this case (xfs).
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
XFS kernel code had a bug where GETNEXTQUOTA-type
quotactls requesting an ID near UINT_MAX could overflow
and return 0 as the "next" active ID.
This test checks that by creating an active quota near
UINT_MAX, then asking for the next one after it.
The proper answer is ENOENT, but if we wrap we'll return
ID 0.
This also changes test-nextquota.c so that it checks
both GETNEXTQUOTA and XGETNEXTQUOTA even if one fails;
it stores the failure conditions and returns 1 if either
of them fails.
Signed-off-by: Eric Sandeen <sandeen@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Add an xfstest which can detect some basic crypto mistakes that would
reduce the confidentiality guarantee provided by filesystem encryption.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Eric Biggers
Calvin Owens
Eryu Guan
Eric Sandeen
Qu Wenruo
Nave Vardy
Darrick J. Wong
Theodore Ts'o
Xiong Zhou
Filipe Manana
Zorro Lang
Christoph Hellwig
Liu Bo
Boyang Xue
Roman Pen
Brian Foster
Deepa Dinamani
Amir Goldstein
Eric Sandeen