diff options
Diffstat (limited to 'lib/Kconfig.debug')
| -rw-r--r-- | lib/Kconfig.debug | 655 |
1 files changed, 344 insertions, 311 deletions
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug index 83a804d58e2f..ac0cf598a42b 100644 --- a/lib/Kconfig.debug +++ b/lib/Kconfig.debug @@ -173,6 +173,15 @@ config SYMBOLIC_ERRNAME of the number 28. It makes the kernel image slightly larger (about 3KB), but can make the kernel logs easier to read. +config DEBUG_BUGVERBOSE + bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT + depends on BUG && (GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE) + default y + help + Say Y here to make BUG() panics output the file name and line number + of the BUG call as well as the EIP and oops trace. This aids + debugging but costs about 70-100K of memory. + endmenu # "printk and dmesg options" menu "Compile-time checks and compiler options" @@ -286,18 +295,6 @@ config READABLE_ASM to keep kernel developers who have to stare a lot at assembler listings sane. -config DEBUG_FS - bool "Debug Filesystem" - help - debugfs is a virtual file system that kernel developers use to put - debugging files into. Enable this option to be able to read and - write to these files. - - For detailed documentation on the debugfs API, see - Documentation/filesystems/. - - If unsure, say N. - config HEADERS_INSTALL bool "Install uapi headers to usr/include" depends on !UML @@ -410,6 +407,8 @@ config DEBUG_FORCE_WEAK_PER_CPU endmenu # "Compiler options" +menu "Generic Kernel Debugging Instruments" + config MAGIC_SYSRQ bool "Magic SysRq key" depends on !UML @@ -443,6 +442,24 @@ config MAGIC_SYSRQ_SERIAL This option allows you to decide whether you want to enable the magic SysRq key. +config DEBUG_FS + bool "Debug Filesystem" + help + debugfs is a virtual file system that kernel developers use to put + debugging files into. Enable this option to be able to read and + write to these files. + + For detailed documentation on the debugfs API, see + Documentation/filesystems/. + + If unsure, say N. + +source "lib/Kconfig.kgdb" + +source "lib/Kconfig.ubsan" + +endmenu + config DEBUG_KERNEL bool "Kernel debugging" help @@ -635,6 +652,18 @@ config DEBUG_STACK_USAGE This option will slow down process creation somewhat. +config SCHED_STACK_END_CHECK + bool "Detect stack corruption on calls to schedule()" + depends on DEBUG_KERNEL + default n + help + This option checks for a stack overrun on calls to schedule(). + If the stack end location is found to be over written always panic as + the content of the corrupted region can no longer be trusted. + This is to ensure no erroneous behaviour occurs which could result in + data corruption or a sporadic crash at a later stage once the region + is examined. The runtime overhead introduced is minimal. + config DEBUG_VM bool "Debug VM" depends on DEBUG_KERNEL @@ -767,53 +796,6 @@ source "lib/Kconfig.kasan" endmenu # "Memory Debugging" -config ARCH_HAS_KCOV - bool - help - An architecture should select this when it can successfully - build and run with CONFIG_KCOV. This typically requires - disabling instrumentation for some early boot code. - -config CC_HAS_SANCOV_TRACE_PC - def_bool $(cc-option,-fsanitize-coverage=trace-pc) - -config KCOV - bool "Code coverage for fuzzing" - depends on ARCH_HAS_KCOV - depends on CC_HAS_SANCOV_TRACE_PC || GCC_PLUGINS - select DEBUG_FS - select GCC_PLUGIN_SANCOV if !CC_HAS_SANCOV_TRACE_PC - help - KCOV exposes kernel code coverage information in a form suitable - for coverage-guided fuzzing (randomized testing). - - If RANDOMIZE_BASE is enabled, PC values will not be stable across - different machines and across reboots. If you need stable PC values, - disable RANDOMIZE_BASE. - - For more details, see Documentation/dev-tools/kcov.rst. - -config KCOV_ENABLE_COMPARISONS - bool "Enable comparison operands collection by KCOV" - depends on KCOV - depends on $(cc-option,-fsanitize-coverage=trace-cmp) - help - KCOV also exposes operands of every comparison in the instrumented - code along with operand sizes and PCs of the comparison instructions. - These operands can be used by fuzzing engines to improve the quality - of fuzzing coverage. - -config KCOV_INSTRUMENT_ALL - bool "Instrument all code by default" - depends on KCOV - default y - help - If you are doing generic system call fuzzing (like e.g. syzkaller), - then you will want to instrument the whole kernel and you should - say y here. If you are doing more targeted fuzzing (like e.g. - filesystem fuzzing with AFL) then you will want to enable coverage - for more specific subsets of files, and should say n here. - config DEBUG_SHIRQ bool "Debug shared IRQ handlers" depends on DEBUG_KERNEL @@ -823,7 +805,35 @@ config DEBUG_SHIRQ Drivers ought to be able to handle interrupts coming in at those points; some don't and need to be caught. -menu "Debug Lockups and Hangs" +menu "Debug Oops, Lockups and Hangs" + +config PANIC_ON_OOPS + bool "Panic on Oops" + help + Say Y here to enable the kernel to panic when it oopses. This + has the same effect as setting oops=panic on the kernel command + line. + + This feature is useful to ensure that the kernel does not do + anything erroneous after an oops which could result in data + corruption or other issues. + + Say N if unsure. + +config PANIC_ON_OOPS_VALUE + int + range 0 1 + default 0 if !PANIC_ON_OOPS + default 1 if PANIC_ON_OOPS + +config PANIC_TIMEOUT + int "panic timeout" + default 0 + help + Set the timeout value (in seconds) until a reboot occurs when the + the kernel panics. If n = 0, then we wait forever. A timeout + value n > 0 will wait n seconds before rebooting, while a timeout + value n < 0 will reboot immediately. config LOCKUP_DETECTOR bool @@ -981,33 +991,7 @@ config WQ_WATCHDOG endmenu # "Debug lockups and hangs" -config PANIC_ON_OOPS - bool "Panic on Oops" - help - Say Y here to enable the kernel to panic when it oopses. This - has the same effect as setting oops=panic on the kernel command - line. - - This feature is useful to ensure that the kernel does not do - anything erroneous after an oops which could result in data - corruption or other issues. - - Say N if unsure. - -config PANIC_ON_OOPS_VALUE - int - range 0 1 - default 0 if !PANIC_ON_OOPS - default 1 if PANIC_ON_OOPS - -config PANIC_TIMEOUT - int "panic timeout" - default 0 - help - Set the timeout value (in seconds) until a reboot occurs when the - the kernel panics. If n = 0, then we wait forever. A timeout - value n > 0 will wait n seconds before rebooting, while a timeout - value n < 0 will reboot immediately. +menu "Scheduler Debugging" config SCHED_DEBUG bool "Collect scheduler debugging info" @@ -1035,17 +1019,7 @@ config SCHEDSTATS application, you can say N to avoid the very slight overhead this adds. -config SCHED_STACK_END_CHECK - bool "Detect stack corruption on calls to schedule()" - depends on DEBUG_KERNEL - default n - help - This option checks for a stack overrun on calls to schedule(). - If the stack end location is found to be over written always panic as - the content of the corrupted region can no longer be trusted. - This is to ensure no erroneous behaviour occurs which could result in - data corruption or a sporadic crash at a later stage once the region - is examined. The runtime overhead introduced is minimal. +endmenu config DEBUG_TIMEKEEPING bool "Enable extra timekeeping sanity checking" @@ -1349,14 +1323,7 @@ config DEBUG_KOBJECT_RELEASE config HAVE_DEBUG_BUGVERBOSE bool -config DEBUG_BUGVERBOSE - bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT - depends on BUG && (GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE) - default y - help - Say Y here to make BUG() panics output the file name and line number - of the BUG call as well as the EIP and oops trace. This aids - debugging but costs about 70-100K of memory. +menu "Debug kernel data structures" config DEBUG_LIST bool "Debug linked list manipulation" @@ -1397,6 +1364,18 @@ config DEBUG_NOTIFIERS This is a relatively cheap check but if you care about maximum performance, say N. +config BUG_ON_DATA_CORRUPTION + bool "Trigger a BUG when data corruption is detected" + select DEBUG_LIST + help + Select this option if the kernel should BUG when it encounters + data corruption in kernel memory structures when they get checked + for validity. + + If unsure, say N. + +endmenu + config DEBUG_CREDENTIALS bool "Debug credential management" depends on DEBUG_KERNEL @@ -1469,164 +1448,6 @@ config CPU_HOTPLUG_STATE_CONTROL Say N if your are unsure. -config NOTIFIER_ERROR_INJECTION - tristate "Notifier error injection" - depends on DEBUG_KERNEL - select DEBUG_FS - help - This option provides the ability to inject artificial errors to - specified notifier chain callbacks. It is useful to test the error - handling of notifier call chain failures. - - Say N if unsure. - -config PM_NOTIFIER_ERROR_INJECT - tristate "PM notifier error injection module" - depends on PM && NOTIFIER_ERROR_INJECTION - default m if PM_DEBUG - help - This option provides the ability to inject artificial errors to - PM notifier chain callbacks. It is controlled through debugfs - interface /sys/kernel/debug/notifier-error-inject/pm - - If the notifier call chain should be failed with some events - notified, write the error code to "actions/<notifier event>/error". - - Example: Inject PM suspend error (-12 = -ENOMEM) - - # cd /sys/kernel/debug/notifier-error-inject/pm/ - # echo -12 > actions/PM_SUSPEND_PREPARE/error - # echo mem > /sys/power/state - bash: echo: write error: Cannot allocate memory - - To compile this code as a module, choose M here: the module will - be called pm-notifier-error-inject. - - If unsure, say N. - -config OF_RECONFIG_NOTIFIER_ERROR_INJECT - tristate "OF reconfig notifier error injection module" - depends on OF_DYNAMIC && NOTIFIER_ERROR_INJECTION - help - This option provides the ability to inject artificial errors to - OF reconfig notifier chain callbacks. It is controlled - through debugfs interface under - /sys/kernel/debug/notifier-error-inject/OF-reconfig/ - - If the notifier call chain should be failed with some events - notified, write the error code to "actions/<notifier event>/error". - - To compile this code as a module, choose M here: the module will - be called of-reconfig-notifier-error-inject. - - If unsure, say N. - -config NETDEV_NOTIFIER_ERROR_INJECT - tristate "Netdev notifier error injection module" - depends on NET && NOTIFIER_ERROR_INJECTION - help - This option provides the ability to inject artificial errors to - netdevice notifier chain callbacks. It is controlled through debugfs - interface /sys/kernel/debug/notifier-error-inject/netdev - - If the notifier call chain should be failed with some events - notified, write the error code to "actions/<notifier event>/error". - - Example: Inject netdevice mtu change error (-22 = -EINVAL) - - # cd /sys/kernel/debug/notifier-error-inject/netdev - # echo -22 > actions/NETDEV_CHANGEMTU/error - # ip link set eth0 mtu 1024 - RTNETLINK answers: Invalid argument - - To compile this code as a module, choose M here: the module will - be called netdev-notifier-error-inject. - - If unsure, say N. - -config FUNCTION_ERROR_INJECTION - def_bool y - depends on HAVE_FUNCTION_ERROR_INJECTION && KPROBES - -config FAULT_INJECTION - bool "Fault-injection framework" - depends on DEBUG_KERNEL - help - Provide fault-injection framework. - For more details, see Documentation/fault-injection/. - -config FAILSLAB - bool "Fault-injection capability for kmalloc" - depends on FAULT_INJECTION - depends on SLAB || SLUB - help - Provide fault-injection capability for kmalloc. - -config FAIL_PAGE_ALLOC - bool "Fault-injection capabilitiy for alloc_pages()" - depends on FAULT_INJECTION - help - Provide fault-injection capability for alloc_pages(). - -config FAIL_MAKE_REQUEST - bool "Fault-injection capability for disk IO" - depends on FAULT_INJECTION && BLOCK - help - Provide fault-injection capability for disk IO. - -config FAIL_IO_TIMEOUT - bool "Fault-injection capability for faking disk interrupts" - depends on FAULT_INJECTION && BLOCK - help - Provide fault-injection capability on end IO handling. This - will make the block layer "forget" an interrupt as configured, - thus exercising the error handling. - - Only works with drivers that use the generic timeout handling, - for others it wont do anything. - -config FAIL_FUTEX - bool "Fault-injection capability for futexes" - select DEBUG_FS - depends on FAULT_INJECTION && FUTEX - help - Provide fault-injection capability for futexes. - -config FAULT_INJECTION_DEBUG_FS - bool "Debugfs entries for fault-injection capabilities" - depends on FAULT_INJECTION && SYSFS && DEBUG_FS - help - Enable configuration of fault-injection capabilities via debugfs. - -config FAIL_FUNCTION - bool "Fault-injection capability for functions" - depends on FAULT_INJECTION_DEBUG_FS && FUNCTION_ERROR_INJECTION - help - Provide function-based fault-injection capability. - This will allow you to override a specific function with a return - with given return value. As a result, function caller will see - an error value and have to handle it. This is useful to test the - error handling in various subsystems. - -config FAIL_MMC_REQUEST - bool "Fault-injection capability for MMC IO" - depends on FAULT_INJECTION_DEBUG_FS && MMC - help - Provide fault-injection capability for MMC IO. - This will make the mmc core return data errors. This is - useful to test the error handling in the mmc block device - and to test how the mmc host driver handles retries from - the block device. - -config FAULT_INJECTION_STACKTRACE_FILTER - bool "stacktrace filter for fault-injection capabilities" - depends on FAULT_INJECTION_DEBUG_FS && STACKTRACE_SUPPORT - depends on !X86_64 - select STACKTRACE - select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM && !ARC && !X86 - help - Provide stacktrace filter for fault-injection capabilities - config LATENCYTOP bool "Latency measuring infrastructure" depends on DEBUG_KERNEL @@ -1675,6 +1496,109 @@ config PROVIDE_OHCI1394_DMA_INIT source "lib/kunit/Kconfig" +source "samples/Kconfig" + +config ARCH_HAS_DEVMEM_IS_ALLOWED + bool + +config STRICT_DEVMEM + bool "Filter access to /dev/mem" + depends on MMU && DEVMEM + depends on ARCH_HAS_DEVMEM_IS_ALLOWED + default y if PPC || X86 || ARM64 + ---help--- + If this option is disabled, you allow userspace (root) access to all + of memory, including kernel and userspace memory. Accidental + access to this is obviously disastrous, but specific access can + be used by people debugging the kernel. Note that with PAT support + enabled, even in this case there are restrictions on /dev/mem + use due to the cache aliasing requirements. + + If this option is switched on, and IO_STRICT_DEVMEM=n, the /dev/mem + file only allows userspace access to PCI space and the BIOS code and + data regions. This is sufficient for dosemu and X and all common + users of /dev/mem. + + If in doubt, say Y. + +config IO_STRICT_DEVMEM + bool "Filter I/O access to /dev/mem" + depends on STRICT_DEVMEM + ---help--- + If this option is disabled, you allow userspace (root) access to all + io-memory regardless of whether a driver is actively using that + range. Accidental access to this is obviously disastrous, but + specific access can be used by people debugging kernel drivers. + + If this option is switched on, the /dev/mem file only allows + userspace access to *idle* io-memory ranges (see /proc/iomem) This + may break traditional users of /dev/mem (dosemu, legacy X, etc...) + if the driver using a given range cannot be disabled. + + If in doubt, say Y. + +config DEBUG_AID_FOR_SYZBOT + bool "Additional debug code for syzbot" + default n + help + This option is intended for testing by syzbot. + +menu "$(SRCARCH) Debugging" + +source "arch/$(SRCARCH)/Kconfig.debug" + +endmenu + +menu "Kernel Testing and Coverage" + +config ARCH_HAS_KCOV + bool + help + An architecture should select this when it can successfully + build and run with CONFIG_KCOV. This typically requires + disabling instrumentation for some early boot code. + +config CC_HAS_SANCOV_TRACE_PC + def_bool $(cc-option,-fsanitize-coverage=trace-pc) + + +config KCOV + bool "Code coverage for fuzzing" + depends on ARCH_HAS_KCOV + depends on CC_HAS_SANCOV_TRACE_PC || GCC_PLUGINS + select DEBUG_FS + select GCC_PLUGIN_SANCOV if !CC_HAS_SANCOV_TRACE_PC + help + KCOV exposes kernel code coverage information in a form suitable + for coverage-guided fuzzing (randomized testing). + + If RANDOMIZE_BASE is enabled, PC values will not be stable across + different machines and across reboots. If you need stable PC values, + disable RANDOMIZE_BASE. + + For more details, see Documentation/dev-tools/kcov.rst. + +config KCOV_ENABLE_COMPARISONS + bool "Enable comparison operands collection by KCOV" + depends on KCOV + depends on $(cc-option,-fsanitize-coverage=trace-cmp) + help + KCOV also exposes operands of every comparison in the instrumented + code along with operand sizes and PCs of the comparison instructions. + These operands can be used by fuzzing engines to improve the quality + of fuzzing coverage. + +config KCOV_INSTRUMENT_ALL + bool "Instrument all code by default" + depends on KCOV + default y + help + If you are doing generic system call fuzzing (like e.g. syzkaller), + then you will want to instrument the whole kernel and you should + say y here. If you are doing more targeted fuzzing (like e.g. + filesystem fuzzing with AFL) then you will want to enable coverage + for more specific subsets of files, and should say n here. + menuconfig RUNTIME_TESTING_MENU bool "Runtime Testing" def_bool y @@ -1970,6 +1894,18 @@ config SYSCTL_KUNIT_TEST If unsure, say N. +config LIST_TEST + bool "KUnit Test for Kernel Linked-list structures" + depends on KUNIT + help + This builds the linked list unit test, which runs on boot. + It tests that the API and basic functionality of the list_head type + and associated macros. + For more information on KUnit and unit tests in general please refer + to the KUnit documentation in Documentation/dev-tools/kunit/. + + If unsure, say N. + config TEST_UDELAY tristate "udelay test driver" help @@ -2092,67 +2028,164 @@ config MEMTEST memtest=17, mean do 17 test patterns. If you are unsure how to answer this question, answer N. -config BUG_ON_DATA_CORRUPTION - bool "Trigger a BUG when data corruption is detected" - select DEBUG_LIST +config NOTIFIER_ERROR_INJECTION + tristate "Notifier error injection" + depends on DEBUG_KERNEL + select DEBUG_FS help - Select this option if the kernel should BUG when it encounters - data corruption in kernel memory structures when they get checked - for validity. + This option provides the ability to inject artificial errors to + specified notifier chain callbacks. It is useful to test the error + handling of notifier call chain failures. + + Say N if unsure. + +config PM_NOTIFIER_ERROR_INJECT + tristate "PM notifier error injection module" + depends on PM && NOTIFIER_ERROR_INJECTION + default m if PM_DEBUG + help + This option provides the ability to inject artificial errors to + PM notifier chain callbacks. It is controlled through debugfs + interface /sys/kernel/debug/notifier-error-inject/pm + + If the notifier call chain should be failed with some events + notified, write the error code to "actions/<notifier event>/error". + + Example: Inject PM suspend error (-12 = -ENOMEM) + + # cd /sys/kernel/debug/notifier-error-inject/pm/ + # echo -12 > actions/PM_SUSPEND_PREPARE/error + # echo mem > /sys/power/state + bash: echo: write error: Cannot allocate memory + + To compile this code as a module, choose M here: the module will + be called pm-notifier-error-inject. If unsure, say N. -source "samples/Kconfig" +config OF_RECONFIG_NOTIFIER_ERROR_INJECT + tristate "OF reconfig notifier error injection module" + depends on OF_DYNAMIC && NOTIFIER_ERROR_INJECTION + help + This option provides the ability to inject artificial errors to + OF reconfig notifier chain callbacks. It is controlled + through debugfs interface under + /sys/kernel/debug/notifier-error-inject/OF-reconfig/ -source "lib/Kconfig.kgdb" + If the notifier call chain should be failed with some events + notified, write the error code to "actions/<notifier event>/error". -source "lib/Kconfig.ubsan" + To compile this code as a module, choose M here: the module will + be called of-reconfig-notifier-error-inject. -config ARCH_HAS_DEVMEM_IS_ALLOWED - bool + If unsure, say N. -config STRICT_DEVMEM - bool "Filter access to /dev/mem" - depends on MMU && DEVMEM - depends on ARCH_HAS_DEVMEM_IS_ALLOWED - default y if PPC || X86 || ARM64 - ---help--- - If this option is disabled, you allow userspace (root) access to all - of memory, including kernel and userspace memory. Accidental - access to this is obviously disastrous, but specific access can - be used by people debugging the kernel. Note that with PAT support - enabled, even in this case there are restrictions on /dev/mem - use due to the cache aliasing requirements. +config NETDEV_NOTIFIER_ERROR_INJECT + tristate "Netdev notifier error injection module" + depends on NET && NOTIFIER_ERROR_INJECTION + help + This option provides the ability to inject artificial errors to + netdevice notifier chain callbacks. It is controlled through debugfs + interface /sys/kernel/debug/notifier-error-inject/netdev - If this option is switched on, and IO_STRICT_DEVMEM=n, the /dev/mem - file only allows userspace access to PCI space and the BIOS code and - data regions. This is sufficient for dosemu and X and all common - users of /dev/mem. + If the notifier call chain should be failed with some events + notified, write the error code to "actions/<notifier event>/error". - If in doubt, say Y. + Example: Inject netdevice mtu change error (-22 = -EINVAL) -config IO_STRICT_DEVMEM - bool "Filter I/O access to /dev/mem" - depends on STRICT_DEVMEM - ---help--- - If this option is disabled, you allow userspace (root) access to all - io-memory regardless of whether a driver is actively using that - range. Accidental access to this is obviously disastrous, but - specific access can be used by people debugging kernel drivers. + # cd /sys/kernel/debug/notifier-error-inject/netdev + # echo -22 > actions/NETDEV_CHANGEMTU/error + # ip link set eth0 mtu 1024 + RTNETLINK answers: Invalid argument - If this option is switched on, the /dev/mem file only allows - userspace access to *idle* io-memory ranges (see /proc/iomem) This - may break traditional users of /dev/mem (dosemu, legacy X, etc...) - if the driver using a given range cannot be disabled. + To compile this code as a module, choose M here: the module will + be called netdev-notifier-error-inject. - If in doubt, say Y. + If unsure, say N. -config DEBUG_AID_FOR_SYZBOT - bool "Additional debug code for syzbot" - default n - help - This option is intended for testing by syzbot. +config FUNCTION_ERROR_INJECTION + def_bool y + depends on HAVE_FUNCTION_ERROR_INJECTION && KPROBES -source "arch/$(SRCARCH)/Kconfig.debug" +config FAULT_INJECTION + bool "Fault-injection framework" + depends on DEBUG_KERNEL + help + Provide fault-injection framework. + For more details, see Documentation/fault-injection/. + +config FAILSLAB + bool "Fault-injection capability for kmalloc" + depends on FAULT_INJECTION + depends on SLAB || SLUB + help + Provide fault-injection capability for kmalloc. + +config FAIL_PAGE_ALLOC + bool "Fault-injection capabilitiy for alloc_pages()" + depends on FAULT_INJECTION + help + Provide fault-injection capability for alloc_pages(). + +config FAIL_MAKE_REQUEST + bool "Fault-injection capability for disk IO" + depends on FAULT_INJECTION && BLOCK + help + Provide fault-injection capability for disk IO. + +config FAIL_IO_TIMEOUT + bool "Fault-injection capability for faking disk interrupts" + depends on FAULT_INJECTION && BLOCK + help + Provide fault-injection capability on end IO handling. This + will make the block layer "forget" an interrupt as configured, + thus exercising the error handling. + + Only works with drivers that use the generic timeout handling, + for others it wont do anything. + +config FAIL_FUTEX + bool "Fault-injection capability for futexes" + select DEBUG_FS + depends on FAULT_INJECTION && FUTEX + help + Provide fault-injection capability for futexes. + +config FAULT_INJECTION_DEBUG_FS + bool "Debugfs entries for fault-injection capabilities" + depends on FAULT_INJECTION && SYSFS && DEBUG_FS + help + Enable configuration of fault-injection capabilities via debugfs. + +config FAIL_FUNCTION + bool "Fault-injection capability for functions" + depends on FAULT_INJECTION_DEBUG_FS && FUNCTION_ERROR_INJECTION + help + Provide function-based fault-injection capability. + This will allow you to override a specific function with a return + with given return value. As a result, function caller will see + an error value and have to handle it. This is useful to test the + error handling in various subsystems. + +config FAIL_MMC_REQUEST + bool "Fault-injection capability for MMC IO" + depends on FAULT_INJECTION_DEBUG_FS && MMC + help + Provide fault-injection capability for MMC IO. + This will make the mmc core return data errors. This is + useful to test the error handling in the mmc block device + and to test how the mmc host driver handles retries from + the block device. + +config FAULT_INJECTION_STACKTRACE_FILTER + bool "stacktrace filter for fault-injection capabilities" + depends on FAULT_INJECTION_DEBUG_FS && STACKTRACE_SUPPORT + depends on !X86_64 + select STACKTRACE + select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM && !ARC && !X86 + help + Provide stacktrace filter for fault-injection capabilities + +endmenu # "Kernel Testing and Coverage" endmenu # Kernel hacking |