Commit 8b59cd81dc5e ("kbuild: ensure full rebuild when the compiler is
updated") introduced a new CONFIG option CONFIG_CC_VERSION_TEXT. On my
system, this is set to "gcc (GCC) 10.1.0" which breaks KUnit config
parsing which did not like the spaces in the string.
Fix this by updating the regex to allow strings containing spaces.
Fixes: 8b59cd81dc5e ("kbuild: ensure full rebuild when the compiler is updated")
Signed-off-by: Rikard Falkeborn <rikard.falkeborn(a)gmail.com>
---
Maybe it would have been sufficient to just use
CONFIG_PATTERN = r'^CONFIG_(\w+)=(.*)$' instead?
tools/testing/kunit/kunit_config.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/kunit/kunit_config.py b/tools/testing/kunit/kunit_config.py
index e75063d603b5..02ffc3a3e5dc 100644
--- a/tools/testing/kunit/kunit_config.py
+++ b/tools/testing/kunit/kunit_config.py
@@ -10,7 +10,7 @@ import collections
import re
CONFIG_IS_NOT_SET_PATTERN = r'^# CONFIG_(\w+) is not set$'
-CONFIG_PATTERN = r'^CONFIG_(\w+)=(\S+)$'
+CONFIG_PATTERN = r'^CONFIG_(\w+)=(\S+|".*")$'
KconfigEntryBase = collections.namedtuple('KconfigEntry', ['name', 'value'])
--
2.27.0
The test_vmlinux test uses hrtimer_nanosleep as hook to test tracing
programs. But it seems Clang may have done an aggressive optimization,
causing fentry and kprobe to not hook on this function properly on a
Clang build kernel.
A possible fix is switching to use a more reliable function, e.g. the
ones exported to kernel modules such as hrtimer_range_start_ns. After
we switch to using hrtimer_range_start_ns, the test passes again even
on a clang build kernel.
Tested:
In a clang build kernel, the test fail even when the flags
{fentry, kprobe}_called are set unconditionally in handle__kprobe()
and handle__fentry(), which implies the programs do not hook on
hrtimer_nanosleep() properly. This could be because clang's code
transformation is too aggressive.
test_vmlinux:PASS:skel_open 0 nsec
test_vmlinux:PASS:skel_attach 0 nsec
test_vmlinux:PASS:tp 0 nsec
test_vmlinux:PASS:raw_tp 0 nsec
test_vmlinux:PASS:tp_btf 0 nsec
test_vmlinux:FAIL:kprobe not called
test_vmlinux:FAIL:fentry not called
After we switch to hrtimer_range_start_ns, the test passes.
test_vmlinux:PASS:skel_open 0 nsec
test_vmlinux:PASS:skel_attach 0 nsec
test_vmlinux:PASS:tp 0 nsec
test_vmlinux:PASS:raw_tp 0 nsec
test_vmlinux:PASS:tp_btf 0 nsec
test_vmlinux:PASS:kprobe 0 nsec
test_vmlinux:PASS:fentry 0 nsec
Signed-off-by: Hao Luo <haoluo(a)google.com>
---
tools/testing/selftests/bpf/progs/test_vmlinux.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/tools/testing/selftests/bpf/progs/test_vmlinux.c b/tools/testing/selftests/bpf/progs/test_vmlinux.c
index 5611b564d3b1..29fa09d6a6c6 100644
--- a/tools/testing/selftests/bpf/progs/test_vmlinux.c
+++ b/tools/testing/selftests/bpf/progs/test_vmlinux.c
@@ -63,20 +63,20 @@ int BPF_PROG(handle__tp_btf, struct pt_regs *regs, long id)
return 0;
}
-SEC("kprobe/hrtimer_nanosleep")
-int BPF_KPROBE(handle__kprobe,
- ktime_t rqtp, enum hrtimer_mode mode, clockid_t clockid)
+SEC("kprobe/hrtimer_start_range_ns")
+int BPF_KPROBE(handle__kprobe, struct hrtimer *timer, ktime_t tim, u64 delta_ns,
+ const enum hrtimer_mode mode)
{
- if (rqtp == MY_TV_NSEC)
+ if (tim == MY_TV_NSEC)
kprobe_called = true;
return 0;
}
-SEC("fentry/hrtimer_nanosleep")
-int BPF_PROG(handle__fentry,
- ktime_t rqtp, enum hrtimer_mode mode, clockid_t clockid)
+SEC("fentry/hrtimer_start_range_ns")
+int BPF_PROG(handle__fentry, struct hrtimer *timer, ktime_t tim, u64 delta_ns,
+ const enum hrtimer_mode mode)
{
- if (rqtp == MY_TV_NSEC)
+ if (tim == MY_TV_NSEC)
fentry_called = true;
return 0;
}
--
2.27.0.212.ge8ba1cc988-goog
The goal for this series is to introduce the hmm_range_fault() output
array flags HMM_PFN_PMD and HMM_PFN_PUD. This allows a device driver to
know that a given 4K PFN is actually mapped by the CPU using either a
PMD sized or PUD sized CPU page table entry and therefore the device
driver can safely map system memory using larger device MMU PTEs.
The series is based on 5.8.0-rc3 and is intended for Jason Gunthorpe's
hmm tree. These were originally part of a larger series:
https://lore.kernel.org/linux-mm/20200619215649.32297-1-rcampbell@nvidia.co…
Changes in v2:
Make the hmm_range_fault() API changes into a separate series and add
two output flags for PMD/PUD instead of a single compund page flag as
suggested by Jason Gunthorpe.
Make the nouveau page table changes a separate patch as suggested by
Ben Skeggs.
Only add support for 2MB nouveau mappings initially since changing the
1:1 CPU/GPU page table size assumptions requires a bigger set of changes.
Rebase to 5.8.0-rc3.
Ralph Campbell (5):
nouveau/hmm: fault one page at a time
mm/hmm: add output flags for PMD/PUD page mapping
nouveau: fix mapping 2MB sysmem pages
nouveau/hmm: support mapping large sysmem pages
hmm: add tests for HMM_PFN_PMD flag
drivers/gpu/drm/nouveau/nouveau_svm.c | 238 ++++++++----------
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 5 +-
.../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c | 82 ++++++
include/linux/hmm.h | 11 +-
lib/test_hmm.c | 4 +
lib/test_hmm_uapi.h | 4 +
mm/hmm.c | 13 +-
tools/testing/selftests/vm/hmm-tests.c | 76 ++++++
8 files changed, 290 insertions(+), 143 deletions(-)
--
2.20.1
## TL;DR
This patchset adds a centralized executor to dispatch tests rather than
relying on late_initcall to schedule each test suite separately along
with a couple of new features that depend on it.
Also, sorry for the extreme delay in getting this out. Part of the delay
came from finding that there were actually several architectures that
the previous revision of this patchset didn't work on, so I went through
and attempted to test this patchset on every architecture - more on that
later.
## What am I trying to do?
Conceptually, I am trying to provide a mechanism by which test suites
can be grouped together so that they can be reasoned about collectively.
The last two of three patches in this series add features which depend
on this:
PATCH 8/11 Prints out a test plan[1] right before KUnit tests are run;
this is valuable because it makes it possible for a test
harness to detect whether the number of tests run matches the
number of tests expected to be run, ensuring that no tests
silently failed. The test plan includes a count of tests that
will run. With the centralized executor, the tests are
located in a single data structure and thus can be counted.
PATCH 9/11 Add a new kernel command-line option which allows the user to
specify that the kernel poweroff, halt, or reboot after
completing all KUnit tests; this is very handy for running
KUnit tests on UML or a VM so that the UML/VM process exits
cleanly immediately after running all tests without needing a
special initramfs. The centralized executor provides a
definitive point when all tests have completed and the
poweroff, halt, or reboot could occur.
In addition, by dispatching tests from a single location, we can
guarantee that all KUnit tests run after late_init is complete, which
was a concern during the initial KUnit patchset review (this has not
been a problem in practice, but resolving with certainty is nevertheless
desirable).
Other use cases for this exist, but the above features should provide an
idea of the value that this could provide.
## Changes since last revision:
- On the last revision I got some messages from 0day that showed that
this patchset didn't work on several architectures, one issue that
this patchset addresses is that we were aligning both memory segments
as well as structures in the segments to specific byte boundaries
which was incorrect.
- The issue mentioned above also caused me to test on additional
architectures which revealed that some architectures other than UML
do not use the default init linker section macro that most
architectures use. There are now several new patches (2, 3, 4, and
6).
- Fixed a formatting consistency issue in the kernel params
documentation patch (9/9).
- Add a brief blurb on how and when the kunit_test_suite macro works.
## Remaining work to be done:
The only architecture for which I was able to get a compiler, but was
apparently unable to get KUnit into a section that the executor to see
was m68k - not sure why.
Alan Maguire (1):
kunit: test: create a single centralized executor for all tests
Brendan Higgins (10):
vmlinux.lds.h: add linker section for KUnit test suites
arch: arm64: add linker section for KUnit test suites
arch: microblaze: add linker section for KUnit test suites
arch: powerpc: add linker section for KUnit test suites
arch: um: add linker section for KUnit test suites
arch: xtensa: add linker section for KUnit test suites
init: main: add KUnit to kernel init
kunit: test: add test plan to KUnit TAP format
Documentation: Add kunit_shutdown to kernel-parameters.txt
Documentation: kunit: add a brief blurb about kunit_test_suite
.../admin-guide/kernel-parameters.txt | 8 ++
Documentation/dev-tools/kunit/usage.rst | 5 ++
arch/arm64/kernel/vmlinux.lds.S | 3 +
arch/microblaze/kernel/vmlinux.lds.S | 4 +
arch/powerpc/kernel/vmlinux.lds.S | 4 +
arch/um/include/asm/common.lds.S | 4 +
arch/xtensa/kernel/vmlinux.lds.S | 4 +
include/asm-generic/vmlinux.lds.h | 8 ++
include/kunit/test.h | 73 ++++++++++++-----
init/main.c | 4 +
lib/kunit/Makefile | 3 +-
lib/kunit/executor.c | 63 +++++++++++++++
lib/kunit/test.c | 13 +--
tools/testing/kunit/kunit_kernel.py | 2 +-
tools/testing/kunit/kunit_parser.py | 74 +++++++++++++++---
.../test_is_test_passed-all_passed.log | Bin 1562 -> 1567 bytes
.../test_data/test_is_test_passed-crash.log | Bin 3016 -> 3021 bytes
.../test_data/test_is_test_passed-failure.log | Bin 1700 -> 1705 bytes
18 files changed, 226 insertions(+), 46 deletions(-)
create mode 100644 lib/kunit/executor.c
base-commit: 4333a9b0b67bb4e8bcd91bdd80da80b0ec151162
prerequisite-patch-id: 2d4b5aa9fa8ada9ae04c8584b47c299a822b9455
prerequisite-patch-id: 582b6d9d28ce4b71628890ec832df6522ca68de0
These patches are available for download with dependencies here:
https://kunit-review.googlesource.com/c/linux/+/3829
[1] https://github.com/isaacs/testanything.github.io/blob/tap14/tap-version-14-…
[2] https://patchwork.kernel.org/patch/11383635/
--
2.27.0.212.ge8ba1cc988-goog
It is Very Rude to clear dmesg in test scripts. That's because the
script may be part of a larger test run, and clearing dmesg
potentially destroys the output of other tests.
We can avoid using dmesg -c by saving the content of dmesg before the
test, and then using diff to compare that to the dmesg afterward,
producing a log with just the added lines.
Signed-off-by: Michael Ellerman <mpe(a)ellerman.id.au>
---
tools/testing/selftests/lkdtm/run.sh | 14 ++++++++------
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/tools/testing/selftests/lkdtm/run.sh b/tools/testing/selftests/lkdtm/run.sh
index dadf819148a4..0b409e187c7b 100755
--- a/tools/testing/selftests/lkdtm/run.sh
+++ b/tools/testing/selftests/lkdtm/run.sh
@@ -59,23 +59,25 @@ if [ -z "$expect" ]; then
expect="call trace:"
fi
-# Clear out dmesg for output reporting
-dmesg -c >/dev/null
-
# Prepare log for report checking
-LOG=$(mktemp --tmpdir -t lkdtm-XXXXXX)
+LOG=$(mktemp --tmpdir -t lkdtm-log-XXXXXX)
+DMESG=$(mktemp --tmpdir -t lkdtm-dmesg-XXXXXX)
cleanup() {
- rm -f "$LOG"
+ rm -f "$LOG" "$DMESG"
}
trap cleanup EXIT
+# Save existing dmesg so we can detect new content below
+dmesg > "$DMESG"
+
# Most shells yell about signals and we're expecting the "cat" process
# to usually be killed by the kernel. So we have to run it in a sub-shell
# and silence errors.
($SHELL -c 'cat <(echo '"$test"') >'"$TRIGGER" 2>/dev/null) || true
# Record and dump the results
-dmesg -c >"$LOG"
+dmesg | diff --changed-group-format='%>' --unchanged-group-format='' "$DMESG" - > "$LOG" || true
+
cat "$LOG"
# Check for expected output
if egrep -qi "$expect" "$LOG" ; then
base-commit: 192ffb7515839b1cc8457e0a8c1e09783de019d3
--
2.25.1
Hi Greg,
(Since this was aleady pending, I just spun a v2, resent here.)
Can you please apply these patches to your drivers/misc tree for LKDTM?
It's mostly a collection of fixes and improvements and tweaks to the
selftest integration.
Thanks!
-Kees
v2: - add fix for UML build failures (Randy, Richard)
v1: https://lore.kernel.org/lkml/20200529200347.2464284-1-keescook@chromium.org/
Kees Cook (4):
lkdtm: Avoid more compiler optimizations for bad writes
lkdtm/heap: Avoid edge and middle of slabs
selftests/lkdtm: Reset WARN_ONCE to avoid false negatives
lkdtm: Make arch-specific tests always available
drivers/misc/lkdtm/bugs.c | 49 +++++++++++++------------
drivers/misc/lkdtm/heap.c | 9 +++--
drivers/misc/lkdtm/lkdtm.h | 2 -
drivers/misc/lkdtm/perms.c | 22 +++++++----
drivers/misc/lkdtm/usercopy.c | 7 +++-
tools/testing/selftests/lkdtm/run.sh | 6 +++
tools/testing/selftests/lkdtm/tests.txt | 1 +
7 files changed, 58 insertions(+), 38 deletions(-)
--
2.25.1
Hi Greg,
Can you please apply these patches to your drivers/misc tree for LKDTM?
It's mostly a collection of fixes and improvements and tweaks to the
selftest integration.
Thanks!
-Kees
Kees Cook (4):
lkdtm: Avoid more compiler optimizations for bad writes
lkdtm/heap: Avoid edge and middle of slabs
selftests/lkdtm: Reset WARN_ONCE to avoid false negatives
lkdtm: Make arch-specific tests always available
drivers/misc/lkdtm/bugs.c | 45 +++++++++++++------------
drivers/misc/lkdtm/heap.c | 9 ++---
drivers/misc/lkdtm/lkdtm.h | 2 --
drivers/misc/lkdtm/perms.c | 22 ++++++++----
drivers/misc/lkdtm/usercopy.c | 7 ++--
tools/testing/selftests/lkdtm/run.sh | 6 ++++
tools/testing/selftests/lkdtm/tests.txt | 1 +
7 files changed, 56 insertions(+), 36 deletions(-)
--
2.25.1
## TL;DR
This patchset adds a centralized executor to dispatch tests rather than
relying on late_initcall to schedule each test suite separately along
with a couple of new features that depend on it.
Also, sorry for the delay in getting this new revision out. I have been
really busy for the past couple weeks.
## What am I trying to do?
Conceptually, I am trying to provide a mechanism by which test suites
can be grouped together so that they can be reasoned about collectively.
The last two of three patches in this series add features which depend
on this:
PATCH 5/7 Prints out a test plan[1] right before KUnit tests are run;
this is valuable because it makes it possible for a test
harness to detect whether the number of tests run matches the
number of tests expected to be run, ensuring that no tests
silently failed. The test plan includes a count of tests that
will run. With the centralized executor, the tests are located
in a single data structure and thus can be counted.
PATCH 6/7 Add a new kernel command-line option which allows the user to
specify that the kernel poweroff, halt, or reboot after
completing all KUnit tests; this is very handy for running
KUnit tests on UML or a VM so that the UML/VM process exits
cleanly immediately after running all tests without needing a
special initramfs. The centralized executor provides a
definitive point when all tests have completed and the
poweroff, halt, or reboot could occur.
In addition, by dispatching tests from a single location, we can
guarantee that all KUnit tests run after late_init is complete, which
was a concern during the initial KUnit patchset review (this has not
been a problem in practice, but resolving with certainty is nevertheless
desirable).
Other use cases for this exist, but the above features should provide an
idea of the value that this could provide.
## Changes since last revision:
- On patch 7/7, I added some additional wording around the
kunit_shutdown command line option explaining that it runs after
built-in tests as suggested by Frank.
- On the coverletter, I improved some wording and added a missing link.
I also specified the base-commit for the series.
- Frank asked for some changes to the documentation; however, David is
taking care of that in a separate patch[2], so I did not make those
changes here. There will be some additional changes necessary
after David's patch is applied.
Alan Maguire (1):
kunit: test: create a single centralized executor for all tests
Brendan Higgins (5):
vmlinux.lds.h: add linker section for KUnit test suites
arch: um: add linker section for KUnit test suites
init: main: add KUnit to kernel init
kunit: test: add test plan to KUnit TAP format
Documentation: Add kunit_shutdown to kernel-parameters.txt
David Gow (1):
kunit: Add 'kunit_shutdown' option
.../admin-guide/kernel-parameters.txt | 8 ++
arch/um/include/asm/common.lds.S | 4 +
include/asm-generic/vmlinux.lds.h | 8 ++
include/kunit/test.h | 82 ++++++++++++-------
init/main.c | 4 +
lib/kunit/Makefile | 3 +-
lib/kunit/executor.c | 71 ++++++++++++++++
lib/kunit/test.c | 11 ---
tools/testing/kunit/kunit_kernel.py | 2 +-
tools/testing/kunit/kunit_parser.py | 76 ++++++++++++++---
.../test_is_test_passed-all_passed.log | 1 +
.../test_data/test_is_test_passed-crash.log | 1 +
.../test_data/test_is_test_passed-failure.log | 1 +
13 files changed, 218 insertions(+), 54 deletions(-)
create mode 100644 lib/kunit/executor.c
base-commit: a2f0b878c3ca531a1706cb2a8b079cea3b17bafc
[1] https://github.com/isaacs/testanything.github.io/blob/tap14/tap-version-14-…
[2] https://patchwork.kernel.org/patch/11383635/
--
2.25.1.481.gfbce0eb801-goog
The arm64 signal tests generate warnings during build since both they and
the toplevel lib.mk define a clean target:
Makefile:25: warning: overriding recipe for target 'clean'
../../lib.mk:126: warning: ignoring old recipe for target 'clean'
Since the inclusion of lib.mk is in the signal Makefile there is no
situation where this warning could be avoided so just remove the redundant
clean target.
Signed-off-by: Mark Brown <broonie(a)kernel.org>
---
tools/testing/selftests/arm64/signal/Makefile | 4 ----
1 file changed, 4 deletions(-)
diff --git a/tools/testing/selftests/arm64/signal/Makefile b/tools/testing/selftests/arm64/signal/Makefile
index b497cfea4643..ac4ad0005715 100644
--- a/tools/testing/selftests/arm64/signal/Makefile
+++ b/tools/testing/selftests/arm64/signal/Makefile
@@ -21,10 +21,6 @@ include ../../lib.mk
$(TEST_GEN_PROGS): $(PROGS)
cp $(PROGS) $(OUTPUT)/
-clean:
- $(CLEAN)
- rm -f $(PROGS)
-
# Common test-unit targets to build common-layout test-cases executables
# Needs secondary expansion to properly include the testcase c-file in pre-reqs
.SECONDEXPANSION:
--
2.20.1
Tim Bird started a thread [1] proposing that he document the selftest result
format used by Linux kernel tests.
[1] https://lore.kernel.org/r/CY4PR13MB1175B804E31E502221BC8163FD830@CY4PR13MB1…
The issue of messages generated by the kernel being tested (that are not
messages directly created by the tests, but are instead triggered as a
side effect of the test) came up. In this thread, I will call these
messages "expected messages". Instead of sidetracking that thread with
a proposal to handle expected messages, I am starting this new thread.
I implemented an API for expected messages that are triggered by tests
in the Devicetree unittest code, with the expectation that the specific
details may change when the Devicetree unittest code adapts the KUnit
API. It seems appropriate to incorporate the concept of expected
messages in Tim's documentation instead of waiting to address the
subject when the Devicetree unittest code adapts the KUnit API, since
Tim's document may become the kernel selftest standard.
Instead of creating a very long email containing multiple objects,
I will reply to this email with a separate reply for each of:
The "expected messages" API implemention and use can be from
drivers/of/unittest.c in the mainline kernel.
of_unittest_expect - A proof of concept perl program to filter console
output containing expected messages output
of_unittest_expect is also available by cloning
https://github.com/frowand/dt_tools.git
An example raw console output with timestamps and expect messages.
An example of console output processed by filter program
of_unittest_expect to be more human readable. The expected
messages are not removed, but are flagged.
An example of console output processed by filter program
of_unittest_expect to be more human readable. The expected
messages are removed instead of being flagged.
Fix
make[1]: execvp: /bin/sh: Argument list too long
encountered with some shells and a couple of more potential problems
in that part of code.
Yauheni Kaliuta (3):
selftests: do not use .ONESHELL
selftests: fix condition in run_tests
selftests: simplify run_tests
tools/testing/selftests/lib.mk | 19 ++++++-------------
1 file changed, 6 insertions(+), 13 deletions(-)
--
2.26.2
Changeset 1eecbcdca2bd ("docs: move protection-keys.rst to the core-api book")
from Jun 7, 2019 converted protection-keys.txt file to ReST.
A recent change at protection_keys.c partially reverted such
changeset, causing it to point to a non-existing file:
- * Tests x86 Memory Protection Keys (see Documentation/core-api/protection-keys.rst)
+ * Tests Memory Protection Keys (see Documentation/vm/protection-keys.txt)
It sounds to me that the changeset that introduced such change
4645e3563673 ("selftests/vm/pkeys: rename all references to pkru to a generic name")
could also have other side effects, as it sounds that it was not
generated against uptream code, but, instead, against a version
older than Jun 7, 2019.
Fixes: 4645e3563673 ("selftests/vm/pkeys: rename all references to pkru to a generic name")
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei(a)kernel.org>
---
tools/testing/selftests/vm/protection_keys.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/vm/protection_keys.c b/tools/testing/selftests/vm/protection_keys.c
index fc19addcb5c8..fdbb602ecf32 100644
--- a/tools/testing/selftests/vm/protection_keys.c
+++ b/tools/testing/selftests/vm/protection_keys.c
@@ -1,6 +1,6 @@
// SPDX-License-Identifier: GPL-2.0
/*
- * Tests Memory Protection Keys (see Documentation/vm/protection-keys.txt)
+ * Tests Memory Protection Keys (see Documentation/core-api/protection-keys.rst)
*
* There are examples in here of:
* * how to set protection keys on memory
--
2.26.2
Some months ago I started work on a document to formalize how
kselftest implements the TAP specification. However, I didn't finish
that work. Maybe it's time to do so now.
kselftest has developed a few differences from the original
TAP specification, and some extensions that I believe are worth
documenting.
Essentially, we have created our own KTAP (kernel TAP)
format. I think it is worth documenting our conventions, in order to
keep everyone on the same page.
Below is a partially completed document on my understanding
of KTAP, based on examination of some of the kselftest test
output. I have not reconciled this with the kunit output format,
which I believe has some differences (which maybe we should
resolve before we get too far into this).
I submit the document now, before it is finished, because a patch
was recently introduced to alter one of the result conventions
(from SKIP='not ok' to SKIP='ok').
See the document include inline below
====== start of ktap-doc-rfc.txt ======
Selftest preferred output format
--------------------------------
The linux kernel selftest system uses TAP (Test Anything Protocol)
output to make testing results consumable by automated systems. A
number of Continuous Integration (CI) systems test the kernel every
day. It is useful for these systems that output from selftest
programs be consistent and machine-parsable.
At the same time, it is useful for test results to be human-readable
as well.
The kernel test result format is based on a variation TAP
TAP is a simple text-based format that is
documented on the TAP home page (http://testanything.org/). There
is an official TAP13 specification here:
http://testanything.org/tap-version-13-specification.html
The kernel test result format consists of 5 major elements,
4 of which are line-based:
* the output version line
* the plan line
* one or more test result lines (also called test result lines)
* a possible "Bail out!" line
optional elements:
* diagnostic data
The 5th element is diagnostic information, which is used to describe
items running in the test, and possibly to explain test results.
A sample test result is show below:
Some other lines may be placed the test harness, and are not emitted
by individual test programs:
* one or more test identification lines
* a possible results summary line
Here is an example:
TAP version 13
1..1
# selftests: cpufreq: main.sh
# pid 8101's current affinity mask: fff
# pid 8101's new affinity mask: 1
ok 1 selftests: cpufreq: main.sh
The output version line is: "TAP version 13"
The test plan is "1..1".
Element details
===============
Output version line
-------------------
The output version line is always "TAP version 13".
Although the kernel test result format has some additions
to the TAP13 format, the version line reported by kselftest tests
is (currently) always the exact string "TAP version 13"
This is always the first line of test output.
Test plan line
--------------
The test plan indicates the number of individual test cases intended to
be executed by the test. It always starts with "1.." and is followed
by the number of tests cases. In the example above, 1..1", indicates
that this test reports only 1 test case.
The test plan line can be placed in two locations:
* the second line of test output, when the number of test cases is known
in advance
* as the last line of test output, when the number of test cases is not
known in advance.
Most often, the number of test cases is known in advance, and the test plan
line appears as the second line of test output, immediately following
the output version line. The number of test cases might not be known
in advance if the number of tests is calculated from runtime data.
In this case, the test plan line is emitted as the last line of test
output.
Test result lines
-----------------
The test output consists of one or more test result lines that indicate
the actual results for the test. These have the format:
<result> <number> <description> [<directive>] [<diagnostic data>]
The ''result'' must appear at the start of a line (except for when a
test is nested, see below), and must consist of one of the following
two phrases:
* ok
* not ok
If the test passed, then the result is reported as "ok". If the test
failed, then the result is reported as "not ok". These must be in
lower case, exactly as shown.
The ''number'' in the test result line represents the number of the
test case being performed by the test program. This is often used by
test harnesses as a unique identifier for each test case. The test
number is a base-10 number, starting with 1. It should increase by
one for each new test result line emitted. If possible the number
for a test case should be kept the same over the lifetime of the test.
The ''description'' is a short description of the test case.
This can be any string of words, but should avoid using colons (':')
except as part of a fully qualifed test case name (see below).
Finally, it is possible to use a test directive to indicate another
possible outcome for a test: that it was skipped. To report that
a test case was skipped, the result line should start with the
result "not ok", and the directive "# SKIP" should be placed after
the test description. (Note that this deviates from the TAP13
specification).
A test may be skipped for a variety of reasons, ranging for
insufficient privileges to missing features or resources required
to execute that test case.
It is usually helpful if a diagnostic message is emitted to explain
the reasons for the skip. If the message is a single line and is
short, the diagnostic message may be placed after the '# SKIP'
directive on the same line as the test result. However, if it is
not on the test result line, it should precede the test line (see
diagnostic data, next).
Diagnostic data
---------------
Diagnostic data is text that reports on test conditions or test
operations, or that explains test results. In the kernel test
result format, diagnostic data is placed on lines that start with a
hash sign, followed by a space ('# ').
One special format of diagnostic data is a test identification line,
that has the fully qualified name of a test case. Such a test
identification line marks the start of test output for a test case.
In the example above, there are three lines that start with '#'
which precede the test result line:
# selftests: cpufreq: main.sh
# pid 8101's current affinity mask: fff
# pid 8101's new affinity mask: 1
These are used to indicate diagnostic data for the test case
'selftests: cpufreq: main.sh'
Material in comments between the identification line and the test
result line are diagnostic data that can help to interpret the
results of the test.
The TAP specification indicates that automated test harnesses may
ignore any line that is not one of the mandatory prescribed lines
(that is, the output format version line, the plan line, a test
result line, or a "Bail out!" line.)
Bail out!
---------
If a line in the test output starts with 'Bail out!', it indicates
that the test was aborted for some reason. It indicates that
the test is unable to proceed, and no additional tests will be
performed.
This can be used at the very beginning of a test, or anywhere in the
middle of the test, to indicate that the test can not continue.
--- from here on is not-yet-organized material
Tip:
- don't change the test plan based on skipped tests.
- it is better to report that a test case was skipped, than to
not report it
- that is, don't adjust the number of test cases based on skipped
tests
Other things to mention:
TAP13 elements not used:
- yaml for diagnostic messages
- reason: try to keep things line-based, since output from other things
may be interspersed with messages from the test itself
- TODO directive
KTAP Extensions beyond TAP13:
- nesting
- via indentation
- indentation makes it easier for humans to read
- test identifier
- multiple parts, separated by ':'
- summary lines
- can be skipped by CI systems that do their own calculations
Other notes:
- automatic assignment of result status based on exit code
Tips:
- do NOT describe the result in the test line
- the test case description should be the same whether the test
succeeds or fails
- use diagnostic lines to describe or explain results, if this is
desirable
- test numbers are considered harmful
- test harnesses should use the test description as the identifier
- test numbers change when testcases are added or removed
- which means that results can't be compared between different
versions of the test
- recommendations for diagnostic messages:
- reason for failure
- reason for skip
- diagnostic data should always preceding the result line
- problem: harness may emit result before test can do assessment
to determine reason for result
- this is what the kernel uses
Differences between kernel test result format and TAP13:
- in KTAP the "# SKIP" directive is placed after the description on
the test result line
====== start of ktap-doc-rfc.txt ======
OK - that's the end of the RFC doc.
Here are a few questions:
- is this document desired or not?
- is it too long or too short?
- if the document is desired, where should it be placed?
I assume somewhere under Documentation, and put into
.rst format. Suggestions for a name and location are welcome.
- is this document accurate?
I think KUNIT does a few things differently than this description.
- is the intent to have kunit and kselftest have the same output format?
if so, then these should be rationalized.
Finally,
- Should a SKIP result be 'ok' (TAP13 spec) or 'not ok' (current kselftest practice)?
See https://testanything.org/tap-version-13-specification.html
Regards,
-- Tim
These patches apply to linux-5.8.0-rc1. Patches 1-3 should probably go
into 5.8, the others can be queued for 5.9. Patches 4-6 improve the HMM
self tests. Patch 7-8 prepare nouveau for the meat of this series which
adds support and testing for compound page mapping of system memory
(patches 9-11) and compound page migration to device private memory
(patches 12-16). Since these changes are split across mm core, nouveau,
and testing, I'm guessing Jason Gunthorpe's HMM tree would be appropriate.
Ralph Campbell (16):
mm: fix migrate_vma_setup() src_owner and normal pages
nouveau: fix migrate page regression
nouveau: fix mixed normal and device private page migration
mm/hmm: fix test timeout on slower machines
mm/hmm/test: remove redundant page table invalidate
mm/hmm: test mixed normal and device private migrations
nouveau: make nvkm_vmm_ctor() and nvkm_mmu_ptp_get() static
nouveau/hmm: fault one page at a time
mm/hmm: add output flag for compound page mapping
nouveau/hmm: support mapping large sysmem pages
hmm: add tests for HMM_PFN_COMPOUND flag
mm/hmm: optimize migrate_vma_setup() for holes
mm: support THP migration to device private memory
mm/thp: add THP allocation helper
mm/hmm/test: add self tests for THP migration
nouveau: support THP migration to private memory
drivers/gpu/drm/nouveau/nouveau_dmem.c | 177 +++++---
drivers/gpu/drm/nouveau/nouveau_svm.c | 241 +++++------
drivers/gpu/drm/nouveau/nouveau_svm.h | 3 +-
.../gpu/drm/nouveau/nvkm/subdev/mmu/base.c | 6 +-
.../gpu/drm/nouveau/nvkm/subdev/mmu/priv.h | 2 +
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 10 +-
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.h | 3 -
.../drm/nouveau/nvkm/subdev/mmu/vmmgp100.c | 29 +-
include/linux/gfp.h | 10 +
include/linux/hmm.h | 4 +-
include/linux/migrate.h | 1 +
include/linux/mm.h | 1 +
lib/test_hmm.c | 359 ++++++++++++----
lib/test_hmm_uapi.h | 2 +
mm/hmm.c | 10 +-
mm/huge_memory.c | 46 ++-
mm/internal.h | 1 -
mm/memory.c | 10 +-
mm/memremap.c | 9 +-
mm/migrate.c | 236 +++++++++--
mm/page_alloc.c | 1 +
tools/testing/selftests/vm/hmm-tests.c | 388 +++++++++++++++++-
22 files changed, 1203 insertions(+), 346 deletions(-)
--
2.20.1
On 6/20/20 9:37 PM, akpm(a)linux-foundation.org wrote:
> The mm-of-the-moment snapshot 2020-06-20-21-36 has been uploaded to
>
> http://www.ozlabs.org/~akpm/mmotm/
>
> mmotm-readme.txt says
>
> README for mm-of-the-moment:
>
> http://www.ozlabs.org/~akpm/mmotm/
>
> This is a snapshot of my -mm patch queue. Uploaded at random hopefully
> more than once a week.
drivers/misc/lkdtm/bugs.c has build errors when building UML for i386
(allmodconfig or allyesconfig):
In file included from ../drivers/misc/lkdtm/bugs.c:17:0:
../arch/x86/um/asm/desc.h:7:0: warning: "LDT_empty" redefined
#define LDT_empty(info) (\
In file included from ../arch/um/include/asm/mmu.h:10:0,
from ../include/linux/mm_types.h:18,
from ../include/linux/sched/signal.h:13,
from ../drivers/misc/lkdtm/bugs.c:11:
../arch/x86/um/asm/mm_context.h:65:0: note: this is the location of the previous definition
#define LDT_empty(info) (_LDT_empty(info))
../drivers/misc/lkdtm/bugs.c: In function ‘lkdtm_DOUBLE_FAULT’:
../drivers/misc/lkdtm/bugs.c:428:9: error: variable ‘d’ has initializer but incomplete type
struct desc_struct d = {
^~~~~~~~~~~
../drivers/misc/lkdtm/bugs.c:429:4: error: ‘struct desc_struct’ has no member named ‘type’
.type = 3, /* expand-up, writable, accessed data */
^~~~
../drivers/misc/lkdtm/bugs.c:429:11: warning: excess elements in struct initializer
.type = 3, /* expand-up, writable, accessed data */
^
../drivers/misc/lkdtm/bugs.c:429:11: note: (near initialization for ‘d’)
../drivers/misc/lkdtm/bugs.c:430:4: error: ‘struct desc_struct’ has no member named ‘p’
.p = 1, /* present */
^
../drivers/misc/lkdtm/bugs.c:430:8: warning: excess elements in struct initializer
.p = 1, /* present */
^
../drivers/misc/lkdtm/bugs.c:430:8: note: (near initialization for ‘d’)
../drivers/misc/lkdtm/bugs.c:431:4: error: ‘struct desc_struct’ has no member named ‘d’
.d = 1, /* 32-bit */
^
../drivers/misc/lkdtm/bugs.c:431:8: warning: excess elements in struct initializer
.d = 1, /* 32-bit */
^
../drivers/misc/lkdtm/bugs.c:431:8: note: (near initialization for ‘d’)
../drivers/misc/lkdtm/bugs.c:432:4: error: ‘struct desc_struct’ has no member named ‘g’
.g = 0, /* limit in bytes */
^
../drivers/misc/lkdtm/bugs.c:432:8: warning: excess elements in struct initializer
.g = 0, /* limit in bytes */
^
../drivers/misc/lkdtm/bugs.c:432:8: note: (near initialization for ‘d’)
../drivers/misc/lkdtm/bugs.c:433:4: error: ‘struct desc_struct’ has no member named ‘s’
.s = 1, /* not system */
^
../drivers/misc/lkdtm/bugs.c:433:8: warning: excess elements in struct initializer
.s = 1, /* not system */
^
../drivers/misc/lkdtm/bugs.c:433:8: note: (near initialization for ‘d’)
../drivers/misc/lkdtm/bugs.c:428:21: error: storage size of ‘d’ isn’t known
struct desc_struct d = {
^
../drivers/misc/lkdtm/bugs.c:437:2: error: implicit declaration of function ‘write_gdt_entry’; did you mean ‘init_wait_entry’? [-Werror=implicit-function-declaration]
write_gdt_entry(get_cpu_gdt_rw(smp_processor_id()),
^~~~~~~~~~~~~~~
init_wait_entry
../drivers/misc/lkdtm/bugs.c:437:18: error: implicit declaration of function ‘get_cpu_gdt_rw’; did you mean ‘get_cpu_ptr’? [-Werror=implicit-function-declaration]
write_gdt_entry(get_cpu_gdt_rw(smp_processor_id()),
^~~~~~~~~~~~~~
get_cpu_ptr
../drivers/misc/lkdtm/bugs.c:438:27: error: ‘DESCTYPE_S’ undeclared (first use in this function)
GDT_ENTRY_TLS_MIN, &d, DESCTYPE_S);
^~~~~~~~~~
../drivers/misc/lkdtm/bugs.c:438:27: note: each undeclared identifier is reported only once for each function it appears in
../drivers/misc/lkdtm/bugs.c:428:21: warning: unused variable ‘d’ [-Wunused-variable]
struct desc_struct d = {
^
cc1: some warnings being treated as errors
--
~Randy
Reported-by: Randy Dunlap <rdunlap(a)infradead.org>
As discussed in [1], KUnit tests have hitherto not had a particularly
consistent naming scheme. This adds documentation outlining how tests
and test suites should be named, including how those names should be
used in Kconfig entries and filenames.
[1]:
https://lore.kernel.org/linux-kselftest/202006141005.BA19A9D3@keescook/t/#u
Signed-off-by: David Gow <davidgow(a)google.com>
---
This is a first draft of some naming guidelines for KUnit tests. Note
that I haven't edited it for spelling/grammar/style yet: I wanted to get
some feedback on the actual naming conventions first.
The issues which came most to the forefront while writing it were:
- Do we want to make subsystems a more explicit thing (make the KUnit
framework recognise them, make suites KTAP subtests of them, etc)
- I'm leaning towards no, mainly because it doesn't seem necessary,
and it makes the subsystem-with-only-one-suite case ugly.
- Do we want to support (or encourage) Kconfig options and/or modules at
the subsystem level rather than the suite level?
- This could be nice: it'd avoid the proliferation of a large number
of tiny config options and modules, and would encourage the test for
<module> to be <module>_kunit, without other stuff in-between.
- As test names are also function names, it may actually make sense to
decorate them with "test" or "kunit" or the like.
- If we're testing a function "foo", "test_foo" seems like as good a
name for the function as any. Sure, many cases may could have better
names like "foo_invalid_context" or something, but that won't make
sense for everything.
- Alternatively, do we split up the test name and the name of the
function implementing the test?
Thoughts?
Documentation/dev-tools/kunit/index.rst | 1 +
Documentation/dev-tools/kunit/style.rst | 139 ++++++++++++++++++++++++
2 files changed, 140 insertions(+)
create mode 100644 Documentation/dev-tools/kunit/style.rst
diff --git a/Documentation/dev-tools/kunit/index.rst b/Documentation/dev-tools/kunit/index.rst
index e93606ecfb01..117c88856fb3 100644
--- a/Documentation/dev-tools/kunit/index.rst
+++ b/Documentation/dev-tools/kunit/index.rst
@@ -11,6 +11,7 @@ KUnit - Unit Testing for the Linux Kernel
usage
kunit-tool
api/index
+ style
faq
What is KUnit?
diff --git a/Documentation/dev-tools/kunit/style.rst b/Documentation/dev-tools/kunit/style.rst
new file mode 100644
index 000000000000..9363b5607262
--- /dev/null
+++ b/Documentation/dev-tools/kunit/style.rst
@@ -0,0 +1,139 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+===========================
+Test Style and Nomenclature
+===========================
+
+Subsystems, Suites, and Tests
+=============================
+
+In order to make tests as easy to find as possible, they're grouped into suites
+and subsystems. A test suite is a group of tests which test a related area of
+the kernel, and a subsystem is a set of test suites which test different parts
+of the same kernel subsystem or driver.
+
+Subsystems
+----------
+
+Every test suite must belong to a subsystem. A subsystem is a collection of one
+or more KUnit test suites which test the same driver or part of the kernel. A
+rule of thumb is that a test subsystem should match a single kernel module. If
+the code being tested can't be compiled as a module, in many cases the subsystem
+should correspond to a directory in the source tree or an entry in the
+MAINTAINERS file. If unsure, follow the conventions set by tests in similar
+areas.
+
+Test subsystems should be named after the code being tested, either after the
+module (wherever possible), or after the directory or files being tested. Test
+subsystems should be named to avoid ambiguity where necessary.
+
+If a test subsystem name has multiple components, they should be separated by
+underscores. Do not include "test" or "kunit" directly in the subsystem name
+unless you are actually testing other tests or the kunit framework itself.
+
+Example subsystems could be:
+
+* ``ext4``
+* ``apparmor``
+* ``kasan``
+
+.. note::
+ The KUnit API and tools do not explicitly know about subsystems. They're
+ simply a way of categorising test suites and naming modules which
+ provides a simple, consistent way for humans to find and run tests. This
+ may change in the future, though.
+
+Suites
+------
+
+KUnit tests are grouped into test suites, which cover a specific area of
+functionality being tested. Test suites can have shared initialisation and
+shutdown code which is run for all tests in the suite.
+Not all subsystems will need to be split into multiple test suites (e.g. simple drivers).
+
+Test suites are named after the subsystem they are part of. If a subsystem
+contains several suites, the specific area under test should be appended to the
+subsystem name, separated by an underscore.
+
+The full test suite name (including the subsystem name) should be specified as
+the ``.name`` member of the ``kunit_suite`` struct, and forms the base for the
+module name (see below).
+
+Example test suites could include:
+
+* ``ext4_inode``
+* ``kunit_try_catch``
+* ``apparmor_property_entry``
+* ``kasan``
+
+Tests
+-----
+
+Individual tests consist of a single function which tests a constrained
+codepath, property, or function. In the test output, individual tests' results
+will show up as subtests of the suite's results.
+
+Tests should be named after what they're testing. This is often the name of the
+function being tested, with a description of the input or codepath being tested.
+As tests are C functions, they should be named and written in accordance with
+the kernel coding style.
+
+.. note::
+ As tests are themselves functions, their names cannot conflict with
+ other C identifiers in the kernel. This may require some creative
+ naming. It's a good idea to make your test functions `static` to avoid
+ polluting the global namespace.
+
+Should it be necessary to refer to a test outside the context of its test suite,
+the *fully-qualified* name of a test should be the suite name followed by the
+test name, separated by a colon (i.e. ``suite:test``).
+
+Test Kconfig Entries
+====================
+
+Every test suite should be tied to a Kconfig entry.
+
+This Kconfig entry must:
+
+* be named ``CONFIG_<name>_KUNIT_TEST``: where <name> is the name of the test
+ suite.
+* be listed either alongside the config entries for the driver/subsystem being
+ tested, or be under [Kernel Hacking]→[Kernel Testing and Coverage]
+* depend on ``CONFIG_KUNIT``
+* be visible only if ``CONFIG_KUNIT_ALL_TESTS`` is not enabled.
+* have a default value of ``CONFIG_KUNIT_ALL_TESTS``.
+* have a brief description of KUnit in the help text
+* include "If unsure, say N" in the help text
+
+Unless there's a specific reason not to (e.g. the test is unable to be built as
+a module), Kconfig entries for tests should be tristate.
+
+An example Kconfig entry:
+
+.. code-block:: none
+
+ config FOO_KUNIT_TEST
+ tristate "KUnit test for foo" if !KUNIT_ALL_TESTS
+ depends on KUNIT
+ default KUNIT_ALL_TESTS
+ help
+ This builds unit tests for foo.
+
+ For more information on KUnit and unit tests in general, please refer
+ to the KUnit documentation in Documentation/dev-tools/kunit
+
+ If unsure, say N
+
+
+Test Filenames
+==============
+
+Where possible, test suites should be placed in a separate source file in the
+same directory as the code being tested.
+
+This file should be named ``<suite>_kunit.c``. It may make sense to strip
+excessive namespacing from the source filename (e.g., ``firmware_kunit.c`` instead of
+``<drivername>_firmware.c``), but please ensure the module name does contain the
+full suite name.
+
+
--
2.27.0.111.gc72c7da667-goog
The reverted commit illegitly uses tpm2-tools. External dependencies are
absolutely forbidden from these tests. There is also the problem that
clearing is not necessarily wanted behavior if the test/target computer is
not used only solely for testing.
Fixes: a9920d3bad40 ("tpm: selftest: cleanup after unseal with wrong auth/policy test")
Cc: Tadeusz Struk <tadeusz.struk(a)intel.com>
Cc: stable(a)vger.kernel.org
Cc: linux-integrity(a)vger.kernel.org
Cc: linux-kselftest(a)vger.kernel.org
Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen(a)linux.intel.com>
---
tools/testing/selftests/tpm2/test_smoke.sh | 5 -----
1 file changed, 5 deletions(-)
diff --git a/tools/testing/selftests/tpm2/test_smoke.sh b/tools/testing/selftests/tpm2/test_smoke.sh
index 663062701d5a..79f8e9da5d21 100755
--- a/tools/testing/selftests/tpm2/test_smoke.sh
+++ b/tools/testing/selftests/tpm2/test_smoke.sh
@@ -8,8 +8,3 @@ ksft_skip=4
python -m unittest -v tpm2_tests.SmokeTest
python -m unittest -v tpm2_tests.AsyncTest
-
-CLEAR_CMD=$(which tpm2_clear)
-if [ -n $CLEAR_CMD ]; then
- tpm2_clear -T device
-fi
--
2.25.1
This patch set adds the new "strict mode" functionality to the Virtual
Routing and Forwarding infrastructure (VRF). Hereafter we discuss the
requirements and the main features of the "strict mode" for VRF.
On VRF creation, it is necessary to specify the associated routing table used
during the lookup operations. Currently, there is no mechanism that avoids
creating multiple VRFs sharing the same routing table. In other words, it is not
possible to force a one-to-one relationship between a specific VRF and the table
associated with it.
The "strict mode" imposes that each VRF can be associated to a routing table
only if such routing table is not already in use by any other VRF.
In particular, the strict mode ensures that:
1) given a specific routing table, the VRF (if exists) is uniquely identified;
2) given a specific VRF, the related table is not shared with any other VRF.
Constraints (1) and (2) force a one-to-one relationship between each VRF and the
corresponding routing table.
The strict mode feature is designed to be network-namespace aware and it can be
directly enabled/disabled acting on the "strict_mode" parameter.
Read and write operations are carried out through the classic sysctl command on
net.vrf.strict_mode path, i.e: sysctl -w net.vrf.strict_mode=1.
Only two distinct values {0,1} are accepted by the strict_mode parameter:
- with strict_mode=0, multiple VRFs can be associated with the same table.
This is the (legacy) default kernel behavior, the same that we experience
when the strict mode patch set is not applied;
- with strict_mode=1, the one-to-one relationship between the VRFs and the
associated tables is guaranteed. In this configuration, the creation of a VRF
which refers to a routing table already associated with another VRF fails and
the error is returned to the user.
The kernel keeps track of the associations between a VRF and the routing table
during the VRF setup, in the "management" plane. Therefore, the strict mode does
not impact the performance or the intrinsic functionality of the data plane in
any way.
When the strict mode is active it is always possible to disable the strict mode,
while the reverse operation is not always allowed.
Setting the strict_mode parameter to 0 is equivalent to removing the one-to-one
constraint between any single VRF and its associated routing table.
Conversely, if the strict mode is disabled and there are multiple VRFs that
refer to the same routing table, then it is prohibited to set the strict_mode
parameter to 1. In this configuration, any attempt to perform the operation will
lead to an error and it will be reported to the user.
To enable strict mode once again (by setting the strict_mode parameter to 1),
you must first remove all the VRFs that share common tables.
There are several use cases which can take advantage from the introduction of
the strict mode feature. In particular, the strict mode allows us to:
i) guarantee the proper functioning of some applications which deal with
routing protocols;
ii) perform some tunneling decap operations which require to use specific
routing tables for segregating and forwarding the traffic.
Considering (i), the creation of different VRFs that point to the same table
leads to the situation where two different routing entities believe they have
exclusive access to the same table. This leads to the situation where different
routing daemons can conflict for gaining routes control due to overlapping
tables. By enabling strict mode it is possible to prevent this situation which
often occurs due to incorrect configurations done by the users.
The ability to enable/disable the strict mode functionality does not depend on
the tool used for configuring the networking. In essence, the strict mode patch
solves, at the kernel level, what some other patches [1] had tried to solve at
the userspace level (using only iproute2) with all the related problems.
Considering (ii), the introduction of the strict mode functionality allows us
implementing the SRv6 End.DT4 behavior. Such behavior terminates a SR tunnel and
it forwards the IPv4 traffic according to the routes present in the routing
table supplied during the configuration. The SRv6 End.DT4 can be realized
exploiting the routing capabilities made available by the VRF infrastructure.
This behavior could leverage a specific VRF for forcing the traffic to be
forwarded in accordance with the routes available in the VRF table.
Anyway, in order to make the End.DT4 properly work, it must be guaranteed that
the table used for the route lookup operations is bound to one and only one VRF.
In this way, it is possible to use the table for uniquely retrieving the
associated VRF and for routing packets.
I would like to thank David Ahern for his constant and valuable support during
the design and development phases of this patch set.
Comments, suggestions and improvements are very welcome!
Thanks,
Andrea Mayer
v1
l3mdev: add infrastructure for table to VRF mapping
- define l3mdev_lock as static, thanks to Jakub Kicinski;
- move lookup_by_table_id_t from l3mdev.c to l3mdev.h and update the
l3mdev_dev_table_lookup_{un}register functions accordingly, thanks to
David Ahern.
vrf: track associations between VRF devices and tables
- change shared_tables type from 'int' to 'u32', thanks to Stephen Hemminger
and David Ahern;
- update comments for share_tables.
vrf: add sysctl parameter for strict mode
- change type 'void __user *buffer' to 'void *buffer' in argument 3 of
vrf_shared_table_handler function, thanks to Jakub Kicinski.
[1] https://lore.kernel.org/netdev/20200307205916.15646-1-sharpd@cumulusnetwork…
Andrea Mayer (5):
l3mdev: add infrastructure for table to VRF mapping
vrf: track associations between VRF devices and tables
vrf: add sysctl parameter for strict mode
vrf: add l3mdev registration for table to VRF device lookup
selftests: add selftest for the VRF strict mode
drivers/net/vrf.c | 450 +++++++++++++++++-
include/net/l3mdev.h | 39 ++
net/l3mdev/l3mdev.c | 93 ++++
.../selftests/net/vrf_strict_mode_test.sh | 390 +++++++++++++++
4 files changed, 963 insertions(+), 9 deletions(-)
create mode 100755 tools/testing/selftests/net/vrf_strict_mode_test.sh
--
2.20.1
Hi Linus,
Please pull the Kunit update for Linux 5.8-rc12.
This Kunit update for Linux 5.8-rc2 consists of:
- Adds a generic kunit_resource API extending it to support
resources that are passed in to kunit in addition kunit
allocated resources. In addition, KUnit resources are now
refcounted to avoid passed in resources being released while
in use by kunit.
- Add support for named resources.
diff is attached.
thanks,
-- Shuah
----------------------------------------------------------------
The following changes since commit b3a9e3b9622ae10064826dccb4f7a52bd88c7407:
Linux 5.8-rc1 (2020-06-14 12:45:04 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/shuah/linux-kselftest
tags/linux-kselftest-kunit-5.8-rc2
for you to fetch changes up to 7bf200b3a4ac10b1b0376c70b8c66ed39eae7cdd:
kunit: add support for named resources (2020-06-15 09:31:23 -0600)
----------------------------------------------------------------
linux-kselftest-kunit-5.8-rc2
This Kunit update for Linux 5.8-rc2 consists of:
- Adds a generic kunit_resource API extending it to support
resources that are passed in to kunit in addition kunit
allocated resources. In addition, KUnit resources are now
refcounted to avoid passed in resources being released while
in use by kunit.
- Add support for named resources.
----------------------------------------------------------------
Alan Maguire (2):
kunit: generalize kunit_resource API beyond allocated resources
kunit: add support for named resources
include/kunit/test.h | 210
+++++++++++++++++++++++++++++++++++++++-------
lib/kunit/kunit-test.c | 111 +++++++++++++++++++-----
lib/kunit/string-stream.c | 14 ++--
lib/kunit/test.c | 171 ++++++++++++++++++++++---------------
4 files changed, 380 insertions(+), 126 deletions(-)
----------------------------------------------------------------
Hi Petr,
Given the realization about kernel log timestamps and partial log
comparison with v2, I respun a final version dropping the dmesg --notime
patch, fixed any rebase conflicts, and added a comment per your
suggestion.
I copied all the ack and review tags from v2 since the patchset is
unchanged otherwise. Hopefully this v3 minimizes any maintainer
fiddling on your end.
I did iterate through the patches and verified that I could run each
multiple times without the dmesg comparison getting confused.
Thanks,
-- Joe
v3:
- when modifying the dmesg comparision to select only new messages in
patch 1, add a comment explaining the importance of timestamps to
accurately pick from where the log left off at start_test [pmladek]
- since Petr determined that the timestamps were in fact very important
to maintain for the dmesg / diff comparision, drop the patch which
added --notime to dmesg invocations [pmladek]
- update the comparision regex filter for 'livepatch:' now that it's
going to be prefixed by '[timestamp] ' and no longer at the start of
the buffer line. This part of the log comparison should now be
unmodified by the patchset.
Joe Lawrence (3):
selftests/livepatch: Don't clear dmesg when running tests
selftests/livepatch: refine dmesg 'taints' in dmesg comparison
selftests/livepatch: add test delimiter to dmesg
tools/testing/selftests/livepatch/README | 16 +++---
.../testing/selftests/livepatch/functions.sh | 37 ++++++++++++-
.../selftests/livepatch/test-callbacks.sh | 55 ++++---------------
.../selftests/livepatch/test-ftrace.sh | 4 +-
.../selftests/livepatch/test-livepatch.sh | 12 +---
.../selftests/livepatch/test-shadow-vars.sh | 4 +-
.../testing/selftests/livepatch/test-state.sh | 21 +++----
7 files changed, 68 insertions(+), 81 deletions(-)
--
2.21.3
Hello!
This is a bit of thread-merge between [1] and [2]. tl;dr: add a way for
a seccomp user_notif process manager to inject files into the managed
process in order to handle emulation of various fd-returning syscalls
across security boundaries. Containers folks and Chrome are in need
of the feature, and investigating this solution uncovered (and fixed)
implementation issues with existing file sending routines.
I intend to carry this in the seccomp tree, unless someone has objections.
:) Please review and test!
-Kees
[1] https://lore.kernel.org/lkml/20200603011044.7972-1-sargun@sargun.me/
[2] https://lore.kernel.org/lkml/20200610045214.1175600-1-keescook@chromium.org/
Kees Cook (9):
net/scm: Regularize compat handling of scm_detach_fds()
fs: Move __scm_install_fd() to __fd_install_received()
fs: Add fd_install_received() wrapper for __fd_install_received()
pidfd: Replace open-coded partial fd_install_received()
fs: Expand __fd_install_received() to accept fd
selftests/seccomp: Make kcmp() less required
selftests/seccomp: Rename user_trap_syscall() to user_notif_syscall()
seccomp: Switch addfd to Extensible Argument ioctl
seccomp: Fix ioctl number for SECCOMP_IOCTL_NOTIF_ID_VALID
Sargun Dhillon (2):
seccomp: Introduce addfd ioctl to seccomp user notifier
selftests/seccomp: Test SECCOMP_IOCTL_NOTIF_ADDFD
fs/file.c | 65 ++++
include/linux/file.h | 16 +
include/uapi/linux/seccomp.h | 25 +-
kernel/pid.c | 11 +-
kernel/seccomp.c | 181 ++++++++-
net/compat.c | 55 ++-
net/core/scm.c | 50 +--
tools/testing/selftests/seccomp/seccomp_bpf.c | 350 +++++++++++++++---
8 files changed, 618 insertions(+), 135 deletions(-)
--
2.25.1
Commit 8b59cd81dc5 ("kbuild: ensure full rebuild when the compiler
is updated") added the environment variable CC_VERSION_TEXT,
parse_from_string() doesn't expect a string in value field and this
causes the failure below:
[iha@bbking linux]$ tools/testing/kunit/kunit.py run --timeout=60
[00:20:12] Configuring KUnit Kernel ...
Generating .config ...
Traceback (most recent call last):
File "tools/testing/kunit/kunit.py", line 347, in <module>
main(sys.argv[1:])
File "tools/testing/kunit/kunit.py", line 257, in main
result = run_tests(linux, request)
File "tools/testing/kunit/kunit.py", line 134, in run_tests
config_result = config_tests(linux, config_request)
File "tools/testing/kunit/kunit.py", line 64, in config_tests
success = linux.build_reconfig(request.build_dir, request.make_options)
File "/home/iha/lkmp/linux/tools/testing/kunit/kunit_kernel.py", line 161, in build_reconfig
return self.build_config(build_dir, make_options)
File "/home/iha/lkmp/linux/tools/testing/kunit/kunit_kernel.py", line 145, in build_config
return self.validate_config(build_dir)
File "/home/iha/lkmp/linux/tools/testing/kunit/kunit_kernel.py", line 124, in validate_config
validated_kconfig.read_from_file(kconfig_path)
File "/home/iha/lkmp/linux/tools/testing/kunit/kunit_config.py", line 89, in read_from_file
self.parse_from_string(f.read())
File "/home/iha/lkmp/linux/tools/testing/kunit/kunit_config.py", line 85, in parse_from_string
raise KconfigParseError('Failed to parse: ' + line)
kunit_config.KconfigParseError: Failed to parse: CONFIG_CC_VERSION_TEXT="gcc (GCC) 10.1.1 20200507 (Red Hat 10.1.1-1)"
Signed-off-by: Vitor Massaru Iha <vitor(a)massaru.org>
---
v2:
- maintains CC_VERSION_TEXT in the .config file to ensure full rebuild
when the compiler is updated.
---
tools/testing/kunit/kunit_config.py | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/tools/testing/kunit/kunit_config.py b/tools/testing/kunit/kunit_config.py
index e75063d603b5..c407c7c6a2b0 100644
--- a/tools/testing/kunit/kunit_config.py
+++ b/tools/testing/kunit/kunit_config.py
@@ -81,6 +81,12 @@ class Kconfig(object):
if line[0] == '#':
continue
+
+ if 'CONFIG_CC_VERSION_TEXT' in line:
+ name, value = line.split('=')
+ entry = KconfigEntry(name, value)
+ self.add_entry(entry)
+ continue
else:
raise KconfigParseError('Failed to parse: ' + line)
base-commit: 7bf200b3a4ac10b1b0376c70b8c66ed39eae7cdd
--
2.26.2
When separating out different phases of running tests[1]
(build/exec/parse/etc), the format of the KunitResult tuple changed
(adding an elapsed_time variable). This is not populated during a build
failure, causing kunit.py to crash.
This fixes [1] to probably populate the result variable, causing a
failing build to be reported properly.
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?…
Signed-off-by: David Gow <davidgow(a)google.com>
---
tools/testing/kunit/kunit.py | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/tools/testing/kunit/kunit.py b/tools/testing/kunit/kunit.py
index 787b6d4ad716..f9b769f3437d 100755
--- a/tools/testing/kunit/kunit.py
+++ b/tools/testing/kunit/kunit.py
@@ -82,7 +82,9 @@ def build_tests(linux: kunit_kernel.LinuxSourceTree,
request.make_options)
build_end = time.time()
if not success:
- return KunitResult(KunitStatus.BUILD_FAILURE, 'could not build kernel')
+ return KunitResult(KunitStatus.BUILD_FAILURE,
+ 'could not build kernel',
+ build_end - build_start)
if not success:
return KunitResult(KunitStatus.BUILD_FAILURE,
'could not build kernel',
--
2.27.0.290.gba653c62da-goog