Here are the know kselftest issues on Linux 5.4 with
top commit commit 619e17cf75dd58905aa67ccd494a6ba5f19d6cc6
on x86_64:
The goal is to get these addressed before 5.4 comes out.
3 build failures and status:
pidfd - undefined reference to `pthread_create' collect2: error: ld
returned 1 exit status
Fixed: https://patchwork.kernel.org/patch/11159517/
bfp (two issues)
1. "make TARGETS=bpf kselftest" build fails
Makefile:127: tools/build/Makefile.include: No such file or directory
This is due to recent kbuild changes and I have a patch ready to send.
2. Related to llvm latest version dependency. This is a hard dependency.
Unless users upgrade to latest llvvm, bpf test won't run. The new llvm
might not be supported on all distros yet, in which case bpf will not
get tested in some rings and on some architectures.
gpio
"make TARGETS=gpio kselftest" build fails
Makefile:23: tools/build/Makefile.include: No such file or directory
This is due to recent kbuild changes and I have a patch ready to send.
kvm
"make TARGETS=kvm kselftest" build fails due --no-pie flags.
I am working on a fix for this. no-pie-option defines aren't working
correctly and I suspect try-run miht not be defined in this kselftest
build case.
thanks,
-- Shuah
From: Colin Ian King <colin.king(a)canonical.com>
There is a spelling mistake in in an error message, fix it.
Signed-off-by: Colin Ian King <colin.king(a)canonical.com>
---
tools/testing/selftests/kvm/lib/sparsebit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/kvm/lib/sparsebit.c b/tools/testing/selftests/kvm/lib/sparsebit.c
index 031ba3c932ed..59ffba902e61 100644
--- a/tools/testing/selftests/kvm/lib/sparsebit.c
+++ b/tools/testing/selftests/kvm/lib/sparsebit.c
@@ -1866,7 +1866,7 @@ void sparsebit_validate_internal(struct sparsebit *s)
* of total bits set.
*/
if (s->num_set != total_bits_set) {
- fprintf(stderr, "Number of bits set missmatch,\n"
+ fprintf(stderr, "Number of bits set mismatch,\n"
" s->num_set: 0x%lx total_bits_set: 0x%lx",
s->num_set, total_bits_set);
--
2.20.1
This micro series fixes annoying warn described in patches
while samples/bpf build. Second patch fixes new warn that
comes after fixing warn of first patch, that was masked.
Ivan Khoronzhuk (2):
selftests/bpf: add static to enable_all_controllers()
selftests/bpf: correct path to include msg + path
tools/testing/selftests/bpf/cgroup_helpers.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--
2.17.1
Fix the following build error from "make TARGETS=kvm kselftest":
libkvm.a(assert.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
This error is seen when build is done from the main Makefile using
kselftest target. In this case KBUILD_CPPFLAGS and CC_OPTION_CFLAGS
are defined.
When build is invoked using:
"make -C tools/testing/selftests/kvm" KBUILD_CPPFLAGS and CC_OPTION_CFLAGS
aren't defined.
There is no need to pass in KBUILD_CPPFLAGS and CC_OPTION_CFLAGS for the
check to determine if --no-pie is necessary, which is the case when these
two aren't defined when "make -C tools/testing/selftests/kvm" runs.
Fix it by simplifying the no-pie-option logic. With this change, both
build variations work.
"make TARGETS=kvm kselftest"
"make -C tools/testing/selftests/kvm"
Signed-off-by: Shuah Khan <skhan(a)linuxfoundation.org>
---
Changes since v2:
-- Removed extra blank line added by accident.
-- Fixed commit log.
tools/testing/selftests/kvm/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile
index 62c591f87dab..7ee097658ef0 100644
--- a/tools/testing/selftests/kvm/Makefile
+++ b/tools/testing/selftests/kvm/Makefile
@@ -48,7 +48,7 @@ CFLAGS += -Wall -Wstrict-prototypes -Wuninitialized -O2 -g -std=gnu99 \
-I$(LINUX_HDR_PATH) -Iinclude -I$(<D) -Iinclude/$(UNAME_M) -I..
no-pie-option := $(call try-run, echo 'int main() { return 0; }' | \
- $(CC) -Werror $(KBUILD_CPPFLAGS) $(CC_OPTION_CFLAGS) -no-pie -x c - -o "$$TMP", -no-pie)
+ $(CC) -Werror -no-pie -x c - -o "$$TMP", -no-pie)
# On s390, build the testcases KVM-enabled
pgste-option = $(call try-run, echo 'int main() { return 0; }' | \
--
2.20.1
On Fri, Sep 20, 2019 at 9:27 AM Shuah Khan <skhan(a)linuxfoundation.org> wrote:
>
> Hi Linus,
>
> On Fri, Sep 20, 2019, 10:18 AM Linus Torvalds <torvalds(a)linux-foundation.org> wrote:
>>
>> On Tue, Sep 17, 2019 at 12:26 PM Shuah Khan <skhan(a)linuxfoundation.org> wrote:
>> >
>> > This Kselftest update for Linux 5.4-rc1 consists of several fixes to
>> > existing tests and adds KUnit, a lightweight unit testing and mocking
>> > framework for the Linux kernel from Brendan Higgins.
>>
>> So I pulled this, but then I almost immediately unpulled it.
>>
>> My reason for doing that may be odd, but it's because of the top-level
>> 'kunit' directory. This shouldn't be on the top level.
>>
>> The reason I react so strongly is that it actually breaks my finger
>> memory. I don't type out filenames - I auto-compete them. So "kernel/"
>> is "k<tab>", "drivers/" is "d<tab>" etc.
>>
>> It already doesn't work for everything ("mm/" is actually "mm<tab>"
>> not because we have files in the git tree, but because the build
>> creates various "module" files), but this breaks a common pattern for
>> me.
Sorry about that. I am surprised that none of the other reviewers
brought this up.
> On hindsight, I probably should have run this by you to get your feedback.
>
>> > In the future KUnit will be linked to Kselftest framework to provide
>> > a way to trigger KUnit tests from user-space.
>>
>> Can the kernel parts please move to lib/kunit/ or something like that.
I'm fine with lib/kunit/.
> I will work with Brendan and come up with a plan and send another request early next week.
Cheers
make TARGETS=gpio kselftest fails with:
Makefile:23: tools/build/Makefile.include: No such file or directory
When the gpio tool make is invoked from tools Makefile, srctree is
cleared and the current logic check for srctree equals to empty
string to determine srctree location from CURDIR.
When the build in invoked from selftests/gpio Makefile, the srctree
is set to "." and the same logic used for srctree equals to empty is
needed to determine srctree.
Check building_out_of_srctree undefined as the condition for both
cases to fix "make TARGETS=gpio kselftest" build failure.
Signed-off-by: Shuah Khan <skhan(a)linuxfoundation.org>
---
Rsending with corrected address for linux-kselftest(a)vger.kernel.org
tools/gpio/Makefile | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/tools/gpio/Makefile b/tools/gpio/Makefile
index 6ecdd1067826..1178d302757e 100644
--- a/tools/gpio/Makefile
+++ b/tools/gpio/Makefile
@@ -3,7 +3,11 @@ include ../scripts/Makefile.include
bindir ?= /usr/bin
-ifeq ($(srctree),)
+# This will work when gpio is built in tools env. where srctree
+# isn't set and when invoked from selftests build, where srctree
+# is set to ".". building_out_of_srctree is undefined for in srctree
+# builds
+ifndef building_out_of_srctree
srctree := $(patsubst %/,%,$(dir $(CURDIR)))
srctree := $(patsubst %/,%,$(dir $(srctree)))
endif
--
2.20.1
When handling page faults for many vCPUs during demand paging, KVM's MMU
lock becomes highly contended. This series creates a test with a naive
userfaultfd based demand paging implementation to demonstrate that
contention. This test serves both as a functional test of userfaultfd
and a microbenchmark of demand paging performance with a variable number
of vCPUs and memory per vCPU.
The test creates N userfaultfd threads, N vCPUs, and a region of memory
with M pages per vCPU. The N userfaultfd polling threads are each set up
to serve faults on a region of memory corresponding to one of the vCPUs.
Each of the vCPUs is then started, and touches each page of its disjoint
memory region, sequentially. In response to faults, the userfaultfd
threads copy a static buffer into the guest's memory. This creates a
worst case for MMU lock contention as we have removed most of the
contention between the userfaultfd threads and there is no time required
to fetch the contents of guest memory.
This test was run successfully on Intel Haswell, Broadwell, and
Cascadelake hosts with a variety of vCPU counts and memory sizes.
This test was adapted from the dirty_log_test.
The series can also be viewed in Gerrit here:
https://linux-review.googlesource.com/c/virt/kvm/kvm/+/1464
(Thanks to Dmitry Vyukov <dvyukov(a)google.com> for setting up the Gerrit
instance)
Ben Gardon (9):
KVM: selftests: Create a demand paging test
KVM: selftests: Add demand paging content to the demand paging test
KVM: selftests: Add memory size parameter to the demand paging test
KVM: selftests: Pass args to vCPU instead of using globals
KVM: selftests: Support multiple vCPUs in demand paging test
KVM: selftests: Time guest demand paging
KVM: selftests: Add parameter to _vm_create for memslot 0 base paddr
KVM: selftests: Support large VMs in demand paging test
Add static flag
tools/testing/selftests/kvm/.gitignore | 1 +
tools/testing/selftests/kvm/Makefile | 4 +-
.../selftests/kvm/demand_paging_test.c | 610 ++++++++++++++++++
tools/testing/selftests/kvm/dirty_log_test.c | 2 +-
.../testing/selftests/kvm/include/kvm_util.h | 3 +-
tools/testing/selftests/kvm/lib/kvm_util.c | 7 +-
6 files changed, 621 insertions(+), 6 deletions(-)
create mode 100644 tools/testing/selftests/kvm/demand_paging_test.c
--
2.23.0.444.g18eeb5a265-goog
Fix the following build error from "make TARGETS=kvm kselftest":
libkvm.a(assert.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIC
This error is seen when build is done from the main Makefile using
kselftest target. In this case KBUILD_CPPFLAGS and CC_OPTION_CFLAGS
are defined. When build is invoked using:
"make -C tools/testing/selftests/kvm" KBUILD_CPPFLAGS and CC_OPTION_CFLAGS
aren't defined.
There is no need to pass in KBUILD_CPPFLAGS and CC_OPTION_CFLAGS for the
check to determine if --no-pie is necessary1s, which is the when these
two aren't defined when "make -C tools/testing/selftests/kvm" runs.
Fix it by simplifying the no-pie-option logic. With this change, bith
build variations work.
"make TARGETS=kvm kselftest"
"make -C tools/testing/selftests/kvm"
Signed-off-by: Shuah Khan <skhan(a)linuxfoundation.org>
---
tools/testing/selftests/kvm/Makefile | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/kvm/Makefile b/tools/testing/selftests/kvm/Makefile
index 62c591f87dab..02d20aab9440 100644
--- a/tools/testing/selftests/kvm/Makefile
+++ b/tools/testing/selftests/kvm/Makefile
@@ -48,8 +48,9 @@ CFLAGS += -Wall -Wstrict-prototypes -Wuninitialized -O2 -g -std=gnu99 \
-I$(LINUX_HDR_PATH) -Iinclude -I$(<D) -Iinclude/$(UNAME_M) -I..
no-pie-option := $(call try-run, echo 'int main() { return 0; }' | \
- $(CC) -Werror $(KBUILD_CPPFLAGS) $(CC_OPTION_CFLAGS) -no-pie -x c - -o "$$TMP", -no-pie)
+ $(CC) -Werror -no-pie -x c - -o "$$TMP", -no-pie)
+#
# On s390, build the testcases KVM-enabled
pgste-option = $(call try-run, echo 'int main() { return 0; }' | \
$(CC) -Werror -Wl$(comma)--s390-pgste -x c - -o "$$TMP",-Wl$(comma)--s390-pgste)
--
2.20.1
Hi Shuah,
On Tue, Oct 01, 2019 at 08:41:43PM +0000, patchwork-bot+linux-kselftest(a)kernel.org wrote:
> Hello:
>
> This series was applied to shuah/linux-kselftest.git (refs/heads/fixes).
>
> On Tue, 17 Sep 2019 20:40:22 +0200 you wrote:
> > From: "George G. Davis" <george_davis(a)mentor.com>
> >
> > The newly added optional file argument does not validate if the
> > file is indeed a watchdog, e.g.:
> >
> > ./watchdog-test -f /dev/zero
> > Watchdog Ticking Away!
> >
> > [...]
>
> Here is a summary with links:
> - [v3,1/2] selftests: watchdog: Validate optional file argument
> https://git.kernel.org/shuah/linux-kselftest/c/93c384f5d553bc4fdfb252b89ff3…
Could you please update the 'Fixes:' tag in the above commit to:
Fixes: a4864a33f56caa ("selftests: watchdog: Add optional file argument")
The warning in https://patchwork.kernel.org/patch/11149287/ clearly says
that the fixed commit is from linux-next and it seems to have been
updated before landing in mainline. TIA.
--
Best Regards,
Eugeniu
From: Andrii Nakryiko <andriin(a)fb.com>
[ Upstream commit 4670d68b9254710fdeaf794cad54d8b2c9929e0a ]
Some recent changes in latest Clang started causing the following
warning when unrolling strobemeta test case main loop:
progs/strobemeta.h:416:2: warning: loop not unrolled: the optimizer was
unable to perform the requested transformation; the transformation might
be disabled or specified as part of an unsupported transformation
ordering [-Wpass-failed=transform-warning]
This patch simplifies loop's exit condition to depend only on constant
max iteration number (STROBE_MAX_MAP_ENTRIES), while moving early
termination logic inside the loop body. The changes are equivalent from
program logic standpoint, but fixes the warning. It also appears to
improve generated BPF code, as it fixes previously failing non-unrolled
strobemeta test cases.
Cc: Alexei Starovoitov <ast(a)fb.com>
Signed-off-by: Andrii Nakryiko <andriin(a)fb.com>
Signed-off-by: Daniel Borkmann <daniel(a)iogearbox.net>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
tools/testing/selftests/bpf/progs/strobemeta.h | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/tools/testing/selftests/bpf/progs/strobemeta.h b/tools/testing/selftests/bpf/progs/strobemeta.h
index 8a399bdfd9203..067eb625d01c5 100644
--- a/tools/testing/selftests/bpf/progs/strobemeta.h
+++ b/tools/testing/selftests/bpf/progs/strobemeta.h
@@ -413,7 +413,10 @@ static __always_inline void *read_map_var(struct strobemeta_cfg *cfg,
#else
#pragma unroll
#endif
- for (int i = 0; i < STROBE_MAX_MAP_ENTRIES && i < map.cnt; ++i) {
+ for (int i = 0; i < STROBE_MAX_MAP_ENTRIES; ++i) {
+ if (i >= map.cnt)
+ break;
+
descr->key_lens[i] = 0;
len = bpf_probe_read_str(payload, STROBE_MAX_STR_LEN,
map.entries[i].key);
--
2.20.1
From: Tycho Andersen <tycho(a)tycho.ws>
[ Upstream commit 88282297fff00796e81f5e67734a6afdfb31fbc4 ]
The seccomp selftest goes to some length to build against older kernel
headers, viz. all the #ifdefs at the beginning of the file.
Commit 201766a20e30 ("ptrace: add PTRACE_GET_SYSCALL_INFO request")
introduces some additional macros, but doesn't do the #ifdef dance.
Let's add that dance here to avoid:
gcc -Wl,-no-as-needed -Wall seccomp_bpf.c -lpthread -o seccomp_bpf
In file included from seccomp_bpf.c:51:
seccomp_bpf.c: In function ‘tracer_ptrace’:
seccomp_bpf.c:1787:20: error: ‘PTRACE_EVENTMSG_SYSCALL_ENTRY’ undeclared (first use in this function); did you mean ‘PTRACE_EVENT_CLONE’?
EXPECT_EQ(entry ? PTRACE_EVENTMSG_SYSCALL_ENTRY
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../kselftest_harness.h:608:13: note: in definition of macro ‘__EXPECT’
__typeof__(_expected) __exp = (_expected); \
^~~~~~~~~
seccomp_bpf.c:1787:2: note: in expansion of macro ‘EXPECT_EQ’
EXPECT_EQ(entry ? PTRACE_EVENTMSG_SYSCALL_ENTRY
^~~~~~~~~
seccomp_bpf.c:1787:20: note: each undeclared identifier is reported only once for each function it appears in
EXPECT_EQ(entry ? PTRACE_EVENTMSG_SYSCALL_ENTRY
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../kselftest_harness.h:608:13: note: in definition of macro ‘__EXPECT’
__typeof__(_expected) __exp = (_expected); \
^~~~~~~~~
seccomp_bpf.c:1787:2: note: in expansion of macro ‘EXPECT_EQ’
EXPECT_EQ(entry ? PTRACE_EVENTMSG_SYSCALL_ENTRY
^~~~~~~~~
seccomp_bpf.c:1788:6: error: ‘PTRACE_EVENTMSG_SYSCALL_EXIT’ undeclared (first use in this function); did you mean ‘PTRACE_EVENT_EXIT’?
: PTRACE_EVENTMSG_SYSCALL_EXIT, msg);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
../kselftest_harness.h:608:13: note: in definition of macro ‘__EXPECT’
__typeof__(_expected) __exp = (_expected); \
^~~~~~~~~
seccomp_bpf.c:1787:2: note: in expansion of macro ‘EXPECT_EQ’
EXPECT_EQ(entry ? PTRACE_EVENTMSG_SYSCALL_ENTRY
^~~~~~~~~
make: *** [Makefile:12: seccomp_bpf] Error 1
[skhan(a)linuxfoundation.org: Fix checkpatch error in commit log]
Signed-off-by: Tycho Andersen <tycho(a)tycho.ws>
Fixes: 201766a20e30 ("ptrace: add PTRACE_GET_SYSCALL_INFO request")
Acked-by: Kees Cook <keescook(a)chromium.org>
Signed-off-by: Shuah Khan <skhan(a)linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal(a)kernel.org>
---
tools/testing/selftests/seccomp/seccomp_bpf.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/tools/testing/selftests/seccomp/seccomp_bpf.c b/tools/testing/selftests/seccomp/seccomp_bpf.c
index 6ef7f16c4cf52..7f8b5c8982e3b 100644
--- a/tools/testing/selftests/seccomp/seccomp_bpf.c
+++ b/tools/testing/selftests/seccomp/seccomp_bpf.c
@@ -199,6 +199,11 @@ struct seccomp_notif_sizes {
};
#endif
+#ifndef PTRACE_EVENTMSG_SYSCALL_ENTRY
+#define PTRACE_EVENTMSG_SYSCALL_ENTRY 1
+#define PTRACE_EVENTMSG_SYSCALL_EXIT 2
+#endif
+
#ifndef seccomp
int seccomp(unsigned int op, unsigned int flags, void *args)
{
--
2.20.1
This patchset is being developed here:
<https://github.com/cyphar/linux/tree/resolveat/master>
It depends on the copy_struct_from_user() helpers being developed here:
<https://github.com/cyphar/linux/tree/copy_struct_from_user/master>
and posted here:
<https://lore.kernel.org/lkml/20190930182810.6090-1-cyphar@cyphar.com/>
Patch changelog:
v13:
* Fix race with the magic-link mode semantics by recomputing the mode during
->get_link() and storing it with nd_jump_link(). A selftest was added for
this attack scenario as well. [Jann Horn]
* Fix gap in RESOLVE_NO_XDEV with magic-links -- now magic-link resolution is
only permitted if the link doesn't jump vfsmounts.
* Remove path_is_under() checks for ".." resolution (due to the possibility
of O(m*n) lookup behaviour). Instead, return -EAGAIN if a racing rename or
mount occurs. Userspace is then encouraged to retry or have another
fallback (if after several tries, it still fails it's likely that there is
an attack going on -- though failures will occur spuriously because
&{rename,mount}_lock are both global). [Linus Torvalds]
* Move copy_struct_from_user() to a separate series so it can be merged
separately. [Christian Brauner]
* Small test improvements (mainly making the TAP output more readable and
adding a few new minor test cases). Now the openat2(2) self-tests have ~271
overall test cases.
* Expand on changes to path-lookup in the kernel docs.
* Kernel-doc fixes. [Randy Dunlap]
v12: <https://lore.kernel.org/lkml/20190904201933.10736-1-cyphar@cyphar.com/>
v11: <https://lore.kernel.org/lkml/20190820033406.29796-1-cyphar@cyphar.com/>
<https://lore.kernel.org/lkml/20190728010207.9781-1-cyphar@cyphar.com/>
v10: <https://lore.kernel.org/lkml/20190719164225.27083-1-cyphar@cyphar.com/>
v09: <https://lore.kernel.org/lkml/20190706145737.5299-1-cyphar@cyphar.com/>
v08: <https://lore.kernel.org/lkml/20190520133305.11925-1-cyphar@cyphar.com/>
v07: <https://lore.kernel.org/lkml/20190507164317.13562-1-cyphar@cyphar.com/>
v06: <https://lore.kernel.org/lkml/20190506165439.9155-1-cyphar@cyphar.com/>
v05: <https://lore.kernel.org/lkml/20190320143717.2523-1-cyphar@cyphar.com/>
v04: <https://lore.kernel.org/lkml/20181112142654.341-1-cyphar@cyphar.com/>
v03: <https://lore.kernel.org/lkml/20181009070230.12884-1-cyphar@cyphar.com/>
v02: <https://lore.kernel.org/lkml/20181009065300.11053-1-cyphar@cyphar.com/>
v01: <https://lore.kernel.org/lkml/20180929103453.12025-1-cyphar@cyphar.com/>
The need for some sort of control over VFS's path resolution (to avoid
malicious paths resulting in inadvertent breakouts) has been a very
long-standing desire of many userspace applications. This patchset is a
revival of Al Viro's old AT_NO_JUMPS[1,2] patchset (which was a variant
of David Drysdale's O_BENEATH patchset[3] which was a spin-off of the
Capsicum project[4]) with a few additions and changes made based on the
previous discussion within [5] as well as others I felt were useful.
In line with the conclusions of the original discussion of AT_NO_JUMPS,
the flag has been split up into separate flags. However, instead of
being an openat(2) flag it is provided through a new syscall openat2(2)
which provides several other improvements to the openat(2) interface (see the
patch description for more details). The following new LOOKUP_* flags are
added:
* LOOKUP_NO_XDEV blocks all mountpoint crossings (upwards, downwards,
or through absolute links). Absolute pathnames alone in openat(2) do not
trigger this. Magic-link traversal which implies a vfsmount jump is also
blocked (though magic-link jumps on the same vfsmount are permitted).
* LOOKUP_NO_MAGICLINKS blocks resolution through /proc/$pid/fd-style
links. This is done by blocking the usage of nd_jump_link() during
resolution in a filesystem. The term "magic-links" is used to match
with the only reference to these links in Documentation/, but I'm
happy to change the name.
It should be noted that this is different to the scope of
~LOOKUP_FOLLOW in that it applies to all path components. However,
you can do openat2(NO_FOLLOW|NO_MAGICLINKS) on a magic-link and it
will *not* fail (assuming that no parent component was a
magic-link), and you will have an fd for the magic-link.
* LOOKUP_BENEATH disallows escapes to outside the starting dirfd's
tree, using techniques such as ".." or absolute links. Absolute
paths in openat(2) are also disallowed. Conceptually this flag is to
ensure you "stay below" a certain point in the filesystem tree --
but this requires some additional to protect against various races
that would allow escape using "..".
Currently LOOKUP_BENEATH implies LOOKUP_NO_MAGICLINKS, because it
can trivially beam you around the filesystem (breaking the
protection). In future, there might be similar safety checks done as
in LOOKUP_IN_ROOT, but that requires more discussion.
In addition, two new flags are added that expand on the above ideas:
* LOOKUP_NO_SYMLINKS does what it says on the tin. No symlink
resolution is allowed at all, including magic-links. Just as with
LOOKUP_NO_MAGICLINKS this can still be used with NOFOLLOW to open an
fd for the symlink as long as no parent path had a symlink
component.
* LOOKUP_IN_ROOT is an extension of LOOKUP_BENEATH that, rather than
blocking attempts to move past the root, forces all such movements
to be scoped to the starting point. This provides chroot(2)-like
protection but without the cost of a chroot(2) for each filesystem
operation, as well as being safe against race attacks that chroot(2)
is not.
If a race is detected (as with LOOKUP_BENEATH) then an error is
generated, and similar to LOOKUP_BENEATH it is not permitted to cross
magic-links with LOOKUP_IN_ROOT.
The primary need for this is from container runtimes, which
currently need to do symlink scoping in userspace[6] when opening
paths in a potentially malicious container. There is a long list of
CVEs that could have bene mitigated by having RESOLVE_THIS_ROOT
(such as CVE-2017-1002101, CVE-2017-1002102, CVE-2018-15664, and
CVE-2019-5736, just to name a few).
And further, several semantics of file descriptor "re-opening" are now
changed to prevent attacks like CVE-2019-5736 by restricting how
magic-links can be resolved (based on their mode). This required some
other changes to the semantics of the modes of O_PATH file descriptor's
associated /proc/self/fd magic-links. openat2(2) has the ability to
further restrict re-opening of its own O_PATH fds, so that users can
make even better use of this feature.
Finally, O_EMPTYPATH was added so that users can do /proc/self/fd-style
re-opening without depending on procfs. The new restricted semantics for
magic-links are applied here too.
In order to make all of the above more usable, I'm working on
libpathrs[7] which is a C-friendly library for safe path resolution. It
features a userspace-emulated backend if the kernel doesn't support
openat2(2). Hopefully we can get userspace to switch to using it, and
thus get openat2(2) support for free once it's ready.
[1]: https://lwn.net/Articles/721443/
[2]: https://lore.kernel.org/patchwork/patch/784221/
[3]: https://lwn.net/Articles/619151/
[4]: https://lwn.net/Articles/603929/
[5]: https://lwn.net/Articles/723057/
[6]: https://github.com/cyphar/filepath-securejoin
[7]: https://github.com/openSUSE/libpathrs
Aleksa Sarai (9):
namei: obey trailing magic-link DAC permissions
procfs: switch magic-link modes to be more sane
open: O_EMPTYPATH: procfs-less file descriptor re-opening
namei: O_BENEATH-style path resolution flags
namei: LOOKUP_IN_ROOT: chroot-like path resolution
namei: permit ".." resolution with LOOKUP_{IN_ROOT,BENEATH}
open: openat2(2) syscall
selftests: add openat2(2) selftests
Documentation: update path-lookup to mention trailing magic-links
Documentation/filesystems/path-lookup.rst | 80 ++-
arch/alpha/include/uapi/asm/fcntl.h | 1 +
arch/alpha/kernel/syscalls/syscall.tbl | 1 +
arch/arm/tools/syscall.tbl | 1 +
arch/arm64/include/asm/unistd.h | 2 +-
arch/arm64/include/asm/unistd32.h | 2 +
arch/ia64/kernel/syscalls/syscall.tbl | 1 +
arch/m68k/kernel/syscalls/syscall.tbl | 1 +
arch/microblaze/kernel/syscalls/syscall.tbl | 1 +
arch/mips/kernel/syscalls/syscall_n32.tbl | 1 +
arch/mips/kernel/syscalls/syscall_n64.tbl | 1 +
arch/mips/kernel/syscalls/syscall_o32.tbl | 1 +
arch/parisc/include/uapi/asm/fcntl.h | 39 +-
arch/parisc/kernel/syscalls/syscall.tbl | 1 +
arch/powerpc/kernel/syscalls/syscall.tbl | 1 +
arch/s390/kernel/syscalls/syscall.tbl | 1 +
arch/sh/kernel/syscalls/syscall.tbl | 1 +
arch/sparc/include/uapi/asm/fcntl.h | 1 +
arch/sparc/kernel/syscalls/syscall.tbl | 1 +
arch/x86/entry/syscalls/syscall_32.tbl | 1 +
arch/x86/entry/syscalls/syscall_64.tbl | 1 +
arch/xtensa/kernel/syscalls/syscall.tbl | 1 +
fs/fcntl.c | 2 +-
fs/internal.h | 1 +
fs/namei.c | 286 +++++++--
fs/open.c | 100 ++-
fs/proc/base.c | 69 +-
fs/proc/fd.c | 45 +-
fs/proc/internal.h | 2 +-
fs/proc/namespaces.c | 4 +-
include/linux/fcntl.h | 21 +-
include/linux/fs.h | 8 +-
include/linux/namei.h | 15 +-
include/linux/syscalls.h | 14 +-
include/uapi/asm-generic/fcntl.h | 4 +
include/uapi/asm-generic/unistd.h | 5 +-
include/uapi/linux/fcntl.h | 42 ++
security/apparmor/apparmorfs.c | 2 +-
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/memfd/memfd_test.c | 7 +-
tools/testing/selftests/openat2/.gitignore | 1 +
tools/testing/selftests/openat2/Makefile | 8 +
tools/testing/selftests/openat2/helpers.c | 98 +++
tools/testing/selftests/openat2/helpers.h | 114 ++++
.../testing/selftests/openat2/linkmode_test.c | 590 ++++++++++++++++++
.../testing/selftests/openat2/openat2_test.c | 152 +++++
.../selftests/openat2/rename_attack_test.c | 149 +++++
.../testing/selftests/openat2/resolve_test.c | 522 ++++++++++++++++
48 files changed, 2258 insertions(+), 145 deletions(-)
create mode 100644 tools/testing/selftests/openat2/.gitignore
create mode 100644 tools/testing/selftests/openat2/Makefile
create mode 100644 tools/testing/selftests/openat2/helpers.c
create mode 100644 tools/testing/selftests/openat2/helpers.h
create mode 100644 tools/testing/selftests/openat2/linkmode_test.c
create mode 100644 tools/testing/selftests/openat2/openat2_test.c
create mode 100644 tools/testing/selftests/openat2/rename_attack_test.c
create mode 100644 tools/testing/selftests/openat2/resolve_test.c
--
2.23.0
make TARGETS=bpf kselftest fails with:
Makefile:127: tools/build/Makefile.include: No such file or directory
When the bpf tool make is invoked from tools Makefile, srctree is
cleared and the current logic check for srctree equals to empty
string to determine srctree location from CURDIR.
When the build in invoked from selftests/bpf Makefile, the srctree
is set to "." and the same logic used for srctree equals to empty is
needed to determine srctree.
Check building_out_of_srctree undefined as the condition for both
cases to fix "make TARGETS=bpf kselftest" build failure.
Signed-off-by: Shuah Khan <skhan(a)linuxfoundation.org>
---
tools/bpf/Makefile | 6 +++++-
tools/lib/bpf/Makefile | 6 +++++-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/tools/bpf/Makefile b/tools/bpf/Makefile
index fbf5e4a0cb9c..5d1995fd369c 100644
--- a/tools/bpf/Makefile
+++ b/tools/bpf/Makefile
@@ -12,7 +12,11 @@ INSTALL ?= install
CFLAGS += -Wall -O2
CFLAGS += -D__EXPORTED_HEADERS__ -I$(srctree)/include/uapi -I$(srctree)/include
-ifeq ($(srctree),)
+# This will work when bpf is built in tools env. where srctree
+# isn't set and when invoked from selftests build, where srctree
+# is set to ".". building_out_of_srctree is undefined for in srctree
+# builds
+ifndef building_out_of_srctree
srctree := $(patsubst %/,%,$(dir $(CURDIR)))
srctree := $(patsubst %/,%,$(dir $(srctree)))
endif
diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
index c6f94cffe06e..20772663d3e1 100644
--- a/tools/lib/bpf/Makefile
+++ b/tools/lib/bpf/Makefile
@@ -8,7 +8,11 @@ LIBBPF_MAJOR_VERSION := $(firstword $(subst ., ,$(LIBBPF_VERSION)))
MAKEFLAGS += --no-print-directory
-ifeq ($(srctree),)
+# This will work when bpf is built in tools env. where srctree
+# isn't set and when invoked from selftests build, where srctree
+# is a ".". building_out_of_srctree is undefined for in srctree
+# builds
+ifndef building_out_of_srctree
srctree := $(patsubst %/,%,$(dir $(CURDIR)))
srctree := $(patsubst %/,%,$(dir $(srctree)))
srctree := $(patsubst %/,%,$(dir $(srctree)))
--
2.20.1
This patch series fixes the following problem:
linux# make kselftest TARGETS=bpf O=/mnt/linux-build
# selftests: bpf: test_libbpf.sh
# ./test_libbpf.sh: line 23: ./test_libbpf_open: No such file or directory
# test_libbpf: failed at file test_l4lb.o
# selftests: test_libbpf [FAILED]
Patch 1 appends / to $(OUTPUT) in order to make it more uniform with the
rest of the tree.
Patch 2 fixes the problem by prepending $(OUTPUT) to all members of
$(TEST_PROGS).
v1->v2:
- Append / to $(OUTPUT).
- Use $(addprefix) instead of $(foreach).
v2->v3:
- Split the patch in two.
- Improve the commit message.
Ilya Leoshkevich (2):
selftests: append / to $(OUTPUT)
selftests: fix prepending $(OUTPUT) to $(TEST_PROGS)
tools/testing/selftests/Makefile | 16 ++++++++--------
tools/testing/selftests/lib.mk | 3 ++-
2 files changed, 10 insertions(+), 9 deletions(-)
--
2.23.0
This patch series simplifies kselftest use-cases and addresses requests
from developers and testers to add support for building and installing
from the main Makefile.
Shuah Khan (2):
Makefile: Add kselftest_build target to build tests
selftests: Add kselftest_install target to main Makefile
Makefile | 8 ++++++++
tools/testing/selftests/Makefile | 8 ++++++--
tools/testing/selftests/kselftest_install.sh | 4 ++--
3 files changed, 16 insertions(+), 4 deletions(-)
--
2.20.1
Hi Linus,
Please pull the following Kselftest update for Linux 5.4-rc1.
This Kselftest update for Linux 5.4-rc1 consists of several fixes to
existing tests.
diff is attached.
This pull has just the ksleftest patches I sent in my previous pull
request. I dropped the KUnit patches and rebased.
I will send another pull request for the KUnit work later on this
week.
Please note that there is conflict between
tools/testing/selftests/tpm2/Makefile
between commit:
3fb2179b0f3553a ("selftests/tpm2: Add the missing TEST_FILES assignment")
from the tpmdd tree and commit:
d04e26067d13f01 ("selftests: tpm2: install python files")
Please take the fix from kselftest tree which is the correct
version for this change.
d04e26067d13f01 ("selftests: tpm2: install python files")
Please let me know if you have any questions and/or concerns.
thanks,
-- Shuah
----------------------------------------------------------------
The following changes since commit d1abaeb3be7b5fa6d7a1fbbd2e14e3310005c4c1:
Linux 5.3-rc5 (2019-08-18 14:31:08 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
tags/linux-kselftest-5.4-rc1.1
for you to fetch changes up to 721cb3c8bc8890e824b7be53bf951960ff7811f9:
selftests: tpm2: install python files (2019-09-23 08:33:16 -0600)
----------------------------------------------------------------
linux-kselftest-5.4-rc1.1
This Kselftest update for Linux 5.4-rc1 consists of fixes to existing
tests.
----------------------------------------------------------------
Anders Roxell (2):
selftests: livepatch: add missing fragments to config
selftests: tpm2: install python files
George G. Davis (2):
selftests: watchdog: Add optional file argument
selftests: watchdog: cleanup whitespace in usage options
Ilya Leoshkevich (1):
selftests: use "$(MAKE)" instead of "make"
Masanari Iida (1):
selftest/ftrace: Fix typo in trigger-snapshot.tc
Tycho Andersen (1):
selftests/seccomp: fix build on older kernels
tools/testing/selftests/Makefile | 22 ++++++------
.../ftrace/test.d/trigger/trigger-snapshot.tc | 2 +-
tools/testing/selftests/livepatch/config | 2 ++
tools/testing/selftests/seccomp/seccomp_bpf.c | 5 +++
tools/testing/selftests/tpm2/Makefile | 1 +
tools/testing/selftests/watchdog/watchdog-test.c | 41
+++++++++++++++-------
6 files changed, 48 insertions(+), 25 deletions(-)
----------------------------------------------------------------
Hi
so this series carries two small fixes to the toplevel KSelfTest makefile
which I found useful especially while attempting to run the suite in
automation.
[1/2]
While it is already possible to specify a limited list of TARGETS to run,
it is not instead easily possible to state a list of targets NOT to run
(say due to specific instability issues).
Moreover providing such a skip list through a stripped down list of TARGETS
it is cumbersome and fragile since this poses the risk to stick to an old
stale stripped TARGETS list once upstream decides to add more default
targets.
A new SKIP_TARGETS Makefile variable is provided by this patch to easily
specify a skiplist for target subsystems.
[2/2]
Currently when some target fails to build, KSFT Makefile just carries on
building as much subsystems as it can: unfortunately this is not properly
reflected also in the generation of the runlist inside run_kselftest.sh.
This patch rectifies this behaviour checking for the existence of a target
directory in the INSTALL_PATH before adding the related snippet to the
run_kselftest.sh script.
Thanks
Cristian
Changelog
v1 --> v2
- added Documentation
- various typos fixed
- added a proper override when filtering-out SKIP_TARGETS from TARGETS
to make it work also when TARGETS is provided too from the cmdline
Cristian Marussi (2):
kselftest: add capability to skip chosen TARGETS
kselftest: exclude failed TARGETS from runlist
Documentation/dev-tools/kselftest.rst | 11 +++++++++++
tools/testing/selftests/Makefile | 11 +++++++++++
2 files changed, 22 insertions(+)
--
2.17.1
I found a bug in kselftest KBUILD_OUTPUT handling.
The following works:
$ cd /home/tbird/work/linux
$ export KBUILD_OUTPUT=/home/tbird/work/kbuild
$ yes '' | make localmodconfig
$ make TARGETS=size kselftest
But this doesn't work:
$ cd /home/tbird/work/linux
$ export KBUILD_OUTPUT=../kbuild
$ yes '' | make localmodconfig
$ make TARGETS=size kselftest
I see the following:
make[1]: Entering directory '/home/tbird/work/kbuild'
make --no-builtin-rules INSTALL_HDR_PATH=$BUILD/usr \
ARCH=x86 -C ../../.. headers_install
INSTALL ../kbuild/kselftest/usr/include
gcc -static -ffreestanding -nostartfiles -s get_size.c -o ../kbuild/kselftest/size/get_size
/usr/bin/ld: cannot open output file ../kbuild/kselftest/size/get_size: No such file or directory
collect2: error: ld returned 1 exit status
../lib.mk:138: recipe for target '../kbuild/kselftest/size/get_size' failed
make[3]: *** [../kbuild/kselftest/size/get_size] Error 1
Makefile:136: recipe for target 'all' failed
make[2]: *** [all] Error 2
/home/tbird/work/linux/Makefile:1240: recipe for target 'kselftest' failed
make[1]: *** [kselftest] Error 2
make[1]: Leaving directory '/home/tbird/work/kbuild'
Makefile:179: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2
This is due to the relative path for KBUILD_OUTPUT being handled incorrectly (I believe)
in tools/testing/selftests/Makefile.
There are these lines in the Makefile, which are responsible for creating the output
directory:
BUILD_TARGET=$$BUILD/$$TARGET
mkdir $$BUILD_TARGET -p
But these are executed from working directory tools/testing/selftests,
so the 'size' directory gets created at tools/testing/kbuild/kselftest/size,
instead of /home/tbird/work/kbuild/kselftest/size.
I can add some code to the Makefile to change the assignment of the
variable BUILD, so that if it is a relative path it is relative to $(top_srcdir)
instead of the current directory. But I wanted to check and make sure that
I'm not breaking anyone else's workflow.
I'm not sure what the expectation would be for someone who did this:
$ export KBUILD_OUTPUT=../kbuild ; make -C tools/testing/selftests run_tests
But I assume if someone is running the kernel's 'make' from the top-level
kernel source directory, and they have a relative KBUILD_OUTPUT directory,
then they want that output directory to be relative to the top-level directory
and not somewhere else.
Should I just code up something for review?
I use relative KBUILD_OUTPUT paths for a number of my kernel build scripts,
and right now these are incompatible with kselftests.
Thanks,
-- Tim
Let the user specify an optional TARGETS skiplist through the new optional
SKIP_TARGETS Makefile variable.
It is easier to skip at will a reduced and well defined list of possibly
problematic targets with SKIP_TARGETS then to provide a partially stripped
down list of good targets using the usual TARGETS variable.
Signed-off-by: Cristian Marussi <cristian.marussi(a)arm.com>
---
tools/testing/selftests/Makefile | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/tools/testing/selftests/Makefile b/tools/testing/selftests/Makefile
index 25b43a8c2b15..103936faa46d 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -132,6 +132,10 @@ else
ARCH=$(ARCH) -C $(top_srcdir) headers_install
endif
+# User can optionally provide a TARGETS skiplist.
+SKIP_TARGETS ?=
+TARGETS := $(filter-out $(SKIP_TARGETS), $(TARGETS))
+
all: khdr
@for TARGET in $(TARGETS); do \
BUILD_TARGET=$$BUILD/$$TARGET; \
--
2.17.1
Hi Linus,
Please pull the following Kselftest update for Linux 5.4-rc1 (minus kunit).
This Kselftest update for Linux 5.4-rc1 consists of several fixes to
existing tests.
diff is attached.
This pull has just the ksleftest patches I sent in my previous pull
request. I dropped the KUnit patches and rebased.
I will send another pull request for the KUnit work later on this
week.
Please note that there is conflict between
tools/testing/selftests/tpm2/Makefile
between commit:
3fb2179b0f3553a ("selftests/tpm2: Add the missing TEST_FILES assignment")
from the tpmdd tree and commit:
d04e26067d13f01 ("selftests: tpm2: install python files")
Please take the fix from kselftest tree which is the correct
version for this change.
d04e26067d13f01 ("selftests: tpm2: install python files")
Please let me know if you have any questions and/or concerns.
thanks,
-- Shuah
----------------------------------------------------------------
The following changes since commit d1abaeb3be7b5fa6d7a1fbbd2e14e3310005c4c1:
Linux 5.3-rc5 (2019-08-18 14:31:08 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
tags/linux-kselftest-5.4-rc1.1
for you to fetch changes up to 721cb3c8bc8890e824b7be53bf951960ff7811f9:
selftests: tpm2: install python files (2019-09-23 08:33:16 -0600)
----------------------------------------------------------------
linux-kselftest-5.4-rc1.1
This Kselftest update for Linux 5.4-rc1 consists of fixes to existing
tests.
----------------------------------------------------------------
Anders Roxell (2):
selftests: livepatch: add missing fragments to config
selftests: tpm2: install python files
George G. Davis (2):
selftests: watchdog: Add optional file argument
selftests: watchdog: cleanup whitespace in usage options
Ilya Leoshkevich (1):
selftests: use "$(MAKE)" instead of "make"
Masanari Iida (1):
selftest/ftrace: Fix typo in trigger-snapshot.tc
Tycho Andersen (1):
selftests/seccomp: fix build on older kernels
tools/testing/selftests/Makefile | 22 ++++++------
.../ftrace/test.d/trigger/trigger-snapshot.tc | 2 +-
tools/testing/selftests/livepatch/config | 2 ++
tools/testing/selftests/seccomp/seccomp_bpf.c | 5 +++
tools/testing/selftests/tpm2/Makefile | 1 +
tools/testing/selftests/watchdog/watchdog-test.c | 41
+++++++++++++++-------
6 files changed, 48 insertions(+), 25 deletions(-)
----------------------------------------------------------------
Hi Alexei and Daniel,
bpf test doesn't build on Linux 5.4 mainline. Do you know what's
happening here.
make -C tools/testing/selftests/bpf/
-c progs/test_core_reloc_ptr_as_arr.c -o - || echo "clang failed") | \
llc -march=bpf -mcpu=generic -filetype=obj -o
/mnt/data/lkml/linux_5.4/tools/testing/selftests/bpf/test_core_reloc_ptr_as_arr.o
progs/test_core_reloc_ptr_as_arr.c:25:6: error: use of unknown builtin
'__builtin_preserve_access_index' [-Wimplicit-function-declaration]
if (BPF_CORE_READ(&out->a, &in[2].a))
^
./bpf_helpers.h:533:10: note: expanded from macro 'BPF_CORE_READ'
__builtin_preserve_access_index(src))
^
progs/test_core_reloc_ptr_as_arr.c:25:6: warning: incompatible integer to
pointer conversion passing 'int' to parameter of type 'const void *'
[-Wint-conversion]
if (BPF_CORE_READ(&out->a, &in[2].a))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./bpf_helpers.h:533:10: note: expanded from macro 'BPF_CORE_READ'
__builtin_preserve_access_index(src))
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning and 1 error generated.
llc: error: llc: <stdin>:1:1: error: expected top-level entity
clang failed
Also
make TARGETS=bpf kselftest fails as well. Dependency between
tools/lib/bpf and the test. How can we avoid this type of
dependency or resolve it in a way it doesn't result in build
failures?
thanks,
-- Shuah
Ohayou Gozaimasu.
My name is Yuval Rose. I have an urgent lucrative business
opportunity for you worth over 15 Milli0n US D0llars. This is by
virtue of the signficance of your nationality (Japanese).
Waiting for your speedy reply for further and complete details.
Doumo Arigatou.
Yuval
Toronto-Canada
TL;DR: We expect KUnit to be accepted upstream into Linus' branch in
the next week or two, and we now need to figure out what we are going
to do with our non-upstream 'kunit/alpha/master' branch.
Hello everyone,
We've put together a rough proposal of what we should do with our
not-upstream branch, known to most people using it as
'kunit/alpha/master'[1], now that KUnit's acceptance into mainline
appears to be imminent (the KUnit MVP patchset is now in linux-next,
and the merge window just opened).
==========
Background
==========
KUnit development is currently split between two versions: the
'kunit/alpha/master'[1] git branch, and the version being submitted to
the upstream Linux kernel. While there are some good reasons to
continue to have two separate versions of KUnit, at present there is
some uncertainty around the difference between these versions, and in
which circumstances each version is useful.
At present, the 'kunit/alpha/master' branch serves a few different
purposes. It is a place for code not-yet-ready for upstream -- such as
the mocking framework -- while being developed, while also acting as a
stable version for customers who do not wish to follow along with the
changes made during the upstreaming process. Adding to the confusion,
the name 'kunit/alpha/master' refers to an early (alpha) version of
KUnit, and the version of KUnit being upstreamed has now diverged
significantly from this version, requiring significant differences in
documentation, and requiring a number of changes to tests when porting
from one version to the other. Finally, it is not clear how the
'kunit/alpha/master' version should evolve as features it contains are
upstreamed.
On the other hand, the version being upstreamed has its own
complications. It contains significantly fewer features (as features
such as the mocking frameworks will be upstreamed individually), and
so is less useful for the average customer. Until each feature is
upstreamed, it is iterated on rapidly to address comments from the
kernel community, so in-progress features are not stable enough to
reasonably build on. Finally, it exists only as a set of patches on
mailing lists, rather than as a maintained git repository (due to the
fact that the patches themselves are changing rapidly), making it
difficult for early adopters to incorporate into their own trees.
Whilst we believe there to be enough (at times conflicting) goals
above to justify having multiple versions of KUnit, we want to ensure
that they are meeting their goals, and that we have a process to
ensure that code finds its way into the correct version, that we can
deprecate and remove failed experiments or superseded versions, and
that we can keep pace with upstream kernel releases.
============
The Proposal
============
We propose having two tracks of development: the upstream kernel
(comprising both code that has been upstreamed, and code which is in
the process of being upstreamed -- i.e. is being reviewed on the
mailing lists), and an 'experimental' branch, which contains features
which are yet to be submitted upstream.
Periodically, the 'experimental' branch will be replaced with a new
'experimental' branch based on the latest upstream version. This will
allow us to focus on code based on upstream versions by deprecating
earlier, experimental versions of features. The older experimental
branch will stay around, but receive no new features or support:
customers will need to eventually migrate to either the upstream
kernel (if all of the features they require have been upstreamed), or
to the latest 'experimental' branch (if they still require
non-upstreamed features).
Where practical, 'experimental' branches will try to provide a stable
interface (and/or compatibility layers/shims) such that users can
write tests against an experimental version and expect our changes to
break them infrequently. We don't intend to make any solid guarantee,
however: so users will need to be able to deal with some breakage.
We expect most changes to KUnit to be submitted directly upstream, and
reserve the 'experimental' branch for features where:
a) the design is yet to be proven by early adopters, and is likely to change;
b) the feature is large enough that having a solid staging environment
in which several developers can work is necessary; and/or
c) it depends on existing features only available in the 'experimental' branch.
An example of features suited to the 'experimental' branch are the
mocking systems[2].
=====================
Lifetime of a feature
=====================
A new feature (that for one of the above reasons may require some
experimentation before being sent upstream) would typically be
developed as follows:
1. An initial version of the feature is developed against the latest
'experimental' branch.
2. The feature is tested by users of the 'experimental' branch.
3. It is revised as needed within the 'experimental' branch. If
breaking changes are required, and supporting some form of
compatibility layer is practical, such a layer is implemented to avoid
breaking existing 'experimental' customers.
4. Once the feature is deemed ready, it is submitted to the mailing
lists for the upstream kernel. Any compatibility layers for earlier
experimental version are removed -- this is a 'clean' version of the
change.
5. Development of the change continues on the kernel mailing lists:
any particularly important changes or bugfixes are ported to the
'experimental' branch if feasible, but complete convergence is not
expected at this stage.
6. When the feature is accepted upstream, a new 'experimental' branch
is created based on the new upstream kernel. Development on the old
'experimental' branch ceases.
7. The upstream version of the feature has now superseded the
experimental version. All future development is done based on the
upstream version, either in the new 'experimental' branch, or directly
against the upstream kernel.
8. Any customers still using the experimental version of the feature
will need to update their code to work with the upstream version in
order to update to the new (supported) 'experimental' branch, or to
the upstream kernel.
===========================
What does this mean for me?
===========================
...as a user?
-------------
If you're using the upstream version of KUnit, nothing! Features will
continue to be pushed upstream when they're ready.
If you're using the 'kunit/alpha/master' branch, then you'll need to
switch to the new 'experimental-<version>' branches. Every so often,
we'll create a new 'experimental-<version>' branch, and you'll need to
rebase your code on top of that to keep receiving updated features and
bugfixes. While we intend to make this as painless as possible, there
may be breaking changes which require you to rework some of your
tests.
Once a feature exists in the upstream kernel, the version of that
feature in the 'experimental' branches should stabilise somewhat.
...as a KUnit developer?
------------------------
For most changes/bugfixes which apply cleanly to the upstream version,
you should directly submit these upstream as before. If it is feasible
and useful to backport them to the latest 'experimental' branch (e.g.,
they are bugfixes to code that the experimental branch already has),
please do so.
For more major features (or anything which depends on
yet-to-be-upstreamed code), you should develop them in the latest
'experimental' branch. For the most part, you can treat this the same
way as the old 'kunit/alpha/master' branch, but note that changes will
need to be rebased on top of a newer experimental branch periodically.
It may make sense to use this as an opportunity to tidy the code up
somewhat: by removing compatibility code for deprecated features, or
to merge 'fixup' commits. Once the code has been upstreamed, the next
rebase of the 'experimental' branch should only use the upstream
version: there should not be a separate 'experimental' version of
upstream code save for the development of a new 'experimental' feature
or bugfix.
For more details, see the 'Lifetime of a feature' section above.
=============
In Conclusion
=============
We'll continue to be working with upstream as before, but we intend to
rename and more explicitly specify the purpose of the
'kunit/alpha/master' branch as above. This will require a bit more
work from people using and developing against this 'experimental'
branch, but allows us to continue to use it for features such as the
mocking framework while limiting its divergence from upstream.
Do let us know if this sounds reasonable to you, if it will affect
your use case, or if you have any questions.
Cheers,
-- David & Brendan
[1] https://kunit.googlesource.com/linux/+/refs/heads/kunit/alpha/master
[2] https://kunit.googlesource.com/linux/+/kunit/alpha/master/Documentation/tes…
## TL;DR
This revision addresses comments from Linus[1] and Randy[2], by moving
top level `kunit/` directory to `lib/kunit/` and likewise moves top
level Kconfig entry under lib/Kconfig.debug, so the KUnit submenu now
shows up under the "Kernel Hacking" menu.
As a consequence of this, I rewrote patch 06/18 (kbuild: enable building
KUnit), and now needs to be re-acked/reviewed.
## Background
This patch set proposes KUnit, a lightweight unit testing and mocking
framework for the Linux kernel.
Unlike Autotest and kselftest, KUnit is a true unit testing framework;
it does not require installing the kernel on a test machine or in a VM
(however, KUnit still allows you to run tests on test machines or in VMs
if you want[3]) and does not require tests to be written in userspace
running on a host kernel. Additionally, KUnit is fast: From invocation
to completion KUnit can run several dozen tests in about a second.
Currently, the entire KUnit test suite for KUnit runs in under a second
from the initial invocation (build time excluded).
KUnit is heavily inspired by JUnit, Python's unittest.mock, and
Googletest/Googlemock for C++. KUnit provides facilities for defining
unit test cases, grouping related test cases into test suites, providing
common infrastructure for running tests, mocking, spying, and much more.
### What's so special about unit testing?
A unit test is supposed to test a single unit of code in isolation,
hence the name. There should be no dependencies outside the control of
the test; this means no external dependencies, which makes tests orders
of magnitudes faster. Likewise, since there are no external dependencies,
there are no hoops to jump through to run the tests. Additionally, this
makes unit tests deterministic: a failing unit test always indicates a
problem. Finally, because unit tests necessarily have finer granularity,
they are able to test all code paths easily solving the classic problem
of difficulty in exercising error handling code.
### Is KUnit trying to replace other testing frameworks for the kernel?
No. Most existing tests for the Linux kernel are end-to-end tests, which
have their place. A well tested system has lots of unit tests, a
reasonable number of integration tests, and some end-to-end tests. KUnit
is just trying to address the unit test space which is currently not
being addressed.
### More information on KUnit
There is a bunch of documentation near the end of this patch set that
describes how to use KUnit and best practices for writing unit tests.
For convenience I am hosting the compiled docs here[4].
Additionally for convenience, I have applied these patches to a
branch[5]. The repo may be cloned with:
git clone https://kunit.googlesource.com/linux
This patchset is on the kunit/initial/v5.3/v17 branch.
## History since v15
### v17
- Addressed comments on 06/19 (lib: enable building KUnit in lib/) from
Stephen Boyd by moving KUnit submenu ahead of Runtime Testing
submenu.
### v16
- Addressed comments from Linus Torvalds by moving all kunit/ paths to
lib/kunit/.
- Addressed comments by Randy Dunlap by moving KUnit Kconfig under
lib/Kconfig.debug so the KUnit submenu shows up under the "Kernel
Hacking" menu.
[1] https://www.lkml.org/lkml/2019/9/20/696
[2] https://www.lkml.org/lkml/2019/9/20/738
[3] https://google.github.io/kunit-docs/third_party/kernel/docs/usage.html#kuni…
[4] https://google.github.io/kunit-docs/third_party/kernel/docs/
[5] https://kunit.googlesource.com/linux/+/kunit/initial/v5.3/v17
---
Avinash Kondareddy (1):
kunit: test: add tests for KUnit managed resources
Brendan Higgins (16):
kunit: test: add KUnit test runner core
kunit: test: add test resource management API
kunit: test: add string_stream a std::stream like string builder
kunit: test: add assertion printing library
kunit: test: add the concept of expectations
lib: enable building KUnit in lib/
kunit: test: add initial tests
objtool: add kunit_try_catch_throw to the noreturn list
kunit: test: add support for test abort
kunit: test: add tests for kunit test abort
kunit: test: add the concept of assertions
kunit: defconfig: add defconfigs for building KUnit tests
Documentation: kunit: add documentation for KUnit
MAINTAINERS: add entry for KUnit the unit testing framework
MAINTAINERS: add proc sysctl KUnit test to PROC SYSCTL section
kunit: fix failure to build without printk
Felix Guo (1):
kunit: tool: add Python wrappers for running KUnit tests
Iurii Zaikin (1):
kernel/sysctl-test: Add null pointer test for sysctl.c:proc_dointvec()
Documentation/dev-tools/index.rst | 1 +
Documentation/dev-tools/kunit/api/index.rst | 16 +
Documentation/dev-tools/kunit/api/test.rst | 11 +
Documentation/dev-tools/kunit/faq.rst | 62 +
Documentation/dev-tools/kunit/index.rst | 79 +
Documentation/dev-tools/kunit/start.rst | 180 ++
Documentation/dev-tools/kunit/usage.rst | 576 +++++++
MAINTAINERS | 13 +
arch/um/configs/kunit_defconfig | 3 +
include/kunit/assert.h | 356 ++++
include/kunit/string-stream.h | 51 +
include/kunit/test.h | 1490 +++++++++++++++++
include/kunit/try-catch.h | 75 +
kernel/Makefile | 2 +
kernel/sysctl-test.c | 392 +++++
lib/Kconfig.debug | 13 +
lib/Makefile | 2 +
lib/kunit/Kconfig | 38 +
lib/kunit/Makefile | 9 +
lib/kunit/assert.c | 141 ++
lib/kunit/example-test.c | 88 +
lib/kunit/string-stream-test.c | 52 +
lib/kunit/string-stream.c | 217 +++
lib/kunit/test-test.c | 331 ++++
lib/kunit/test.c | 478 ++++++
lib/kunit/try-catch.c | 118 ++
tools/objtool/check.c | 1 +
tools/testing/kunit/.gitignore | 3 +
tools/testing/kunit/configs/all_tests.config | 3 +
tools/testing/kunit/kunit.py | 136 ++
tools/testing/kunit/kunit_config.py | 66 +
tools/testing/kunit/kunit_kernel.py | 149 ++
tools/testing/kunit/kunit_parser.py | 310 ++++
tools/testing/kunit/kunit_tool_test.py | 206 +++
.../test_is_test_passed-all_passed.log | 32 +
.../test_data/test_is_test_passed-crash.log | 69 +
.../test_data/test_is_test_passed-failure.log | 36 +
.../test_is_test_passed-no_tests_run.log | 75 +
.../test_output_isolated_correctly.log | 106 ++
.../test_data/test_read_from_file.kconfig | 17 +
40 files changed, 6003 insertions(+)
create mode 100644 Documentation/dev-tools/kunit/api/index.rst
create mode 100644 Documentation/dev-tools/kunit/api/test.rst
create mode 100644 Documentation/dev-tools/kunit/faq.rst
create mode 100644 Documentation/dev-tools/kunit/index.rst
create mode 100644 Documentation/dev-tools/kunit/start.rst
create mode 100644 Documentation/dev-tools/kunit/usage.rst
create mode 100644 arch/um/configs/kunit_defconfig
create mode 100644 include/kunit/assert.h
create mode 100644 include/kunit/string-stream.h
create mode 100644 include/kunit/test.h
create mode 100644 include/kunit/try-catch.h
create mode 100644 kernel/sysctl-test.c
create mode 100644 lib/kunit/Kconfig
create mode 100644 lib/kunit/Makefile
create mode 100644 lib/kunit/assert.c
create mode 100644 lib/kunit/example-test.c
create mode 100644 lib/kunit/string-stream-test.c
create mode 100644 lib/kunit/string-stream.c
create mode 100644 lib/kunit/test-test.c
create mode 100644 lib/kunit/test.c
create mode 100644 lib/kunit/try-catch.c
create mode 100644 tools/testing/kunit/.gitignore
create mode 100644 tools/testing/kunit/configs/all_tests.config
create mode 100755 tools/testing/kunit/kunit.py
create mode 100644 tools/testing/kunit/kunit_config.py
create mode 100644 tools/testing/kunit/kunit_kernel.py
create mode 100644 tools/testing/kunit/kunit_parser.py
create mode 100755 tools/testing/kunit/kunit_tool_test.py
create mode 100644 tools/testing/kunit/test_data/test_is_test_passed-all_passed.log
create mode 100644 tools/testing/kunit/test_data/test_is_test_passed-crash.log
create mode 100644 tools/testing/kunit/test_data/test_is_test_passed-failure.log
create mode 100644 tools/testing/kunit/test_data/test_is_test_passed-no_tests_run.log
create mode 100644 tools/testing/kunit/test_data/test_output_isolated_correctly.log
create mode 100644 tools/testing/kunit/test_data/test_read_from_file.kconfig
--
2.23.0.351.gc4317032e6-goog
This patch set proposes KUnit, a lightweight unit testing and mocking
framework for the Linux kernel.
Unlike Autotest and kselftest, KUnit is a true unit testing framework;
it does not require installing the kernel on a test machine or in a VM
and does not require tests to be written in userspace running on a host
kernel. Additionally, KUnit is fast: From invocation to completion KUnit
can run several dozen tests in under a second. Currently, the entire
KUnit test suite for KUnit runs in under a second from the initial
invocation (build time excluded).
KUnit is heavily inspired by JUnit, Python's unittest.mock, and
Googletest/Googlemock for C++. KUnit provides facilities for defining
unit test cases, grouping related test cases into test suites, providing
common infrastructure for running tests, mocking, spying, and much more.
## What's so special about unit testing?
A unit test is supposed to test a single unit of code in isolation,
hence the name. There should be no dependencies outside the control of
the test; this means no external dependencies, which makes tests orders
of magnitudes faster. Likewise, since there are no external dependencies,
there are no hoops to jump through to run the tests. Additionally, this
makes unit tests deterministic: a failing unit test always indicates a
problem. Finally, because unit tests necessarily have finer granularity,
they are able to test all code paths easily solving the classic problem
of difficulty in exercising error handling code.
## Is KUnit trying to replace other testing frameworks for the kernel?
No. Most existing tests for the Linux kernel are end-to-end tests, which
have their place. A well tested system has lots of unit tests, a
reasonable number of integration tests, and some end-to-end tests. KUnit
is just trying to address the unit test space which is currently not
being addressed.
## More information on KUnit
There is a bunch of documentation near the end of this patch set that
describes how to use KUnit and best practices for writing unit tests.
For convenience I am hosting the compiled docs here:
https://google.github.io/kunit-docs/third_party/kernel/docs/
Additionally for convenience, I have applied these patches to a branch:
https://kunit.googlesource.com/linux/+/kunit/rfc/4.19/v3
The repo may be cloned with:
git clone https://kunit.googlesource.com/linux
This patchset is on the kunit/rfc/4.19/v3 branch.
## Changes Since Last Version
- Changed namespace prefix from `test_*` to `kunit_*` as requested by
Shuah.
- Started converting/cleaning up the device tree unittest to use KUnit.
- Started adding KUnit expectations with custom messages.
--
2.20.0.rc0.387.gc7a69e6b6c-goog
## TL;DR
This revision addresses comments from Linus[1] and Randy[2], by moving
top level `kunit/` directory to `lib/kunit/` and likewise moves top
level Kconfig entry under lib/Kconfig.debug, so the KUnit submenu now
shows up under the "Kernel Hacking" menu.
As a consequence of this, I rewrote patch 06/18 (kbuild: enable building
KUnit), and now needs to be re-acked/reviewed.
## Background
This patch set proposes KUnit, a lightweight unit testing and mocking
framework for the Linux kernel.
Unlike Autotest and kselftest, KUnit is a true unit testing framework;
it does not require installing the kernel on a test machine or in a VM
(however, KUnit still allows you to run tests on test machines or in VMs
if you want[3]) and does not require tests to be written in userspace
running on a host kernel. Additionally, KUnit is fast: From invocation
to completion KUnit can run several dozen tests in about a second.
Currently, the entire KUnit test suite for KUnit runs in under a second
from the initial invocation (build time excluded).
KUnit is heavily inspired by JUnit, Python's unittest.mock, and
Googletest/Googlemock for C++. KUnit provides facilities for defining
unit test cases, grouping related test cases into test suites, providing
common infrastructure for running tests, mocking, spying, and much more.
### What's so special about unit testing?
A unit test is supposed to test a single unit of code in isolation,
hence the name. There should be no dependencies outside the control of
the test; this means no external dependencies, which makes tests orders
of magnitudes faster. Likewise, since there are no external dependencies,
there are no hoops to jump through to run the tests. Additionally, this
makes unit tests deterministic: a failing unit test always indicates a
problem. Finally, because unit tests necessarily have finer granularity,
they are able to test all code paths easily solving the classic problem
of difficulty in exercising error handling code.
### Is KUnit trying to replace other testing frameworks for the kernel?
No. Most existing tests for the Linux kernel are end-to-end tests, which
have their place. A well tested system has lots of unit tests, a
reasonable number of integration tests, and some end-to-end tests. KUnit
is just trying to address the unit test space which is currently not
being addressed.
### More information on KUnit
There is a bunch of documentation near the end of this patch set that
describes how to use KUnit and best practices for writing unit tests.
For convenience I am hosting the compiled docs here[4].
Additionally for convenience, I have applied these patches to a
branch[5]. The repo may be cloned with:
git clone https://kunit.googlesource.com/linux
This patchset is on the kunit/initial/v5.3/v16 branch.
[1] https://www.lkml.org/lkml/2019/9/20/696
[2] https://www.lkml.org/lkml/2019/9/20/738
[3] https://google.github.io/kunit-docs/third_party/kernel/docs/usage.html#kuni…
[4] https://google.github.io/kunit-docs/third_party/kernel/docs/
[5] https://kunit.googlesource.com/linux/+/kunit/initial/v5.3/v16
---
Avinash Kondareddy (1):
kunit: test: add tests for KUnit managed resources
Brendan Higgins (16):
kunit: test: add KUnit test runner core
kunit: test: add test resource management API
kunit: test: add string_stream a std::stream like string builder
kunit: test: add assertion printing library
kunit: test: add the concept of expectations
lib: enable building KUnit in lib/
kunit: test: add initial tests
objtool: add kunit_try_catch_throw to the noreturn list
kunit: test: add support for test abort
kunit: test: add tests for kunit test abort
kunit: test: add the concept of assertions
kunit: defconfig: add defconfigs for building KUnit tests
Documentation: kunit: add documentation for KUnit
MAINTAINERS: add entry for KUnit the unit testing framework
MAINTAINERS: add proc sysctl KUnit test to PROC SYSCTL section
kunit: fix failure to build without printk
Felix Guo (1):
kunit: tool: add Python wrappers for running KUnit tests
Iurii Zaikin (1):
kernel/sysctl-test: Add null pointer test for sysctl.c:proc_dointvec()
Documentation/dev-tools/index.rst | 1 +
Documentation/dev-tools/kunit/api/index.rst | 16 +
Documentation/dev-tools/kunit/api/test.rst | 11 +
Documentation/dev-tools/kunit/faq.rst | 62 +
Documentation/dev-tools/kunit/index.rst | 79 +
Documentation/dev-tools/kunit/start.rst | 180 ++
Documentation/dev-tools/kunit/usage.rst | 576 +++++++
MAINTAINERS | 13 +
arch/um/configs/kunit_defconfig | 3 +
include/kunit/assert.h | 356 ++++
include/kunit/string-stream.h | 51 +
include/kunit/test.h | 1490 +++++++++++++++++
include/kunit/try-catch.h | 75 +
kernel/Makefile | 2 +
kernel/sysctl-test.c | 392 +++++
lib/Kconfig.debug | 13 +
lib/Makefile | 2 +
lib/kunit/Kconfig | 38 +
lib/kunit/Makefile | 9 +
lib/kunit/assert.c | 141 ++
lib/kunit/example-test.c | 88 +
lib/kunit/string-stream-test.c | 52 +
lib/kunit/string-stream.c | 217 +++
lib/kunit/test-test.c | 331 ++++
lib/kunit/test.c | 478 ++++++
lib/kunit/try-catch.c | 118 ++
tools/objtool/check.c | 1 +
tools/testing/kunit/.gitignore | 3 +
tools/testing/kunit/configs/all_tests.config | 3 +
tools/testing/kunit/kunit.py | 136 ++
tools/testing/kunit/kunit_config.py | 66 +
tools/testing/kunit/kunit_kernel.py | 149 ++
tools/testing/kunit/kunit_parser.py | 310 ++++
tools/testing/kunit/kunit_tool_test.py | 206 +++
.../test_is_test_passed-all_passed.log | 32 +
.../test_data/test_is_test_passed-crash.log | 69 +
.../test_data/test_is_test_passed-failure.log | 36 +
.../test_is_test_passed-no_tests_run.log | 75 +
.../test_output_isolated_correctly.log | 106 ++
.../test_data/test_read_from_file.kconfig | 17 +
40 files changed, 6003 insertions(+)
create mode 100644 Documentation/dev-tools/kunit/api/index.rst
create mode 100644 Documentation/dev-tools/kunit/api/test.rst
create mode 100644 Documentation/dev-tools/kunit/faq.rst
create mode 100644 Documentation/dev-tools/kunit/index.rst
create mode 100644 Documentation/dev-tools/kunit/start.rst
create mode 100644 Documentation/dev-tools/kunit/usage.rst
create mode 100644 arch/um/configs/kunit_defconfig
create mode 100644 include/kunit/assert.h
create mode 100644 include/kunit/string-stream.h
create mode 100644 include/kunit/test.h
create mode 100644 include/kunit/try-catch.h
create mode 100644 kernel/sysctl-test.c
create mode 100644 lib/kunit/Kconfig
create mode 100644 lib/kunit/Makefile
create mode 100644 lib/kunit/assert.c
create mode 100644 lib/kunit/example-test.c
create mode 100644 lib/kunit/string-stream-test.c
create mode 100644 lib/kunit/string-stream.c
create mode 100644 lib/kunit/test-test.c
create mode 100644 lib/kunit/test.c
create mode 100644 lib/kunit/try-catch.c
create mode 100644 tools/testing/kunit/.gitignore
create mode 100644 tools/testing/kunit/configs/all_tests.config
create mode 100755 tools/testing/kunit/kunit.py
create mode 100644 tools/testing/kunit/kunit_config.py
create mode 100644 tools/testing/kunit/kunit_kernel.py
create mode 100644 tools/testing/kunit/kunit_parser.py
create mode 100755 tools/testing/kunit/kunit_tool_test.py
create mode 100644 tools/testing/kunit/test_data/test_is_test_passed-all_passed.log
create mode 100644 tools/testing/kunit/test_data/test_is_test_passed-crash.log
create mode 100644 tools/testing/kunit/test_data/test_is_test_passed-failure.log
create mode 100644 tools/testing/kunit/test_data/test_is_test_passed-no_tests_run.log
create mode 100644 tools/testing/kunit/test_data/test_output_isolated_correctly.log
create mode 100644 tools/testing/kunit/test_data/test_read_from_file.kconfig
--
2.23.0.351.gc4317032e6-goog
Commit a745f7af3cbd ("selftests/harness: Add 30 second timeout per
test") solves the problem of kselftest_harness.h-using binary tests
possibly hanging forever. However, scripts and other binaries can still
hang forever. This adds a global timeout to each test script run.
To make this configurable (e.g. as needed in the "rtc" test case),
include a new per-test-directory "settings" file (similar to "config")
that can contain kselftest-specific settings. The first recognized field
is "timeout".
Additionally, this splits the reporting for timeouts into a specific
"TIMEOUT" not-ok (and adds exit code reporting in the remaining case).
Signed-off-by: Kees Cook <keescook(a)chromium.org>
---
tools/testing/selftests/kselftest/runner.sh | 36 +++++++++++++++++++--
tools/testing/selftests/rtc/settings | 1 +
2 files changed, 34 insertions(+), 3 deletions(-)
create mode 100644 tools/testing/selftests/rtc/settings
diff --git a/tools/testing/selftests/kselftest/runner.sh b/tools/testing/selftests/kselftest/runner.sh
index 00c9020bdda8..84de7bc74f2c 100644
--- a/tools/testing/selftests/kselftest/runner.sh
+++ b/tools/testing/selftests/kselftest/runner.sh
@@ -3,9 +3,14 @@
#
# Runs a set of tests in a given subdirectory.
export skip_rc=4
+export timeout_rc=124
export logfile=/dev/stdout
export per_test_logging=
+# Defaults for "settings" file fields:
+# "timeout" how many seconds to let each test run before failing.
+export kselftest_default_timeout=45
+
# There isn't a shell-agnostic way to find the path of a sourced file,
# so we must rely on BASE_DIR being set to find other tools.
if [ -z "$BASE_DIR" ]; then
@@ -24,6 +29,16 @@ tap_prefix()
fi
}
+tap_timeout()
+{
+ # Make sure tests will time out if utility is available.
+ if [ -x /usr/bin/timeout ] ; then
+ /usr/bin/timeout "$kselftest_timeout" "$1"
+ else
+ "$1"
+ fi
+}
+
run_one()
{
DIR="$1"
@@ -32,6 +47,18 @@ run_one()
BASENAME_TEST=$(basename $TEST)
+ # Reset any "settings"-file variables.
+ export kselftest_timeout="$kselftest_default_timeout"
+ # Load per-test-directory kselftest "settings" file.
+ settings="$BASE_DIR/$DIR/settings"
+ if [ -r "$settings" ] ; then
+ while read line ; do
+ field=$(echo "$line" | cut -d= -f1)
+ value=$(echo "$line" | cut -d= -f2-)
+ eval "kselftest_$field"="$value"
+ done < "$settings"
+ fi
+
TEST_HDR_MSG="selftests: $DIR: $BASENAME_TEST"
echo "# $TEST_HDR_MSG"
if [ ! -x "$TEST" ]; then
@@ -44,14 +71,17 @@ run_one()
echo "not ok $test_num $TEST_HDR_MSG"
else
cd `dirname $TEST` > /dev/null
- (((((./$BASENAME_TEST 2>&1; echo $? >&3) |
+ ((((( tap_timeout ./$BASENAME_TEST 2>&1; echo $? >&3) |
tap_prefix >&4) 3>&1) |
(read xs; exit $xs)) 4>>"$logfile" &&
echo "ok $test_num $TEST_HDR_MSG") ||
- (if [ $? -eq $skip_rc ]; then \
+ (rc=$?; \
+ if [ $rc -eq $skip_rc ]; then \
echo "not ok $test_num $TEST_HDR_MSG # SKIP"
+ elif [ $rc -eq $timeout_rc ]; then \
+ echo "not ok $test_num $TEST_HDR_MSG # TIMEOUT"
else
- echo "not ok $test_num $TEST_HDR_MSG"
+ echo "not ok $test_num $TEST_HDR_MSG # exit=$rc"
fi)
cd - >/dev/null
fi
diff --git a/tools/testing/selftests/rtc/settings b/tools/testing/selftests/rtc/settings
new file mode 100644
index 000000000000..ba4d85f74cd6
--- /dev/null
+++ b/tools/testing/selftests/rtc/settings
@@ -0,0 +1 @@
+timeout=90
--
2.17.1
--
Kees Cook
On Tue, Sep 17, 2019 at 12:26 PM Shuah Khan <skhan(a)linuxfoundation.org> wrote:
>
> This Kselftest update for Linux 5.4-rc1 consists of several fixes to
> existing tests and adds KUnit, a lightweight unit testing and mocking
> framework for the Linux kernel from Brendan Higgins.
So I pulled this, but then I almost immediately unpulled it.
My reason for doing that may be odd, but it's because of the top-level
'kunit' directory. This shouldn't be on the top level.
The reason I react so strongly is that it actually breaks my finger
memory. I don't type out filenames - I auto-compete them. So "kernel/"
is "k<tab>", "drivers/" is "d<tab>" etc.
It already doesn't work for everything ("mm/" is actually "mm<tab>"
not because we have files in the git tree, but because the build
creates various "module" files), but this breaks a common pattern for
me.
> In the future KUnit will be linked to Kselftest framework to provide
> a way to trigger KUnit tests from user-space.
Can the kernel parts please move to lib/kunit/ or something like that?
Linus
Hey everyone,
This is the patchset coming out of the KSummit session Kees and I gave
in Lisbon last week (cf. [3] which also contains slides with more
details on related things such as deep argument inspection).
The simple idea is to extend the seccomp notifier to allow for the
continuation of a syscall. The rationale for this can be found in the
commit message to [1]. For the curious there is more detail in [2].
This patchset would unblock supervising an extended set of syscalls such
as mount() where a privileged process is supervising the syscalls of a
lesser privileged process and emulates the syscall for the latter in
userspace.
For more comments on security see [1].
Kees, if you prefer a pr the series can be pulled from:
git@gitolite.kernel.org:pub/scm/linux/kernel/git/brauner/linux tags/seccomp-notify-syscall-continue-v5.5
For anyone who wants to play with this it's sitting in:
https://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/log/?h=se…
/* v1 */
- Kees Cook <keescook(a)chromium.org>:
- dropped patch because it is already present in linux-next
[PATCH 2/4] seccomp: add two missing ptrace ifdefines
Link: https://lore.kernel.org/r/20190918084833.9369-3-christian.brauner@ubuntu.com
/* v0 */
Link: https://lore.kernel.org/r/20190918084833.9369-1-christian.brauner@ubuntu.com
Thanks!
Christian
/* References */
[1]: [PATCH 1/3] seccomp: add SECCOMP_USER_NOTIF_FLAG_CONTINUE
[2]: https://lore.kernel.org/r/20190719093538.dhyopljyr5ns33qx@brauner.io
[3]: https://linuxplumbersconf.org/event/4/contributions/560
Christian Brauner (3):
seccomp: add SECCOMP_USER_NOTIF_FLAG_CONTINUE
seccomp: avoid overflow in implicit constant conversion
seccomp: test SECCOMP_USER_NOTIF_FLAG_CONTINUE
include/uapi/linux/seccomp.h | 20 ++++
kernel/seccomp.c | 28 ++++-
tools/testing/selftests/seccomp/seccomp_bpf.c | 105 +++++++++++++++++-
3 files changed, 146 insertions(+), 7 deletions(-)
--
2.23.0
Hey everyone,
This is the patchset coming out of the KSummit session Kees and I gave
in Lisbon last week (cf. [3] which also contains slides with more
details on related things such as deep argument inspection).
The simple idea is to extend the seccomp notifier to allow for the
continuation of a syscall. The rationale for this can be found in the
commit message to [1]. For the curious there is more detail in [2].
This patchset would unblock supervising an extended set of syscalls such
as mount() where a privileged process is supervising the syscalls of a
lesser privileged process and emulates the syscall for the latter in
userspace.
For more comments on security see [1].
Thanks!
Christian
/* References */
[1]: [PATCH 1/4] seccomp: add SECCOMP_RET_USER_NOTIF_ALLOW
[2]: https://lore.kernel.org/r/20190719093538.dhyopljyr5ns33qx@brauner.io
[3]: https://linuxplumbersconf.org/event/4/contributions/560
Christian Brauner (4):
seccomp: add SECCOMP_RET_USER_NOTIF_ALLOW
seccomp: add two missing ptrace ifdefines
seccomp: avoid overflow in implicit constant conversion
seccomp: test SECCOMP_RET_USER_NOTIF_ALLOW
include/uapi/linux/seccomp.h | 2 +
kernel/seccomp.c | 24 +++-
tools/testing/selftests/seccomp/seccomp_bpf.c | 110 +++++++++++++++++-
3 files changed, 131 insertions(+), 5 deletions(-)
--
2.23.0
From: "George G. Davis" <george_davis(a)mentor.com>
The newly added optional file argument does not validate if the
file is indeed a watchdog, e.g.:
./watchdog-test -f /dev/zero
Watchdog Ticking Away!
Fix it by confirming that the WDIOC_GETSUPPORT ioctl succeeds.
Fixes: c3f2490d6e9257 ("selftests: watchdog: Add optional file argument")
Reported-by: Eugeniu Rosca <erosca(a)de.adit-jv.com>
Signed-off-by: George G. Davis <george_davis(a)mentor.com>
Signed-off-by: Eugeniu Rosca <erosca(a)de.adit-jv.com>
---
v3:
- Used v1 as starting point and simplified commit description
- Added Fixes tag (WARNING: commit id is from linux-next!)
- No change in the contents
- Applied cleanly to the same base as used in [v1]
v2:
- https://patchwork.kernel.org/patch/11147663/
v1:
- https://patchwork.kernel.org/patch/11136283/
- Applied/tested on commit ce54eab71e210f ("kunit: fix failure to build without printk") of
https://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest.git/l…
---
tools/testing/selftests/watchdog/watchdog-test.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/tools/testing/selftests/watchdog/watchdog-test.c b/tools/testing/selftests/watchdog/watchdog-test.c
index afff120c7be6..6ed822dc2222 100644
--- a/tools/testing/selftests/watchdog/watchdog-test.c
+++ b/tools/testing/selftests/watchdog/watchdog-test.c
@@ -97,6 +97,7 @@ int main(int argc, char *argv[])
int c;
int oneshot = 0;
char *file = "/dev/watchdog";
+ struct watchdog_info info;
setbuf(stdout, NULL);
@@ -118,6 +119,16 @@ int main(int argc, char *argv[])
exit(-1);
}
+ /*
+ * Validate that `file` is a watchdog device
+ */
+ ret = ioctl(fd, WDIOC_GETSUPPORT, &info);
+ if (ret) {
+ printf("WDIOC_GETSUPPORT error '%s'\n", strerror(errno));
+ close(fd);
+ exit(ret);
+ }
+
optind = 0;
while ((c = getopt_long(argc, argv, sopts, lopts, NULL)) != -1) {
--
2.23.0
Problem:
Currently tasks attempting to allocate more hugetlb memory than is available get
a failure at mmap/shmget time. This is thanks to Hugetlbfs Reservations [1].
However, if a task attempts to allocate hugetlb memory only more than its
hugetlb_cgroup limit allows, the kernel will allow the mmap/shmget call,
but will SIGBUS the task when it attempts to fault the memory in.
We have developers interested in using hugetlb_cgroups, and they have expressed
dissatisfaction regarding this behavior. We'd like to improve this
behavior such that tasks violating the hugetlb_cgroup limits get an error on
mmap/shmget time, rather than getting SIGBUS'd when they try to fault
the excess memory in.
The underlying problem is that today's hugetlb_cgroup accounting happens
at hugetlb memory *fault* time, rather than at *reservation* time.
Thus, enforcing the hugetlb_cgroup limit only happens at fault time, and
the offending task gets SIGBUS'd.
Proposed Solution:
A new page counter named hugetlb.xMB.reservation_[limit|usage]_in_bytes. This
counter has slightly different semantics than
hugetlb.xMB.[limit|usage]_in_bytes:
- While usage_in_bytes tracks all *faulted* hugetlb memory,
reservation_usage_in_bytes tracks all *reserved* hugetlb memory.
- If a task attempts to reserve more memory than limit_in_bytes allows,
the kernel will allow it to do so. But if a task attempts to reserve
more memory than reservation_limit_in_bytes, the kernel will fail this
reservation.
This proposal is implemented in this patch, with tests to verify
functionality and show the usage.
Alternatives considered:
1. A new cgroup, instead of only a new page_counter attached to
the existing hugetlb_cgroup. Adding a new cgroup seemed like a lot of code
duplication with hugetlb_cgroup. Keeping hugetlb related page counters under
hugetlb_cgroup seemed cleaner as well.
2. Instead of adding a new counter, we considered adding a sysctl that modifies
the behavior of hugetlb.xMB.[limit|usage]_in_bytes, to do accounting at
reservation time rather than fault time. Adding a new page_counter seems
better as userspace could, if it wants, choose to enforce different cgroups
differently: one via limit_in_bytes, and another via
reservation_limit_in_bytes. This could be very useful if you're
transitioning how hugetlb memory is partitioned on your system one
cgroup at a time, for example. Also, someone may find usage for both
limit_in_bytes and reservation_limit_in_bytes concurrently, and this
approach gives them the option to do so.
Caveats:
1. This support is implemented for cgroups-v1. I have not tried
hugetlb_cgroups with cgroups v2, and AFAICT it's not supported yet.
This is largely because we use cgroups-v1 for now. If required, I
can add hugetlb_cgroup support to cgroups v2 in this patch or
a follow up.
2. Most complicated bit of this patch I believe is: where to store the
pointer to the hugetlb_cgroup to uncharge at unreservation time?
Normally the cgroup pointers hang off the struct page. But, with
hugetlb_cgroup reservations, one task can reserve a specific page and another
task may fault it in (I believe), so storing the pointer in struct
page is not appropriate. Proposed approach here is to store the pointer in
the resv_map. See patch for details.
Testing:
- Added tests passing.
- libhugetlbfs tests mostly passing, but some tests have trouble with and
without this patch series. Seems environment issue rather than code:
- Overall results:
********** TEST SUMMARY
* 2M
* 32-bit 64-bit
* Total testcases: 84 0
* Skipped: 0 0
* PASS: 66 0
* FAIL: 14 0
* Killed by signal: 0 0
* Bad configuration: 4 0
* Expected FAIL: 0 0
* Unexpected PASS: 0 0
* Test not present: 0 0
* Strange test result: 0 0
**********
- Failing tests:
- elflink_rw_and_share_test("linkhuge_rw") segfaults with and without this
patch series.
- LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes malloc (2M: 32):
FAIL Address is not hugepage
- LD_PRELOAD=libhugetlbfs.so HUGETLB_RESTRICT_EXE=unknown:malloc
HUGETLB_MORECORE=yes malloc (2M: 32):
FAIL Address is not hugepage
- LD_PRELOAD=libhugetlbfs.so HUGETLB_MORECORE=yes malloc_manysmall (2M: 32):
FAIL Address is not hugepage
- GLIBC_TUNABLES=glibc.malloc.tcache_count=0 LD_PRELOAD=libhugetlbfs.so
HUGETLB_MORECORE=yes heapshrink (2M: 32):
FAIL Heap not on hugepages
- GLIBC_TUNABLES=glibc.malloc.tcache_count=0 LD_PRELOAD=libhugetlbfs.so
libheapshrink.so HUGETLB_MORECORE=yes heapshrink (2M: 32):
FAIL Heap not on hugepages
- HUGETLB_ELFMAP=RW linkhuge_rw (2M: 32): FAIL small_data is not hugepage
- HUGETLB_ELFMAP=RW HUGETLB_MINIMAL_COPY=no linkhuge_rw (2M: 32):
FAIL small_data is not hugepage
- alloc-instantiate-race shared (2M: 32):
Bad configuration: sched_setaffinity(cpu1): Invalid argument -
FAIL Child 1 killed by signal Killed
- shmoverride_linked (2M: 32):
FAIL shmget failed size 2097152 from line 176: Invalid argument
- HUGETLB_SHM=yes shmoverride_linked (2M: 32):
FAIL shmget failed size 2097152 from line 176: Invalid argument
- shmoverride_linked_static (2M: 32):
FAIL shmget failed size 2097152 from line 176: Invalid argument
- HUGETLB_SHM=yes shmoverride_linked_static (2M: 32):
FAIL shmget failed size 2097152 from line 176: Invalid argument
- LD_PRELOAD=libhugetlbfs.so shmoverride_unlinked (2M: 32):
FAIL shmget failed size 2097152 from line 176: Invalid argument
- LD_PRELOAD=libhugetlbfs.so HUGETLB_SHM=yes shmoverride_unlinked (2M: 32):
FAIL shmget failed size 2097152 from line 176: Invalid argument
Signed-off-by: Mina Almasry <almasrymina(a)google.com>
[1]: https://www.kernel.org/doc/html/latest/vm/hugetlbfs_reserv.html
Changes in v4:
- Split up 'hugetlb_cgroup: add accounting for shared mappings' into 4 patches
for better isolation and context on the individual changes:
- hugetlb_cgroup: add accounting for shared mappings
- hugetlb: disable region_add file_region coalescing
- hugetlb: remove duplicated code
- hugetlb: region_chg provides only cache entry
- Fixed resv->adds_in_progress accounting.
- Retained behavior that region_add never fails, in earlier patchsets region_add
could return failure.
- Fixed libhugetlbfs failure.
- Minor fix to the added tests that was preventing them from running on some
environments.
Changes in v3:
- Addressed comments of Hillf Danton:
- Added docs.
- cgroup_files now uses enum.
- Various readability improvements.
- Addressed comments of Mike Kravetz.
- region_* functions no longer coalesce file_region entries in the resv_map.
- region_add() and region_chg() refactored to make them much easier to
understand and remove duplicated code so this patch doesn't add too much
complexity.
- Refactored common functionality into helpers.
Changes in v2:
- Split the patch into a 5 patch series.
- Fixed patch subject.
Mina Almasry (9):
hugetlb_cgroup: Add hugetlb_cgroup reservation counter
hugetlb_cgroup: add interface for charge/uncharge hugetlb reservations
hugetlb_cgroup: add reservation accounting for private mappings
hugetlb: region_chg provides only cache entry
hugetlb: remove duplicated code
hugetlb: disable region_add file_region coalescing
hugetlb_cgroup: add accounting for shared mappings
hugetlb_cgroup: Add hugetlb_cgroup reservation tests
hugetlb_cgroup: Add hugetlb_cgroup reservation docs
.../admin-guide/cgroup-v1/hugetlb.rst | 84 ++-
include/linux/hugetlb.h | 24 +-
include/linux/hugetlb_cgroup.h | 24 +-
mm/hugetlb.c | 516 +++++++++++-------
mm/hugetlb_cgroup.c | 189 +++++--
tools/testing/selftests/vm/.gitignore | 1 +
tools/testing/selftests/vm/Makefile | 4 +
.../selftests/vm/charge_reserved_hugetlb.sh | 440 +++++++++++++++
.../selftests/vm/write_hugetlb_memory.sh | 22 +
.../testing/selftests/vm/write_to_hugetlbfs.c | 252 +++++++++
10 files changed, 1304 insertions(+), 252 deletions(-)
create mode 100755 tools/testing/selftests/vm/charge_reserved_hugetlb.sh
create mode 100644 tools/testing/selftests/vm/write_hugetlb_memory.sh
create mode 100644 tools/testing/selftests/vm/write_to_hugetlbfs.c
--
2.23.0.162.g0b9fbb3734-goog