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.