Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/DeelerDev/linux/llms.txt

Use this file to discover all available pages before exploring further.

The Linux kernel ships with an extensive suite of tools for catching bugs before they reach users. These range from a simple style checker to sophisticated runtime sanitizers that can detect concurrency bugs and memory corruption. Using them systematically is expected of anyone submitting non-trivial patches. The tools fall into four broad categories: style checking, static analysis, dynamic analysis (sanitizers), and testing frameworks.

Style checking

Validate patch formatting before submission to avoid reviewer friction.

Static analysis

Analyze source code at compile time to catch type errors, locking issues, and common patterns.

Dynamic analysis

Detect memory errors, data races, and undefined behavior in a running kernel.

Testing frameworks

Write and run structured unit tests and system-level tests against the kernel.

​
Style checker

​
checkpatch.pl

scripts/checkpatch.pl checks patches (or source files) for violations of the kernel coding style. It reports three levels of messages: ERROR (very likely wrong), WARNING (requires careful review), and CHECK (requires thought, enabled with --strict). 
# Check a patch file
./scripts/checkpatch.pl mypatch.patch

# Check a source file
./scripts/checkpatch.pl -f drivers/mydriver/file.c

# Check a git commit range
./scripts/checkpatch.pl -g HEAD~3..HEAD

# Enable stricter CHECK-level tests
./scripts/checkpatch.pl --strict mypatch.patch
Checkpatch is a guide, not a substitute for judgment. If fixing a complaint makes the code less readable, leave it and justify the exception in your cover letter.

​
Static analysis tools

Static analysis tools examine source code at compile time without running it. They catch classes of bugs that the compiler itself does not warn about.

​
sparse

Sparse is the kernel’s primary static analysis tool. It performs type-checking that the C compiler cannot do, including:
  • Verifying that __user pointers are not dereferenced in kernel context
  • Detecting endianness mismatches (__be32 vs __le32)
  • Checking for misuse of __rcu-annotated pointers
  • Flagging lock annotation violations
Enable sparse by adding C=1 to your make invocation: 
make C=1 drivers/mydriver/
Use C=2 to check all files, not just those that were recompiled.

​
Coccinelle

Coccinelle (make coccicheck) applies semantic patches — scripts that describe patterns to find and fix — across the entire source tree. It is used for mass API migrations and for finding common programming mistakes. Unlike sparse or smatch, Coccinelle produces patch output directly, not just warnings. 
make coccicheck MODE=report
Coccinelle works before the preprocessor, which makes it particularly effective at catching bugs in macros.

​
Dynamic analysis tools

Dynamic analysis tools instrument the running kernel to detect errors as they occur. They are configured via Kconfig and must be enabled before building the test kernel.

​
KASAN — Kernel Address Sanitizer

KASAN detects out-of-bounds memory accesses and use-after-free errors. Enable it with CONFIG_KASAN=y. When a violation occurs, KASAN prints a detailed report including the stack trace, the accessed address, and the allocation/free history for that memory region. 
CONFIG_KASAN=y
CONFIG_KASAN_INLINE=y
KASAN has a performance overhead and is intended for development and testing kernels, not production.

​
KCSAN — Kernel Concurrency Sanitizer

KCSAN detects data races — concurrent accesses to the same memory location where at least one access is a write and there is no synchronization. Enable it with CONFIG_KCSAN=y. 
CONFIG_KCSAN=y
CONFIG_KCSAN_REPORT_ONCE_IN_MS=3000
KCSAN works by instrumenting memory accesses and using a watchpoint mechanism to catch unsynchronized concurrent access. It is especially useful when combined with KUnit or kselftest on SMP systems.
KCSAN reports are probabilistic — a data race that exists may not always be reported in a single run. Running tests multiple times or under stress conditions improves detection rate.

​
KFENCE — Kernel Electric Fence

KFENCE is a low-overhead sampling-based memory safety tool that can be enabled in production kernels. Unlike KASAN, it does not instrument every memory access; instead, it protects a random sample of allocations. This makes it suitable for catching use-after-free and out-of-bounds bugs in deployed systems. 
CONFIG_KFENCE=y

​
UBSAN — Undefined Behavior Sanitizer

UBSAN detects C undefined behavior at runtime, including integer overflows, out-of-bounds array accesses, and misaligned pointer dereferences. 
CONFIG_UBSAN=y

​
kmemleak

kmemleak scans the kernel’s memory allocations and reports objects that are allocated but never freed and no longer reachable. It is useful for tracking down memory leak bugs. 
CONFIG_DEBUG_KMEMLEAK=y
After booting, trigger a scan and read the results: 
echo scan > /sys/kernel/debug/kmemleak
cat /sys/kernel/debug/kmemleak

​
lockdep

lockdep is a locking correctness validator. It tracks every lock acquisition and release in the kernel and verifies that:
  • Locks are always acquired in the same order (to prevent deadlocks)
  • Interrupt safety assumptions are consistent across all paths
  • Lock classes are used correctly
Enable lockdep with CONFIG_PROVE_LOCKING=y. Any code with non-trivial locking should be tested with lockdep enabled before submission.

​
Testing frameworks

​
KUnit — Kernel Unit Testing Framework

KUnit is the kernel’s in-kernel unit testing framework. Tests are written in C, live inside the kernel, and have access to internal functions and structures that are not exposed to userspace. This makes it well-suited to “white box” testing of individual functions and code paths. KUnit tests run either at boot (built-in) or as loadable modules. Results are reported in KTAP format in the kernel log. The kunit.py script can run tests under QEMU or User Mode Linux and parse results automatically: 
./tools/testing/kunit/kunit.py run
A minimal KUnit test looks like: 
#include <kunit/test.h>

static void example_test_basic(struct kunit *test)
{
	KUNIT_EXPECT_EQ(test, 1 + 1, 2);
}

static struct kunit_case example_test_cases[] = {
	KUNIT_CASE(example_test_basic),
	{}
};

static struct kunit_suite example_test_suite = {
	.name = "example",
	.test_cases = example_test_cases,
};

kunit_test_suite(example_test_suite);
KUnit tests can run in under 10 seconds for around 100 test cases. Running them frequently during development catches regressions immediately. The testing-overview.rst document recommends KUnit for testing individual functions and code paths.

​
kselftest — Kernel Self Tests

kselftest provides a collection of userspace test scripts and programs under tools/testing/selftests/. Unlike KUnit, kselftest tests run in userspace and interact with the kernel through system calls, sysfs, procfs, and device files. This makes them suitable for testing whole-kernel features and their userspace interfaces. All new system calls should be accompanied by kselftest tests. 
# Build and run all selftests
make -C tools/testing/selftests/ run_tests

# Run a specific subsystem's tests
make -C tools/testing/selftests/net/ run_tests

​
Tracing and debugging tools

​
ftrace

ftrace is the kernel’s built-in function tracer. It can trace function calls, measure latency, and record events with minimal overhead. Access it through the tracefs filesystem: 
# Enable function tracing
echo function > /sys/kernel/tracing/current_tracer
cat /sys/kernel/tracing/trace
ftrace is the foundation for many higher-level tools including trace-cmd and kernelshark.

​
perf

perf provides hardware performance counter support and software event profiling. It can profile entire systems, individual processes, or specific kernel functions: 
perf stat make vmlinux
perf record -ag sleep 10
perf report

​
KGDB — Kernel Debugger

KGDB allows source-level debugging of the Linux kernel using gdb over a serial connection or network. Enable it with CONFIG_KGDB=y and connect a gdb instance to the target machine. KGDB is particularly useful for debugging early boot or interrupt handler code where printk-based debugging is impractical. For routine development, enabling the following Kconfig options is recommended: 
CONFIG_KASAN=y
CONFIG_PROVE_LOCKING=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_ATOMIC_SLEEP=y
CONFIG_DEBUG_OBJECTS=y
CONFIG_DEBUG_SLAB=y

CONFIG_FRAME_WARN=1024
CONFIG_UBSAN=y
Build with additional warnings enabled:
make KCFLAGS=-W
The fault injection framework can force memory allocations to fail at a configurable rate, helping you test error-handling paths that would otherwise never execute:
CONFIG_FAULT_INJECTION=y
CONFIG_FAILSLAB=y
CONFIG_FAULT_INJECTION_DEBUG_FS=y
Dynamic analysis tools (KASAN, KCSAN, UBSAN) have significant performance overhead and should not be enabled in production kernels. Use them in development and testing environments only.

Build docs developers (and LLMs) love

Get started for freeTalk to us