Documentation/fault-injection/provoke-crashes.rst
Source file repositories/reference/linux-study-clean/Documentation/fault-injection/provoke-crashes.rst
File Facts
- System
- Linux kernel
- Corpus path
Documentation/fault-injection/provoke-crashes.rst- Extension
.rst- Size
- 2391 bytes
- Lines
- 58
- Domain
- Support Tooling And Documentation
- Bucket
- Documentation
- Inferred role
- Support Tooling And Documentation: documentation
- Status
- atlas-only
Why This File Exists
Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
- Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.
Dependency Surface
- No C-style include directives detected by the generator.
Detected Declarations
- No top-level syscall, struct, function, initcall, or export declaration detected by the generator.
Annotated Snippet
.. SPDX-License-Identifier: GPL-2.0
============================================================
Provoking crashes with Linux Kernel Dump Test Module (LKDTM)
============================================================
The lkdtm module provides an interface to disrupt (and usually crash)
the kernel at predefined code locations to evaluate the reliability of
the kernel's exception handling and to test crash dumps obtained using
different dumping solutions. The module uses KPROBEs to instrument the
trigger location, but can also trigger the kernel directly without KPROBE
support via debugfs.
You can select the location of the trigger ("crash point name") and the
type of action ("crash point type") either through module arguments when
inserting the module, or through the debugfs interface.
Usage::
insmod lkdtm.ko [recur_count={>0}] cpoint_name=<> cpoint_type=<>
[cpoint_count={>0}]
recur_count
Recursion level for the stack overflow test. By default this is
dynamically calculated based on kernel configuration, with the
goal of being just large enough to exhaust the kernel stack. The
value can be seen at `/sys/module/lkdtm/parameters/recur_count`.
cpoint_name
Where in the kernel to trigger the action. It can be
one of INT_HARDWARE_ENTRY, INT_HW_IRQ_EN, INT_TASKLET_ENTRY,
FS_SUBMIT_BH, MEM_SWAPOUT, TIMERADD, SCSI_QUEUE_RQ, or DIRECT.
cpoint_type
Indicates the action to be taken on hitting the crash point.
These are numerous, and best queried directly from debugfs. Some
of the common ones are PANIC, BUG, EXCEPTION, LOOP, and OVERFLOW.
See the contents of `/sys/kernel/debug/provoke-crash/DIRECT` for
a complete list.
cpoint_count
Indicates the number of times the crash point is to be hit
before triggering the action. The default is 10 (except for
DIRECT, which always fires immediately).
You can also induce failures by mounting debugfs and writing the type to
<debugfs>/provoke-crash/<crashpoint>. E.g.::
mount -t debugfs debugfs /sys/kernel/debug
echo EXCEPTION > /sys/kernel/debug/provoke-crash/INT_HARDWARE_ENTRY
The special file `DIRECT` will induce the action directly without KPROBE
instrumentation. This mode is the only one available when the module is
built for a kernel without KPROBEs support::
# Instead of having a BUG kill your shell, have it kill "cat":
cat <(echo WRITE_RO) >/sys/kernel/debug/provoke-crash/DIRECT
Annotation
- Atlas domain: Support Tooling And Documentation / Documentation.
- Implementation status: atlas-only.
Implementation Notes
- This generated page is the file-by-file coverage layer; curated subsystem chapters should link here when they synthesize a multi-file control flow.
- Core OS pages should be promoted from atlas-only to deep-reviewed when they explain data structures, invariants, locking, lifecycle, and C implementation snippets.
- Driver-family pages are intentionally pattern-oriented unless they are part of the selected PCIe/NVMe representative device path.