Test accessing encrypted files and directories, both with and
without the encryption key.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Add an xfstest which verifies the kernel performs basic validation
of the encryption policy structure.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Several kernel bugs were recently fixed regarding the constraints
for setting encryption policies. Add tests for these cases and a
few more.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Add utility functions for testing filesystem-level encryption via
the common API currently supported by ext4 and f2fs, in development
for ubifs and planned for xfs. Setting and getting encryption
policies will use new commands being added to xfs_io, while adding
and removing encryption keys will use keyctl.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Btrfs upstream doesn't accept stream-version, so the test is never
ran on upstream kernel nor btrfs-progs.
Just remove it.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Currently in _scratch_mkfs only xfs and ext4 could handle the mkfs
failure caused by conflicts between $MKFS_OPTIONS and mkfs options
specified by tests, because of _scratch_mkfs_xfs and
_scratch_mkfs_ext4. This is a very useful functionality that allows
tests to specify mkfs options safely and to test specific fs
configurations, without worrying about mkfs failures caused by these
options.
Now teach _scratch_mkfs to handle such mkfs option conflicts for
other filesystems too, i.e. mkfs again only with mkfs options
specified by tests. Also add the ability to filter unnecessary
messages from mkfs stderr.
Also update some btrfs tests to throw away _scratch_mkfs stdout,
because previously _scratch_mkfs did this for btrfs.
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
If a file size limitation is set, underlying filesystem should not
break the limit and exceed the max file size.
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Introduce a new test to demonstrate a known issue with overlayfs:
- file A and B are hardlinked in lower
- modify A to trigger copy up
- file A is no longer a hardlink of file B
There is no fix for this issue at this time.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
generic/062 uses getfattr to dump xattrs for a directory tree, then
deletes and recreates that directory tree, then dumps the xattrs
again and compares the dump to the original. This was failing when
run on ext4 with encryption enabled because getfattr's output is in
readdir order, but ext4 encryption by design chooses unpredictable
encrypted filenames for each new directory, causing the readdir
order to change after backup and restore. It is not really a valid
assumption that the readdir order will always be the same, so update
the test to sort the filenames, removing this assumption.
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Brian Foster <bfoster@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Tests 016 and 013 both test behavior of concurrent
file access during copy up (truncate+exec and read+write).
Associate those tests to the copyup group.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Introduce a new test to demonstrate a known issue with overlayfs:
- stat file A shows inode number X
- modify A to trigger copy up
- stat file A shows inode number Y != X
Also test if d_ino of readdir entries changes after copy up.
There is a POC patch by Miklos Szeredi that fixes this issue.
Not dealing with hardlinks here, because there is more to test
then stable inode number.
Hardlinks will get a test of their own.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
When enabling btrfs compression, original codes can not fill fs
correctly, here we introduce _fill_fs() in common/rc, which'll keep
creating and writing files until enospc error occurs. Note _fill_fs
is copied from tests/generic/256, but with some minor modifications.
Signed-off-by: Wang Xiaoguang <wangxg.fnst@cn.fujitsu.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Unlike xfs/btrfs which store refcounting information as part of the
space metadata, ocfs2 implements block sharing (reflink) by creating
refcount btrees that are shared between subsets of files. Effectively,
this means that a ocfs2 can have multiple disjoint sets of files that
share blocks, which also means that blocks cannot be reflinked between
two disjoint refcounted-file-sets. generic/119 tests the ability to do
this, so we cannot run it for ocfs2. Create a _require helper to check
for this.
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>
The -x flag is used to exclude tests that belong to
certain groups from the test args list.
When the test args list is expressed as a match pattern,
-x fails to exclude the tests that match the pattern
and belong to excluded groups.
For example:
$ ./check -n xfs/??? | wc -l
341
$ ./check -n -x fuzzers,dangerous_fuzzers xfs/??? | wc -l
341
After the fix:
$ ./check -n -x fuzzers,dangerous_fuzzers xfs/??? | wc -l
315
This bug seems to date back to this git repo epoc.
The fix also sorts out filtering of test that are not found
in group files for the patten match input.
For example:
$ ./check xfs/001*
...
xfs/001 2s
xfs/001.out [failed, exit status 127] - no qualified output
After the fix:
$ ./check -n xfs/001*
xfs/001.out - unknown test, ignored
...
xfs/001 2s
[eguan: use grep -q and fix if-then-fi style]
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This test requires a fix to xfs_io to support
-C one shot commands and -c "open foo" command.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
-c "open $f" is broken in xfs_io <= 4.8. Using it results
in an endless loop and xfs_io exists with error EMFILE.
A fix for that bug makes "open" a 'one shot' command.
Along with this fix, a new -C flag was introduced to explicitly
request to execute a one shot command.
Check for -C flag support as an indication that -c "open $f"
is not broken.
Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Introduce new _require_btrfs_qgroup_report function, which will
check the accessibility to "btrfs check --qgroup-report", then set a
global flag to info _check_scratch_fs() to do extra qgroup check.
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Rename _require_btrfs() to _require_btrfs_command() to avoid
confusion, as all other _require_btrfs_* has a quite clear suffix,
like _require_btrfs_mkfs_feature() or _require_btrfs_fs_feature().
Also enhance _require_btrfs_command() to accept 2nd level commands
or options.
Options will be determined by the first "-" char. This is quite
useful for case like "btrfs inspect-internal dump-tree" and "btrfs
check --qgroup-report".
[eguan: make local vars in _require_btrfs_command "local"]
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
This patch addresses the following build warnings:
fsx.c: In function 'do_punch_hole':
fsx.c:940:3: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
if (!quiet && testcalls > simulatedopcount)
^~
fsx.c:942:4: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if'
log4(OP_PUNCH_HOLE, offset, length, FL_SKIPPED);
^~~~
fsx.c:947:3: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
if (!quiet && testcalls > simulatedopcount)
^~
fsx.c:949:4: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if'
log4(OP_PUNCH_HOLE, offset, length, FL_SKIPPED);
^~~~
fsx.c: In function 'do_zero_range':
fsx.c:995:3: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
if (!quiet && testcalls > simulatedopcount)
^~
fsx.c:997:4: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if'
log4(OP_ZERO_RANGE, offset, length, FL_SKIPPED |
^~~~
[CC] growfiles
growfiles.c: In function 'notify_others':
growfiles.c:1458:6: warning: this 'if' clause does not guard... [-Wmisleading-indentation]
if ( Forker_pids[ind] != Pid )
^~
growfiles.c:1462:10: note: ...this statement, but the latter is misleadingly indented as if it is guarded by the 'if'
kill(Forker_pids[ind], SIGUSR2);
^~~~
The warnings in fsx.c were just spacing issues of the form:
if (length == 0) {
if (!quiet && testcalls > simulatedopcount)
prt("skipping zero length punch hole\n");
log4(OP_PUNCH_HOLE, offset, length, FL_SKIPPED);
return;
}
Where the log4() call just needs to be unindented. log4() calls
elsewhere in that same file are not protected with any sort of
'quiet' check, and commonly follow prt() calls which are. See
doread(), domapread(), etc.
The warning from growfiles.c was actually a bug. notify_others() is
looping through the Forker_pids[] array and sending SIGUSR2 to all
other processes. However, with the current logic it only *logs* the
kill for other processes, and kills all other processes plus the
Forker_pids[] entry that matches 'Pid'.
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Lukas Czerner <lczerner@redhat.com>
Cc: Allison Henderson <achender@vnet.ibm.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Nathan Scott <nathans@sgi.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Btrfs doesn't support swapfiles (yet?), so generic/356 fails
erroneously, and generic/357 only passes by accident. Let's add a
_require_scratch_swapfile helper and add it to these tests.
Signed-off-by: Omar Sandoval <osandov@fb.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
The next version of xfslibs will require that its users enable
transparent largefile support. This broke building xfstests on
32-bit Linux because _FILE_OFFSET_BITS=64 was not getting defined
when testing for xfs headers. Fix this by defining
_FILE_OFFSET_BITS=64 when doing configure checks for the xfs
headers.
It was not necessary to define _FILE_OFFSET_BITS=64 for the actual
build because it's already done, in builddefs.in.
The problem could also be solved by adding AC_SYS_LARGEFILE to
configure.ac. It's debatable, but I chose not to do that because it
might give the impression that it affects the actual compilation of
the test programs and not just the configure checks. (Since not all
.c files include config.h first, a _FILE_OFFSET_BITS definition in
config.h wouldn't always take effect.)
Signed-off-by: Eric Biggers <ebiggers@google.com>
Reviewed-by: Eryu Guan <eguan@redhat.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
common/rc has become a dumping ground for common functions that
don't have a specific topic file. It's getting huge and difficiult
to manage, and people are duplicating functionality because they
can't easily find existing functions in the mess.
Let's start to make it a little easier to manage by splitting out
the XFS specific functions into common/xfs and source that from
common/rc automatically. Other filesytems can follow suit in
future, leaving us with only generic functionality in common/rc.
Signed-Off-By: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Eryu Guan <eguan@redhat.com>
Oops, we did it again - we moved the XFS dio code warning to a new
function with the iomap direct IO rework. Update the filter to pick
up the new warning location.
Signed-Off-By: Dave Chinner <dchinner@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Eryu Guan <eguan@redhat.com>