This series introduces the selftests/arm directory, which tests 32 and 64-bit
kernel compatibility with 32-bit ELFs running on the Aarch platform.
The need for this bucket of tests is that 32 bit applications built on legacy
ARM architecture must not break on the new Aarch64 platforms and the 64-bit
kernel. The kernel must emulate the data structures, system calls and the
registers according to Aarch32, when running a 32-bit process; this directory
fills that testing requirement.
One may find similarity between this directory and selftests/arm64; it is
advisable to refer to that since a lot has been copied from there itself.
The mm directory includes a test for checking 4GB limit of the virtual
address space of a process.
The signal directory contains two tests, following a common theme: mangle
with arm_cpsr, dumped by the kernel to user space while invoking the signal
handler; kernel must spot this illegal attempt and terminate the program by
SEGV.
The elf directory includes a test for checking the 32-bit status of the ELF.
The series has been tested on 6.9-rc5, on Aarch64 platform. Testing remains
to be done on Aaarch32.
Changes in v2:
- Formatting changes
- Add .gitignore files and config file
Dev Jain (4):
selftests/arm: Add mm test
selftests/arm: Add signal tests
selftests/arm: Add elf test
selftests: Add build infrastructure along with README
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/arm/Makefile | 57 ++++
tools/testing/selftests/arm/README | 31 +++
tools/testing/selftests/arm/config | 1 +
tools/testing/selftests/arm/elf/.gitignore | 2 +
tools/testing/selftests/arm/elf/Makefile | 6 +
tools/testing/selftests/arm/elf/parse_elf.c | 74 +++++
tools/testing/selftests/arm/mm/.gitignore | 2 +
tools/testing/selftests/arm/mm/Makefile | 6 +
tools/testing/selftests/arm/mm/compat_va.c | 92 +++++++
tools/testing/selftests/arm/signal/.gitignore | 3 +
tools/testing/selftests/arm/signal/Makefile | 30 ++
.../selftests/arm/signal/test_signals.c | 27 ++
.../selftests/arm/signal/test_signals.h | 74 +++++
.../selftests/arm/signal/test_signals_utils.c | 257 ++++++++++++++++++
.../selftests/arm/signal/test_signals_utils.h | 128 +++++++++
.../signal/testcases/mangle_cpsr_aif_bits.c | 33 +++
.../mangle_cpsr_invalid_compat_toggle.c | 29 ++
18 files changed, 853 insertions(+)
create mode 100644 tools/testing/selftests/arm/Makefile
create mode 100644 tools/testing/selftests/arm/README
create mode 100644 tools/testing/selftests/arm/config
create mode 100644 tools/testing/selftests/arm/elf/.gitignore
create mode 100644 tools/testing/selftests/arm/elf/Makefile
create mode 100644 tools/testing/selftests/arm/elf/parse_elf.c
create mode 100644 tools/testing/selftests/arm/mm/.gitignore
create mode 100644 tools/testing/selftests/arm/mm/Makefile
create mode 100644 tools/testing/selftests/arm/mm/compat_va.c
create mode 100644 tools/testing/selftests/arm/signal/.gitignore
create mode 100644 tools/testing/selftests/arm/signal/Makefile
create mode 100644 tools/testing/selftests/arm/signal/test_signals.c
create mode 100644 tools/testing/selftests/arm/signal/test_signals.h
create mode 100644 tools/testing/selftests/arm/signal/test_signals_utils.c
create mode 100644 tools/testing/selftests/arm/signal/test_signals_utils.h
create mode 100644 tools/testing/selftests/arm/signal/testcases/mangle_cpsr_aif_bits.c
create mode 100644 tools/testing/selftests/arm/signal/testcases/mangle_cpsr_invalid_compat_toggle.c
--
2.39.2
The NULL dereference tests in kunit_fault deliberately trigger a kernel
BUG(), and therefore print the associated stack trace, even when the
test passes. This is both annoying (as it bloats the test output), and
can confuse some test harnesses, which assume any BUG() is a failure.
Allow these tests to be specifically disabled (without disabling all
of KUnit's other tests), by placing them behind the
CONFIG_KUNIT_FAULT_TEST Kconfig option. This is enabled by default, but
can be set to 'n' to disable the test. An empty 'kunit_fault' suite is
left behind, which will automatically be marked 'skipped'.
As the fault tests already were disabled under UML (as they weren't
compatible with its fault handling), we can simply adapt those
conditions, and add a dependency on !UML for our new option.
Suggested-by: Guenter Roeck <linux(a)roeck-us.net>
Link: https://lore.kernel.org/all/928249cc-e027-4f7f-b43f-502f99a1ea63@roeck-us.n…
Fixes: 82b0beff3497 ("kunit: Add tests for fault")
Signed-off-by: David Gow <davidgow(a)google.com>
---
lib/kunit/Kconfig | 11 +++++++++++
lib/kunit/kunit-test.c | 8 ++++----
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/lib/kunit/Kconfig b/lib/kunit/Kconfig
index 68a6daec0aef..34d7242d526d 100644
--- a/lib/kunit/Kconfig
+++ b/lib/kunit/Kconfig
@@ -24,6 +24,17 @@ config KUNIT_DEBUGFS
test suite, which allow users to see results of the last test suite
run that occurred.
+config KUNIT_FAULT_TEST
+ bool "Enable KUnit tests which print BUG stacktraces"
+ depends on KUNIT_TEST
+ depends on !UML
+ default y
+ help
+ Enables fault handling tests for the KUnit framework. These tests may
+ trigger a kernel BUG(), and the associated stack trace, even when they
+ pass. If this conflicts with your test infrastrcture (or is confusing
+ or annoying), they can be disabled by setting this to N.
+
config KUNIT_TEST
tristate "KUnit test for KUnit" if !KUNIT_ALL_TESTS
default KUNIT_ALL_TESTS
diff --git a/lib/kunit/kunit-test.c b/lib/kunit/kunit-test.c
index 0fdca5fffaec..e3412e0ca399 100644
--- a/lib/kunit/kunit-test.c
+++ b/lib/kunit/kunit-test.c
@@ -109,7 +109,7 @@ static struct kunit_suite kunit_try_catch_test_suite = {
.test_cases = kunit_try_catch_test_cases,
};
-#ifndef CONFIG_UML
+#if IS_ENABLED(CONFIG_KUNIT_FAULT_TEST)
static void kunit_test_null_dereference(void *data)
{
@@ -136,12 +136,12 @@ static void kunit_test_fault_null_dereference(struct kunit *test)
KUNIT_EXPECT_TRUE(test, ctx->function_called);
}
-#endif /* !CONFIG_UML */
+#endif /* CONFIG_KUNIT_FAULT_TEST */
static struct kunit_case kunit_fault_test_cases[] = {
-#ifndef CONFIG_UML
+#if IS_ENABLED(CONFIG_KUNIT_FAULT_TEST)
KUNIT_CASE(kunit_test_fault_null_dereference),
-#endif /* !CONFIG_UML */
+#endif /* CONFIG_KUNIT_FAULT_TEST */
{}
};
--
2.44.0.769.g3c40516874-goog
I was writing a test for page pool which depended on qstats,
and got tired of having to filter dumps in user space.
Add support for dumping stats for a single netdev.
To get there we first need to add full support for extack
in dumps (and fix a dump error handling bug in YNL, sent
separately to the net tree).
Jakub Kicinski (4):
netdev: support dumping a single netdev in qstats
netlink: move extack writing helpers
netlink: support all extack types in dumps
selftests: drv-net: test dumping qstats per device
Documentation/netlink/specs/netdev.yaml | 1 +
net/core/netdev-genl-gen.c | 1 +
net/core/netdev-genl.c | 52 +++++--
net/netlink/af_netlink.c | 135 ++++++++++---------
tools/testing/selftests/drivers/net/stats.py | 62 ++++++++-
tools/testing/selftests/net/lib/py/ksft.py | 18 +++
6 files changed, 188 insertions(+), 81 deletions(-)
--
2.44.0
Hi,
I've been working with colleagues at Collabora to improve the testing
quality overall for kselftests since several months. We had identified
following key points to improve:
* Make non-TAP conformant tests, TAP conformant to catch the bugs/failures
in the CI and non-CI environment. Without clear success or failure message,
it is difficult and at times impossible to notice the bugs and which part
of the test or sub-test has failed.
* Add config fragment if it is already isn't present.
* Improve ancient tests to be robust. KernelCI helps a lot in finding
flakiness or non-robust pieces of code by building it in range of
configurations and running it on range of hardware.
As new KernelCI is in works, we are identifying which kselftest suites
could be most suitable to be enabled in the start to keep the noise to a
minimum. The criteria to enable a suite on KernelCI is:
* The test suite is TAP compliant
* The test suite passes in preliminary testing on x86_64 and ARM64 platforms
* The test suite builds fine with Clang in-addition to gcc
To facilitate transparency and track our progress, I am diligently
maintaining a spreadsheet [1] with detailed information about each suite's
status and requirements.
Furthermore, I have commenced exploration into KUnit testing, and initial
results are promising. I plan to delve deeper into KUnit testing and will
provide further updates in the coming days.
Your feedback, insights and collaboration on any aspect of these
initiatives would be highly valuable. We greatly appreciate your
collaboration and support as we continue to enhance the testing quality of
kselftests.
[1]
https://docs.google.com/spreadsheets/d/1XRCgxlY1b74aIOIXQ7qDR-62KTJmuV1ow9s…
--
BR,
Muhammad Usama Anjum
Log errors are the most widely used mechanism for reporting issues in
the kernel. When an error is logged using the device helpers, eg
dev_err(), it gets metadata attached that identifies the subsystem and
device where the message is coming from. This series makes use of that
metadata in a new test to report which devices logged errors.
The first two patches move a test and a helper script to keep things
organized before this new test is added in the third patch.
It is expected that there might be many false-positive error messages
throughout the drivers code which will be reported by this test. By
having this test in the first place and working through the results we
can address those occurrences by adjusting the loglevel of the messages
that turn out to not be real errors that require the user's attention.
It will also motivate additional error messages to be introduced in the
code to detect real errors where they turn out to be missing, since
it will be possible to detect said issues automatically.
As an example, below you can see the test result for
mt8192-asurada-spherion. The single standing issue has been investigated
and will be addressed in an EC firmware update [1]:
TAP version 13
1..1
power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5
power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5
power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5
power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5
power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5
power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5
power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5
power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5
power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5
power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5
power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5
power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5
power_supply sbs-8-000b: driver failed to report `model_name' property: -6
power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5
power_supply sbs-8-000b: driver failed to report `energy_full_design' property: -6
power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5
power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5
power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5
power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5
power_supply sbs-8-000b: driver failed to report `time_to_empty_now' property: -5
not ok 1 +power_supply:sbs-8-000b
Totals: pass:0 fail:1 xfail:0 xpass:0 skip:0 error:0
[1] https://lore.kernel.org/all/cf4d8131-4b63-4c7a-9f27-5a0847c656c4@notapiano
Signed-off-by: Nícolas F. R. A. Prado <nfraprado(a)collabora.com>
---
Nícolas F. R. A. Prado (3):
kselftest: devices: Move discoverable devices test to subdirectory
kselftest: Move ksft helper module to common directory
kselftest: devices: Add test to detect device error logs
tools/testing/selftests/Makefile | 4 +-
tools/testing/selftests/devices/Makefile | 4 -
.../testing/selftests/devices/error_logs/Makefile | 3 +
.../devices/error_logs/test_device_error_logs.py | 85 ++++++++++++++++++++++
tools/testing/selftests/devices/probe/Makefile | 4 +
.../{ => probe}/boards/Dell Inc.,XPS 13 9300.yaml | 0
.../{ => probe}/boards/google,spherion.yaml | 0
.../{ => probe}/test_discoverable_devices.py | 7 +-
.../selftests/{devices => kselftest}/ksft.py | 0
9 files changed, 101 insertions(+), 6 deletions(-)
---
base-commit: 7b4f2bc91c15fdcf948bb2d9741a9d7d54303f8d
change-id: 20240421-dev-err-log-selftest-28f5b8fc7cd0
Best regards,
--
Nícolas F. R. A. Prado <nfraprado(a)collabora.com>
There is a 'malloc' call in config_name function, which can
be unsuccessful. This patch will add the malloc failure checking
to avoid possible null dereference and give more information
about test fail reasons.
Signed-off-by: Kunwu Chan <chentao(a)kylinos.cn>
---
tools/testing/selftests/kvm/get-reg-list.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/testing/selftests/kvm/get-reg-list.c b/tools/testing/selftests/kvm/get-reg-list.c
index 91f05f78e824..22398696ffd6 100644
--- a/tools/testing/selftests/kvm/get-reg-list.c
+++ b/tools/testing/selftests/kvm/get-reg-list.c
@@ -66,6 +66,7 @@ static const char *config_name(struct vcpu_reg_list *c)
len += strlen(s->name) + 1;
c->name = malloc(len);
+ TEST_ASSERT(c->name, "-ENOMEM when allocating config name");
len = 0;
for_each_sublist(c, s) {
--
2.40.1