Open-Source Wikis

/

Linux

/

How to contribute

/

Testing

torvalds/linux

Testing

The kernel has multiple, mostly orthogonal testing surfaces. Each catches different bugs. Most patches are expected to pass at least the build-test, sparse, and a relevant kselftest before posting.

Test surfaces

graph TD
    KS[kselftest<br/>tools/testing/selftests/] -->|exercises| KAPI[Syscall + uAPI behavior]
    KU[KUnit<br/>tools/testing/kunit/] -->|in-kernel| FN[Pure functions, data structures]
    SYZ[syzkaller] -->|fuzzing| KAPI
    KASAN[KASAN/UBSAN/KCSAN] -->|sanitizer| RT[Runtime memory + concurrency bugs]
    LKDTM[LKDTM<br/>drivers/misc/lkdtm/] -->|injects faults| HARDEN[Hardening features]
    PERF[perf bench] -->|microbenchmarks| HOTPATH[Scheduler, mm hot paths]

kselftest

Located at tools/testing/selftests/. User-space C and shell programs that drive kernel features and assert on results. Each subdirectory is a test suite (bpf, mm, net, kvm, cgroup, clone3, etc.).

Build and run in place:

make headers          # First time: install headers for selftests to compile against
make -C tools/testing/selftests
make -C tools/testing/selftests run_tests TARGETS=mm

Or build and install to a directory:

make -C tools/testing/selftests install INSTALL_PATH=/tmp/kst
/tmp/kst/run_kselftest.sh

Tests use the TAP (Test Anything Protocol) output format. The harness (kselftest.h / kselftest_harness.h) provides TEST(), EXPECT_EQ(), ASSERT_EQ(), etc.

KUnit

Located at tools/testing/kunit/. Runs real kernel code under UML or in a small VM and asserts on it.

Run KUnit:

./tools/testing/kunit/kunit.py run

Tests live next to the code they cover, named *_test.c or under */tests/. Examples:

Authoring a test (sketch):

#include <kunit/test.h>

static void my_test(struct kunit *test)
{
    KUNIT_EXPECT_EQ(test, 2 + 2, 4);
}

static struct kunit_case test_cases[] = {
    KUNIT_CASE(my_test),
    {}
};

static struct kunit_suite my_suite = {
    .name = "my_suite",
    .test_cases = test_cases,
};
kunit_test_suite(my_suite);

Build-time and static analysis

  • Sparsemake C=2 runs sparse over all files. Catches endianness, locking annotations (__must_hold), and many type errors.
  • Smatch — out-of-tree, but very effective. Catches NULL derefs, bad locking, mutex_lock returns ignored.
  • Coccinelle / SmPL — semantic patches. The kernel ships SmPL scripts under scripts/coccinelle/.
    make coccicheck MODE=report
  • W=1, W=2, W=3 — increasingly strict GCC warnings. Most subsystems target W=1 clean.

Runtime sanitizers

Enable in .config for sanitizer builds:

  • CONFIG_KASAN — Kernel Address Sanitizer. Detects use-after-free, OOB reads/writes.
  • CONFIG_UBSAN — Undefined Behavior Sanitizer.
  • CONFIG_KCSAN — Kernel Concurrency Sanitizer. Detects data races at runtime.
  • CONFIG_KMSAN — Kernel Memory Sanitizer (Clang only). Detects uses of uninitialized memory.
  • CONFIG_LOCKDEP — Locking validator. Detects circular lock dependencies, missing locks, IRQ-unsafe holds.
  • CONFIG_DEBUG_OBJECTS, CONFIG_DEBUG_LIST, CONFIG_DEBUG_VM — runtime invariants for common data structures.

Turn these on for development; turn most off for production.

Fuzzing

  • syzkaller — out-of-tree but the de facto kernel fuzzer. Runs against a syscall-coverage-aware harness and reproduces bugs into C programs. Many bug fixes carry Reported-by: syzbot+...@syzkaller.appspotmail.com.
  • trinity — older random syscall fuzzer. Less used today.
  • AFL/AFL++ — used for parsers (e.g. ELF, ext4 crash images, BPF programs).

Performance

  • tools/perf/ ships perf bench for microbenchmarks.
  • tools/testing/selftests/sched/ covers scheduler regressions.
  • The mmtests and phoronix-test-suite are the typical workload-style suites used out of tree.

CI

There is no single CI. Many companies run continuous testing infrastructure (KernelCI, Intel 0-day, Red Hat CKI, the Linaro tuxsuite/tuxmake setups, Google syzbot). All publish results to public mailing lists. Patches that break linux-next are noticed quickly because of these systems.

  • Tooling — running the static analyzers.
  • Debugging — what to do when a sanitizer fires.

Built by Factory AutoWiki from public repository content. It is a generated preview for codebase exploration, not source-maintained documentation.

Testing – Linux wiki | Factory