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 an incremental send operation works correctly when an inode A
is renamed, a new hard link added to it and some other inode B is renamed
to the old name of inode A.
The btrfs bug is fixed by the following patch for the linux kernel:
"Btrfs: send, fix invalid path after renaming and linking file"
Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Some tests require the scratch volume to be a block device,
although they don't do anything block device specific like
the device mapper tests. They actually only require a local
device and fail with network or overlay pseudo mount devices.
The same tests also try to mount the scratch device manually
after running _scratch_mkfs. For UBIFS, _scratch_mkfs simply
truncates the UBI volume and relies on the kernel to re-format
the volume on the next mount. This fails if the fs type is not
specified explicitly when mounting.
This patch replaces the block device requirement with a
generic check for a local device and adds a filesystem
specification to all manual mounts of the scratch device
to a mount point.
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Some filesystems (e.g. UBIFS) fail with EPERM when trying to move a
file into an encrypted directory via cross rename, without having
access to the encryption key.
Since rename is perfectly allowed to return EPERM, which is also
tested for, and no precise specification seems to exist that
clarifies when to expect EPERM and when ENOKEY, this patch modifies
the generic/398 test to accept both, for the test case where the key
is not available.
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
UBIFS is a filesystem for unmanaged flash memory devices. It works
on top of UBI (Unsorted Block Images) which is a wear leveling and
volume management layer on top of flash memory devices, which are
handled by the MTD subsystem (memory technology device).
Since the semantics of flash devices are drastically different from
regular block devices (blocks or "pages" must be erased before
writing, only larger groups of pages or "erase blocks" can be erased
at once, page write must be in order within an erase block, etc...)
it was decided to expose MTD devices as character devices with
ioctls for operations like erase.
Since erasing a flash erase block causes physical wear on the
device, eventually causing the erase blocks to go bad, the UBI layer
provides mainly transparent wear leveling on top of MTD devices. UBI
does not attempt to emulate a regular block device, but rather
something like a flash memory with idealized characteristics that
can be partitioned into multiple UBI volumes in a fashion somewhat
similar to LVM. UBI volumes are also exposed to user space as
character devices.
This patch mainly deals with some quirks of UBIFS like working on
top of character devices instead of block devices. Also UBIFS
automatically formats UBI devices when trying to mount an empty
device. The mkfs.ubifs program is mainly used for creating images.
This patch changes _scratch_mkfs and _scratch_mkfs_encrypted to
truncate the UBI volume instead, relying on the kernel to reformat
it on the next mount.
For _scratch_mkfs_encrypted this is actually required to get the
encryption tests to run, because mkfs.ubifs, at the time of writing
this, the kernel support for UBIFS encryption is fairly recent and
mkfs.ubifs does not have proper support yet.
The necessity of an additional -ubifs switch was discussed but auto
detection of UBIFS formated UBI devices could not be reproduced on
my end and is unlikely to work with empty UBI volumes anyway.
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Implement _is_char_dev similar to _is_block_dev to test for
character devices.
Add a _require_local_device test. This test is similar to
_require_block_device but checks if the path refers to a
block or a character device.
Signed-off-by: David Oberhollenzer <david.oberhollenzer@sigma-star.at>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This is a regression test for patch "Btrfs: fix delalloc accounting
leak caused by u32 overflow". It creates a bunch of delalloc extents
and merges them together to make sure the accounting is done right.
[eguan: use $XFS_IO_PROG instead of xfs_io]
Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
When the filesystem is force-killed in generic/019 and fsstress is
compiled with DEBUG then it's possible for check_cwd() to fail. In
this case fsstress would just die and invoking kill on its pid would
produce an error to the output file:
+./tests/generic/019: line 157: kill: (32750) - No such process
Fix this possibility by ignoring the result of the output command,
this won't affect the test coverage.
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Make _require_group yield the correct error message when the
requested group is not found.
Signed-off-by: Nikolay Borisov <nborisov@suse.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>
listxattr reaturns a null-terminated list of entries that represent
the xattr names. However, if it is passed larger buffer than it
requires it won't zero-out the rest of the memory. The way the
loop iterator in listxattr.c is written makes it go print every
null-terminated entry up to bufsize (which is user passed parameter).
This can lead to a situation where listxattr users N bytes out of
M bytes big buffer ( M > N). This will leave the rest (M-N)
as garbage, which in turn will be printed by listxattr. Fix this
by converting the 'for' loop to 'while' and properly ensuring
we are reading at most howevermany elements the syscall reported
it returned
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Xiao Yang reported that fstests failed to build on RHEL6.9 hosts due
to old autoreconf didn't pass -I to aclocal -I. (This was fixed by
autoconf commit 44fbeef86d03 ("Pass autoreconf -I to aclocal -I"),
but not on RHEL6.9).
So call aclocal, autoheader and autoconf directly instead of
autoreconf, as what's done in xfsprogs Makefile.
Reported-by: Xiao Yang <yangx.jy@cn.fujitsu.com>
Reviewed-by: Xiao Yang <yangx.jy@cn.fujitsu.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>
Test nfs4_getfacl gets ACL list correctly from server when the ACL
length is close enough to the end of a page. On buggy NFS client
getxattr could return ERANGE. Upstream commit ed92d8c137b7 ("NFSv4:
fix getacl ERANGE for some ACL buffer sizes") fixed this bug in 4.11
kernel.
Note that this reproducer was originally written by J. Bruce Fields.
Cc: J. Bruce Fields <bfields@redhat.com>
Cc: Weston Andros Adamson <dros@primarydata.com>
Cc: linux-nfs@vger.kernel.org
Reviewed-by: J. Bruce Fields <bfields@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
The OpenSSL dependency was added for one program, fssum, and it needs
it only because it needs a md5 implementation. Use Solar Designer's
openssl compatible implementation of md5 so we no longer need to
depend on OpenSSL.
Since the OpenSSL libraries are not always available, we had to add
extra complexity to test to see whether fssum exists.
The other problem with depending on the OpenSSL libraries is that
shared library compatibility situation is terrible; a fssum binary
built on a system using libssl1.0.0 is *NOT* run on a system with
libssl1.0.2, since the shared libraries are incompatible even across a
minor version bump. (Sigh.)
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
_get_scsi_debug_dev is supposed to return a "/dev/$device".
However, in case the scsi device is not mapped to a disk, hence
/dev/sd* doesn't exist, then get_scsi_debug_dev would return only
the "/dev/" string. In generic/108 we check whether return value is
"" and only then consider it a failure. This behavior allows the
test to erroneously consider _get_scsi_debug_dev succeeded even if
it returned a malformed string. Fix this by correctly checking
whether the return value is "/dev/"
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
From xfsprogs v4.7, mkfs.xfs add respecification detection by
commit 9090e18. Then mkfs will fail and return if we run it
as below:
mkfs.xfs -m crc=1,finobt=1 -m crc=0 ....
Then _scratch_mkfs_xfs can deal with this problem. But for old
xfsprogs ( < v4.7), it replace the first "crc=1" with the second
"crc=0". Then "crc=0,finobt=1" cause a warning, but keep running:
"warning: finobt not supported without CRC support, disabled."
This extra warning breaks the golden image of xfs/288, so filter
it out in case.
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
linux XFS rename all "fail_writes" references to "drop_writes" in
v4.11. Some old kernel still use the name "fail_writes", e.g.
RHEL-7. For testing on old kernel, we need to fallback to
"fail_writes".
Signed-off-by: Zorro Lang <zlang@redhat.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Filesystesm with the "default behavior" will always return the
offset of the end of the file when lseek'ing with SEEK_HOLE. This
test does the following:
- fallocate 4 << 20 bytes
- write PAGE_SIZE bytes at offset 0
- writes PAGE_SIZE bytes at offset 4 << 20
Thus, using lseek in an FS with the "default behavior" will set the
position at 4 << 20 + PAGE_SIZE.
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Luis Henriques <lhenriques@suse.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
If xfs/293 is run on a system which doesn't have 'man' installed
it will hang the due to $CAT waiting for input indefinitely. Also
create an entry for $MAN_PROG and use the cached $MANPAGE instead
of repeatedy calling $MAN_PROG --page
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
I found that this test succeeds on UBIFS:
stat_test /mnt/foo attr=+compressed attr=-compressed
Since stx_attributes can hold many flags, check the flags
correctly with the & operator.
Signed-off-by: Richard Weinberger <richard@nod.at>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Most of the fixes are printf format type warnings, but apparently GCC
6 is smart enough to realize is that if you don't do proper error
checking with posix_memalign, the resulting pointer can be undefined,
and whines about it. So while fixing this in aio-dio-fcntl-race, I
also cleaned up the error checking and reporting.
Signed-off-by: Theodore Ts'o <tytso@mit.edu>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
When running xfstests on a kernel configured with CONFIG_AIO=n, all
AIO-related tests fail, often due to an error similar to the
following:
error Function not implemented during io_setup
This affected at least the following tests: generic/036,
generic/112, generic/113, generic/198, generic/207, generic/208,
generic/210, generic/211, generic/239, generic/323, generic/427,
xfs/240, xfs/241.
Fix this by enhancing the 'feature' program to allow testing for
asynchronous I/O support, then skipping all AIO-related tests when
AIO is unsupported.
This change is useful because CONFIG_AIO is sometimes disabled to
reduce the kernel's attack surface (e.g. see
https://android-review.googlesource.com/#/c/292158/).
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This is to test whether buffered read retry-repair code is able to
work in raid1 case as expected.
Please note that without checksum, btrfs doesn't know if the data
used to repair is correct, so repair is more of resync which makes
sure that both of the copy has the same content.
Commit 20a7db8ab3f2 ("btrfs: add dummy callback for
readpage_io_failed and drop checks") introduced the regression.
The upstream fix is commit 9d0d1c8b1c9d ("Btrfs: bring back repair
during read")
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Filipe Manana <fdmanana@gmail.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Commit 2dabb3248453 ("Btrfs: Direct I/O read: Work on sectorsized
blocks") introduced this regression. It'd cause 'Segmentation
fault' error.
The upstream fix is commit 97bf5a5589aa ("Btrfs: fix segment fault
when doing dio read")
Signed-off-by: Liu Bo <bo.li.liu@oracle.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Reviewed-by: Filipe Manana <fdmanana@gmail.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Eric Biggers
Filipe Manana
David Oberhollenzer
Omar Sandoval
Nikolay Borisov
Eryu Guan
Jan Kara
Theodore Ts'o
Zorro Lang
Luis Henriques
Richard Weinberger
Liu Bo