Update to add clarity and recommendations on running newer kselftests
on older kernels vs. matching the kernel and kselftest revisions.
The recommendation is "Match kernel revision and kselftest."
Signed-off-by: Shuah Khan <skhan(a)linuxfoundation.org>
---
Documentation/dev-tools/kselftest.rst | 25 +++++++++++++++++++++++++
1 file changed, 25 insertions(+)
diff --git a/Documentation/dev-tools/kselftest.rst b/Documentation/dev-tools/kselftest.rst
index 25604904fa6e..e55d9229fa8c 100644
--- a/Documentation/dev-tools/kselftest.rst
+++ b/Documentation/dev-tools/kselftest.rst
@@ -12,6 +12,31 @@ write new tests using the framework on Kselftest wiki:
https://kselftest.wiki.kernel.org/
+Recommendations on running kselftests in Continuous Integration test rings
+=========================================================================
+
+It is recommended that users run Kselftest from the same release. Running
+newer Kselftest on older kernels isn't recommended for the following
+reasons:
+
+- Kselftest from mainline and linux-next might not be stable enough to run
+ on stable kernels.
+- Kselftests detect feature dependencies at run-time and skip tests if a
+ feature and/or configuration they test aren't enabled. Running newer
+ tests on older kernels could result in a few too many skipped/failed
+ conditions. It becomes difficult to evaluate the results.
+- Newer tests provide better coverage. However, users should make a judgement
+ call on coverage vs. run to run consistency and being able to compare
+ run to run results on older kernels.
+
+Recommendations:
+
+Match kernel revision and kselftest. Especially important for LTS and
+Stable kernel Continuous Integration test rings.
+
+Hot-plug tests
+==============
+
On some systems, hot-plug tests could hang forever waiting for cpu and
memory to be ready to be offlined. A special hot-plug target is created
to run the full range of hot-plug tests. In default mode, hot-plug tests run
--
2.20.1
## TL;DR
This revision addresses comments from Shuah by fixing a couple
checkpatch warnings and fixing some comment readability issues. No API
or major structual changes have been made since v13.
## 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[1]) 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[2].
Additionally for convenience, I have applied these patches to a
branch[3]. The repo may be cloned with:
git clone https://kunit.googlesource.com/linux
This patchset is on the kunit/rfc/v5.3/v15 branch.
## Changes Since Last Version
- Moved comment from inline in macro to kernel-doc to address checkpatch
warning.
- Demoted BUG() to WARN_ON.
- Formatted some kernel-doc comments to make them more readible.
[1] https://google.github.io/kunit-docs/third_party/kernel/docs/usage.html#kuni…
[2] https://google.github.io/kunit-docs/third_party/kernel/docs/
[3] https://kunit.googlesource.com/linux/+/kunit/rfc/v5.3/v15
--
2.23.0.187.g17f5b7556c-goog
This patch series adds kernel selftest of request_firmware_into_buf.
The API was added to the kernel previously untested.
Also included in this patch series is a fix for a race condition
discovered while testing request_firmware_into_buf. Mutex may
not be correct final solution but demonstrates a fix to a race
condition new test exposes.
Scott Branden (3):
test_firmware: add support for request_firmware_into_buf
selftest: firmware: Add request_firmware_into_buf tests
firmware: add mutex fw_lock_fallback for race condition
drivers/base/firmware_loader/main.c | 15 +++++
lib/test_firmware.c | 50 +++++++++++++++-
.../selftests/firmware/fw_filesystem.sh | 57 ++++++++++++++++++-
tools/testing/selftests/firmware/fw_lib.sh | 11 ++++
4 files changed, 129 insertions(+), 4 deletions(-)
--
2.17.1
## TL;DR
This revision addresses comments from Shuah by removing two macros that
were causing checkpatch errors. No API or major structual changes have
been made since v13.
## 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[1]) 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[2].
Additionally for convenience, I have applied these patches to a
branch[3]. The repo may be cloned with:
git clone https://kunit.googlesource.com/linux
This patchset is on the kunit/rfc/v5.3/v14 branch.
## Changes Since Last Version
- Removed to macros which helped define expectation and assertion
macros; these values are now just copied and pasted. Change was made
to fix checkpatch error, as suggested by Shuah.
[1] https://google.github.io/kunit-docs/third_party/kernel/docs/usage.html#kuni…
[2] https://google.github.io/kunit-docs/third_party/kernel/docs/
[3] https://kunit.googlesource.com/linux/+/kunit/rfc/v5.3/v14
--
2.23.0.rc1.153.gdeed80330f-goog
Hi everyone,
Firstly, apologies to anyone on the long cc list that turns out not to be particularly interested in the following, but
you were all marked as cc'd in the commit message below.
I've found a problem that isn't present in 5.2 series or 4.19 series kernels, and seems to have arrived in 5.3-rc1. The
problem is that if I suspend (to ram) my laptop, on resume 14 minutes or more after suspending, I have no networking
functionality. If I resume the laptop after 13 minutes or less, networking works fine. I haven't tried to get finer
grained timings between 13 and 14 minutes, but can do if it would help.
ifconfig shows that wlan0 is still up and still has its assigned ip address but, for instance, a ping of any other
device on my network, fails as does pinging, say, kernel.org. I've tried "downing" the network with (/sbin/ifdown) and
unloading the iwlmvm module and then reloading the module and "upping" (/sbin/ifup) the network, but my network is still
unusable. I should add that the problem also manifests if I hibernate the laptop, although my testing of this has been
minimal. I can do more if required.
As I say, the problem first appears in 5.3-rc1, so I've bisected between 5.2.0 and 5.3-rc1 and that concluded with:
[chris:~/kernel/linux]$ git bisect good
7ac8707479886c75f353bfb6a8273f423cfccb23 is the first bad commit
commit 7ac8707479886c75f353bfb6a8273f423cfccb23
Author: Vincenzo Frascino <vincenzo.frascino(a)arm.com>
Date: Fri Jun 21 10:52:49 2019 +0100
x86/vdso: Switch to generic vDSO implementation
The x86 vDSO library requires some adaptations to take advantage of the
newly introduced generic vDSO library.
Introduce the following changes:
- Modification of vdso.c to be compliant with the common vdso datapage
- Use of lib/vdso for gettimeofday
[ tglx: Massaged changelog and cleaned up the function signature formatting ]
Signed-off-by: Vincenzo Frascino <vincenzo.frascino(a)arm.com>
Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de>
Cc: linux-arch(a)vger.kernel.org
Cc: linux-arm-kernel(a)lists.infradead.org
Cc: linux-mips(a)vger.kernel.org
Cc: linux-kselftest(a)vger.kernel.org
Cc: Catalin Marinas <catalin.marinas(a)arm.com>
Cc: Will Deacon <will.deacon(a)arm.com>
Cc: Arnd Bergmann <arnd(a)arndb.de>
Cc: Russell King <linux(a)armlinux.org.uk>
Cc: Ralf Baechle <ralf(a)linux-mips.org>
Cc: Paul Burton <paul.burton(a)mips.com>
Cc: Daniel Lezcano <daniel.lezcano(a)linaro.org>
Cc: Mark Salyzyn <salyzyn(a)android.com>
Cc: Peter Collingbourne <pcc(a)google.com>
Cc: Shuah Khan <shuah(a)kernel.org>
Cc: Dmitry Safonov <0x7f454c46(a)gmail.com>
Cc: Rasmus Villemoes <linux(a)rasmusvillemoes.dk>
Cc: Huw Davies <huw(a)codeweavers.com>
Cc: Shijith Thotton <sthotton(a)marvell.com>
Cc: Andre Przywara <andre.przywara(a)arm.com>
Link: https://lkml.kernel.org/r/20190621095252.32307-23-vincenzo.frascino@arm.com
arch/x86/Kconfig | 3 +
arch/x86/entry/vdso/Makefile | 9 ++
arch/x86/entry/vdso/vclock_gettime.c | 245 ++++---------------------------
arch/x86/entry/vdso/vdsox32.lds.S | 1 +
arch/x86/entry/vsyscall/Makefile | 2 -
arch/x86/entry/vsyscall/vsyscall_gtod.c | 83 -----------
arch/x86/include/asm/pvclock.h | 2 +-
arch/x86/include/asm/vdso/gettimeofday.h | 191 ++++++++++++++++++++++++
arch/x86/include/asm/vdso/vsyscall.h | 44 ++++++
arch/x86/include/asm/vgtod.h | 75 +---------
arch/x86/include/asm/vvar.h | 7 +-
arch/x86/kernel/pvclock.c | 1 +
12 files changed, 284 insertions(+), 379 deletions(-)
delete mode 100644 arch/x86/entry/vsyscall/vsyscall_gtod.c
create mode 100644 arch/x86/include/asm/vdso/gettimeofday.h
create mode 100644 arch/x86/include/asm/vdso/vsyscall.h
To confirm my bisection was correct, I did a git checkout of 7ac8707479886c75f353bfb6a8273f423cfccb2. As expected, the
kernel exhibited the problem I've described. However, a kernel built at the immediately preceding (parent?) commit
(bfe801ebe84f42b4666d3f0adde90f504d56e35b) has a working network after a (>= 14minute) suspend/resume cycle.
As the module name implies, I'm using wireless networking. The hardware is detected as "Intel(R) Wireless-AC 9260
160MHz, REV=0x324" by iwlwifi.
I'm more than happy to provide additional diagnostics (but may need a little hand-holding) and to apply diagnostic or
fix patches, but please cc me on any reply as I'm not subscribed to any of the kernel-related mailing lists.
Chris
This patch series adds kernel selftest of request_firmware_into_buf.
The API was added to the kernel previously untested.
Changes from v1:
- Dropped demonstration patch for a race condition discovered
while testing request_firmare_into_buf.
The new test exposes a kernel opps with the firmware fallback mechanism that may
be fixed separate from these tests.
- minor whitespace formatting in patch
- added Ack's
- added "s" in commit message (changed selftest: to selftests:)
Scott Branden (2):
test_firmware: add support for request_firmware_into_buf
selftests: firmware: Add request_firmware_into_buf tests
lib/test_firmware.c | 50 +++++++++++++++-
.../selftests/firmware/fw_filesystem.sh | 57 ++++++++++++++++++-
tools/testing/selftests/firmware/fw_lib.sh | 11 ++++
3 files changed, 114 insertions(+), 4 deletions(-)
--
2.17.1
When running xfrm_policy.sh we see the following
# sysctl cannot stat /proc/sys/net/ipv4/conf/eth1/forwarding No such file or directory
cannot: stat_/proc/sys/net/ipv4/conf/eth1/forwarding #
# sysctl cannot stat /proc/sys/net/ipv4/conf/veth0/forwarding No such file or directory
cannot: stat_/proc/sys/net/ipv4/conf/veth0/forwarding #
# sysctl cannot stat /proc/sys/net/ipv4/conf/eth1/forwarding No such file or directory
cannot: stat_/proc/sys/net/ipv4/conf/eth1/forwarding #
# sysctl cannot stat /proc/sys/net/ipv4/conf/veth0/forwarding No such file or directory
cannot: stat_/proc/sys/net/ipv4/conf/veth0/forwarding #
# sysctl cannot stat /proc/sys/net/ipv6/conf/eth1/forwarding No such file or directory
cannot: stat_/proc/sys/net/ipv6/conf/eth1/forwarding #
# sysctl cannot stat /proc/sys/net/ipv6/conf/veth0/forwarding No such file or directory
cannot: stat_/proc/sys/net/ipv6/conf/veth0/forwarding #
# sysctl cannot stat /proc/sys/net/ipv6/conf/eth1/forwarding No such file or directory
cannot: stat_/proc/sys/net/ipv6/conf/eth1/forwarding #
# sysctl cannot stat /proc/sys/net/ipv6/conf/veth0/forwarding No such file or directory
cannot: stat_/proc/sys/net/ipv6/conf/veth0/forwarding #
# modprobe FATAL Module ip_tables not found in directory /lib/modules/5.3.0-rc5-next-20190820+
FATAL: Module_ip_tables #
# iptables v1.6.2 can't initialize iptables table `filter' Table does not exist (do you need to insmod?)
v1.6.2: can't_initialize #
Rework to enable CONFIG_NF_TABLES_NETDEV and CONFIG_NFT_FWD_NETDEV.
Signed-off-by: Anders Roxell <anders.roxell(a)linaro.org>
---
tools/testing/selftests/net/config | 2 ++
1 file changed, 2 insertions(+)
diff --git a/tools/testing/selftests/net/config b/tools/testing/selftests/net/config
index b8503a8119b0..e30b0ae5d474 100644
--- a/tools/testing/selftests/net/config
+++ b/tools/testing/selftests/net/config
@@ -29,3 +29,5 @@ CONFIG_NET_SCH_FQ=m
CONFIG_NET_SCH_ETF=m
CONFIG_TEST_BLACKHOLE_DEV=m
CONFIG_KALLSYMS=y
+CONFIG_NF_TABLES_NETDEV=y
+CONFIG_NFT_FWD_NETDEV=m
--
2.20.1