Lines Matching +full:in +full:- +full:kernel
1 .. SPDX-License-Identifier: GPL-2.0
4 Kernel Testing Guide
8 There are a number of different tools for testing the Linux kernel, so knowing
16 The bulk of kernel tests are written using either the kselftest or KUnit
18 groups of tests easier, as well as providing helpers to aid in writing new
21 If you're looking to verify the behaviour of the Kernel — particularly specific
22 parts of the kernel — then you'll want to use KUnit or kselftest.
26 ------------------------------------------
28 KUnit (Documentation/dev-tools/kunit/index.rst) is an entirely in-kernel system
29 for "white box" testing: because test code is part of the kernel, it can access
32 KUnit tests therefore are best written against small, self-contained parts
33 of the kernel, which can be tested in isolation. This aligns well with the
36 For example, a KUnit test might test an individual kernel function (or even a
43 There is a KUnit test style guide which may give further pointers in
44 Documentation/dev-tools/kunit/style.rst
47 kselftest (Documentation/dev-tools/kselftest.rst), on the other hand, is
48 largely implemented in userspace, and tests are normal userspace scripts or
53 However, it's not possible to call kernel functions directly from kselftest.
54 This means that only kernel functionality which is exposed to userspace somehow
56 work around this, some tests include a companion kernel module which exposes
58 kernel, however, KUnit may be the more appropriate tool.
62 details. This aligns well with 'system' or 'end-to-end' testing.
69 The Linux Kernel supports two different code coverage measurement tools. These
71 of code. This is useful for determining how much of the kernel is being tested,
72 and for finding corner-cases which are not covered by the appropriate test.
74 Documentation/dev-tools/gcov.rst is GCC's coverage testing tool, which can be
75 used with the kernel to get global or per-module coverage. Unlike KCOV, it
76 does not record per-task coverage. Coverage data can be read from debugfs,
79 Documentation/dev-tools/kcov.rst is a feature which can be built in to the
80 kernel to allow capturing coverage on a per-task level. It's therefore useful
88 The kernel also supports a number of dynamic analysis tools, which attempt to
89 detect classes of issues when they occur in a running kernel. These typically
97 Documentation/dev-tools/kmemleak.rst
98 * KASAN detects invalid memory accesses such as out-of-bounds and
99 use-after-free errors. See Documentation/dev-tools/kasan.rst
101 overflows. See Documentation/dev-tools/ubsan.rst
102 * KCSAN detects data races. See Documentation/dev-tools/kcsan.rst
103 * KFENCE is a low-overhead detector of memory issues, which is much faster than
104 KASAN and can be used in production. See Documentation/dev-tools/kfence.rst
106 Documentation/locking/lockdep-design.rst
108 subsystem. See Documentation/trace/rv/runtime-verification.rst
109 * There are several other pieces of debug instrumentation in the kernel, many
110 of which can be found in lib/Kconfig.debug
112 These tools tend to test the kernel as a whole, and do not "pass" like
114 running tests on a kernel with these tools enabled: you can then be sure
123 In addition to testing a running kernel, one can also analyze kernel source code
125 commonly used in the kernel allow one to inspect the whole source tree or just
129 Sparse can help test the kernel by performing type-checking, lock checking,
130 value range checking, in addition to reporting various errors and warnings while
131 examining the code. See the Documentation/dev-tools/sparse.rst documentation
135 mistakes such as missing breaks in switch statements, unused return values on
136 error checking, forgetting to set an error code in the return of an error path,
143 to avoid certain bugs that occur in common code patterns. The types of tests
144 available include API tests, tests for correct usage of kernel iterators, checks
146 tests known to help keep consistent kernel usage. See the
147 Documentation/dev-tools/coccinelle.rst documentation page for details.
153 -----------------------------
164 It's generally easier to write checks in Smatch than it is to write checks in
168 --------------------------------------
171 pre-processor so it's easier to check for bugs in macros using Coccinelle.
181 Smatch. On the other hand, Coccinelle allows you to do simple things in a simple