# SPDX-License-Identifier: GPL-2.0-only

menu "Kernel hacking"

menu "printk and dmesg options"

config PRINTK_TIME

bool "Show timing information on printks"

depends on PRINTK

help

Selecting this option causes time stamps of the printk()

messages to be added to the output of the syslog() system

call and at the console.

The timestamp is always recorded internally, and exported

to /dev/kmsg. This flag just specifies if the timestamp should

be included, not that the timestamp is recorded.

The behavior is also controlled by the kernel command line

parameter printk.time=1. See Documentation/admin-guide/kernel-parameters.rst

config PRINTK_CALLER

bool "Show caller information on printks"

depends on PRINTK

help

Selecting this option causes printk() to add a caller "thread id" (if

in task context) or a caller "processor id" (if not in task context)

to every message.

This option is intended for environments where multiple threads

concurrently call printk() for many times, for it is difficult to

interpret without knowing where these lines (or sometimes individual

line which was divided into multiple lines due to race) came from.

Since toggling after boot makes the code racy, currently there is

no option to enable/disable at the kernel command line parameter or

sysfs interface.

config CONSOLE_LOGLEVEL_DEFAULT

int "Default console loglevel (1-15)"

range 1 15

default "7"

help

Default loglevel to determine what will be printed on the console.

Setting a default here is equivalent to passing in loglevel=<x> in

the kernel bootargs. loglevel=<x> continues to override whatever

value is specified here as well.

Note: This does not affect the log level of un-prefixed printk()

usage in the kernel. That is controlled by the MESSAGE_LOGLEVEL_DEFAULT

option.

config CONSOLE_LOGLEVEL_QUIET

int "quiet console loglevel (1-15)"

range 1 15

default "4"

help

loglevel to use when "quiet" is passed on the kernel commandline.

When "quiet" is passed on the kernel commandline this loglevel

will be used as the loglevel. IOW passing "quiet" will be the

equivalent of passing "loglevel=<CONSOLE_LOGLEVEL_QUIET>"

config MESSAGE_LOGLEVEL_DEFAULT

int "Default message log level (1-7)"

range 1 7

default "4"

help

Default log level for printk statements with no specified priority.

This was hard-coded to KERN_WARNING since at least 2.6.10 but folks

that are auditing their logs closely may want to set it to a lower

priority.

Note: This does not affect what message level gets printed on the console

by default. To change that, use loglevel=<x> in the kernel bootargs,

or pick a different CONSOLE_LOGLEVEL_DEFAULT configuration value.

config BOOT_PRINTK_DELAY

bool "Delay each boot printk message by N milliseconds"

depends on DEBUG_KERNEL && PRINTK && GENERIC_CALIBRATE_DELAY

help

This build option allows you to read kernel boot messages

by inserting a short delay after each one. The delay is

specified in milliseconds on the kernel command line,

using "boot_delay=N".

It is likely that you would also need to use "lpj=M" to preset

the "loops per jiffie" value.

See a previous boot log for the "lpj" value to use for your

system, and then set "lpj=M" before setting "boot_delay=N".

NOTE: Using this option may adversely affect SMP systems.

I.e., processors other than the first one may not boot up.

BOOT_PRINTK_DELAY also may cause LOCKUP_DETECTOR to detect

what it believes to be lockup conditions.

config DYNAMIC_DEBUG

bool "Enable dynamic printk() support"

default n

depends on PRINTK

depends on DEBUG_FS

help

Compiles debug level messages into the kernel, which would not

otherwise be available at runtime. These messages can then be

enabled/disabled based on various levels of scope - per source file,

function, module, format string, and line number. This mechanism

implicitly compiles in all pr_debug() and dev_dbg() calls, which

enlarges the kernel text size by about 2%.

If a source file is compiled with DEBUG flag set, any

pr_debug() calls in it are enabled by default, but can be

disabled at runtime as below. Note that DEBUG flag is

turned on by many CONFIG_*DEBUG* options.

Usage:

Dynamic debugging is controlled via the 'dynamic_debug/control' file,

which is contained in the 'debugfs' filesystem. Thus, the debugfs

filesystem must first be mounted before making use of this feature.

We refer the control file as: <debugfs>/dynamic_debug/control. This

file contains a list of the debug statements that can be enabled. The

format for each line of the file is:

filename:lineno [module]function flags format

filename : source file of the debug statement

lineno : line number of the debug statement

module : module that contains the debug statement

function : function that contains the debug statement

flags : '=p' means the line is turned 'on' for printing

format : the format used for the debug statement

From a live system:

nullarbor:~ # cat <debugfs>/dynamic_debug/control

# filename:lineno [module]function flags format

fs/aio.c:222 [aio]__put_ioctx =_ "__put_ioctx:\040freeing\040%p\012"

fs/aio.c:248 [aio]ioctx_alloc =_ "ENOMEM:\040nr_events\040too\040high\012"

fs/aio.c:1770 [aio]sys_io_cancel =_ "calling\040cancel\012"

Example usage:

// enable the message at line 1603 of file svcsock.c

nullarbor:~ # echo -n 'file svcsock.c line 1603 +p' >

<debugfs>/dynamic_debug/control

// enable all the messages in file svcsock.c

nullarbor:~ # echo -n 'file svcsock.c +p' >

<debugfs>/dynamic_debug/control

// enable all the messages in the NFS server module

nullarbor:~ # echo -n 'module nfsd +p' >

<debugfs>/dynamic_debug/control

// enable all 12 messages in the function svc_process()

nullarbor:~ # echo -n 'func svc_process +p' >

<debugfs>/dynamic_debug/control

// disable all 12 messages in the function svc_process()

nullarbor:~ # echo -n 'func svc_process -p' >

<debugfs>/dynamic_debug/control

See Documentation/admin-guide/dynamic-debug-howto.rst for additional

information.

endmenu # "printk and dmesg options"

menu "Compile-time checks and compiler options"

config DEBUG_INFO

bool "Compile the kernel with debug info"

depends on DEBUG_KERNEL && !COMPILE_TEST

help

If you say Y here the resulting kernel image will include

debugging info resulting in a larger kernel image.

This adds debug symbols to the kernel and modules (gcc -g), and

is needed if you intend to use kernel crashdump or binary object

tools like crash, kgdb, LKCD, gdb, etc on the kernel.

Say Y here only if you plan to debug the kernel.

If unsure, say N.

config DEBUG_INFO_REDUCED

bool "Reduce debugging information"

depends on DEBUG_INFO

help

If you say Y here gcc is instructed to generate less debugging

information for structure types. This means that tools that

need full debugging information (like kgdb or systemtap) won't

be happy. But if you merely need debugging information to

resolve line numbers there is no loss. Advantage is that

build directory object sizes shrink dramatically over a full

DEBUG_INFO build and compile times are reduced too.

Only works with newer gcc versions.

config DEBUG_INFO_SPLIT

bool "Produce split debuginfo in .dwo files"

depends on DEBUG_INFO

depends on $(cc-option,-gsplit-dwarf)

help

Generate debug info into separate .dwo files. This significantly

reduces the build directory size for builds with DEBUG_INFO,

because it stores the information only once on disk in .dwo

files instead of multiple times in object files and executables.

In addition the debug information is also compressed.

Requires recent gcc (4.7+) and recent gdb/binutils.

Any tool that packages or reads debug information would need

to know about the .dwo files and include them.

Incompatible with older versions of ccache.

config DEBUG_INFO_DWARF4

bool "Generate dwarf4 debuginfo"

depends on DEBUG_INFO

depends on $(cc-option,-gdwarf-4)

help

Generate dwarf4 debug info. This requires recent versions

of gcc and gdb. It makes the debug information larger.

But it significantly improves the success of resolving

variables in gdb on optimized code.

config DEBUG_INFO_BTF

bool "Generate BTF typeinfo"

depends on DEBUG_INFO

depends on !DEBUG_INFO_SPLIT && !DEBUG_INFO_REDUCED

depends on !GCC_PLUGIN_RANDSTRUCT || COMPILE_TEST

help

Generate deduplicated BTF type information from DWARF debug info.

Turning this on expects presence of pahole tool, which will convert

DWARF type info into equivalent deduplicated BTF type info.

config GDB_SCRIPTS

bool "Provide GDB scripts for kernel debugging"

depends on DEBUG_INFO

help

This creates the required links to GDB helper scripts in the

build directory. If you load vmlinux into gdb, the helper

scripts will be automatically imported by gdb as well, and

additional functions are available to analyze a Linux kernel

instance. See Documentation/dev-tools/gdb-kernel-debugging.rst

for further details.

config ENABLE_MUST_CHECK

bool "Enable __must_check logic"

default y

help

Enable the __must_check logic in the kernel build. Disable this to

suppress the "warning: ignoring return value of 'foo', declared with

attribute warn_unused_result" messages.

config FRAME_WARN

int "Warn for stack frames larger than (needs gcc 4.4)"

range 0 8192

default 2048 if GCC_PLUGIN_LATENT_ENTROPY

default 2048 if PARISC

default 1536 if (!64BIT && XTENSA)

default 1280 if KASAN && !64BIT

default 1024 if !64BIT

default 2048 if 64BIT

help

Tell gcc to warn at build time for stack frames larger than this.

Setting this too low will cause a lot of warnings.

Setting it to 0 disables the warning.

Requires gcc 4.4

config STRIP_ASM_SYMS

bool "Strip assembler-generated symbols during link"

default n

help

Strip internal assembler-generated symbols during a link (symbols

that look like '.Lxxx') so they don't pollute the output of

get_wchan() and suchlike.

config READABLE_ASM

bool "Generate readable assembler code"

depends on DEBUG_KERNEL

help

Disable some compiler optimizations that tend to generate human unreadable

assembler output. This may make the kernel slightly slower, but it helps

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

help

This option will install uapi headers (headers exported to user-space)

into the usr/include directory for use during the kernel build.

This is unneeded for building the kernel itself, but needed for some

user-space program samples. It is also needed by some features such

as uapi header sanity checks.

config OPTIMIZE_INLINING

def_bool y

help

This option determines if the kernel forces gcc to inline the functions

developers have marked 'inline'. Doing so takes away freedom from gcc to

do what it thinks is best, which is desirable for the gcc 3.x series of

compilers. The gcc 4.x series have a rewritten inlining algorithm and

enabling this option will generate a smaller kernel there. Hopefully

this algorithm is so good that allowing gcc 4.x and above to make the

decision will become the default in the future. Until then this option

is there to test gcc for this.

config DEBUG_SECTION_MISMATCH

bool "Enable full Section mismatch analysis"

help

The section mismatch analysis checks if there are illegal

references from one section to another section.

During linktime or runtime, some sections are dropped;

any use of code/data previously in these sections would

most likely result in an oops.

In the code, functions and variables are annotated with

__init,, etc. (see the full list in include/linux/init.h),

which results in the code/data being placed in specific sections.

The section mismatch analysis is always performed after a full

kernel build, and enabling this option causes the following

additional step to occur:

- Add the option -fno-inline-functions-called-once to gcc commands.

When inlining a function annotated with __init in a non-init

function, we would lose the section information and thus

the analysis would not catch the illegal reference.

This option tells gcc to inline less (but it does result in

a larger kernel).

config SECTION_MISMATCH_WARN_ONLY

bool "Make section mismatch errors non-fatal"

default y

help

If you say N here, the build process will fail if there are any

section mismatch, instead of just throwing warnings.

If unsure, say Y.

#

# Select this config option from the architecture Kconfig, if it

# is preferred to always offer frame pointers as a config

# option on the architecture (regardless of KERNEL_DEBUG):

#

config ARCH_WANT_FRAME_POINTERS

bool

config FRAME_POINTER

bool "Compile the kernel with frame pointers"

depends on DEBUG_KERNEL && (M68K || UML || SUPERH) || ARCH_WANT_FRAME_POINTERS

default y if (DEBUG_INFO && UML) || ARCH_WANT_FRAME_POINTERS

help

If you say Y here the resulting kernel image will be slightly

larger and slower, but it gives very useful debugging information

in case of kernel bugs. (precise oopses/stacktraces/warnings)

config STACK_VALIDATION

bool "Compile-time stack metadata validation"

depends on HAVE_STACK_VALIDATION

default n

help

Add compile-time checks to validate stack metadata, including frame

pointers (if CONFIG_FRAME_POINTER is enabled). This helps ensure

that runtime stack traces are more reliable.

This is also a prerequisite for generation of ORC unwind data, which

is needed for CONFIG_UNWINDER_ORC.

For more information, see

tools/objtool/Documentation/stack-validation.txt.

config DEBUG_FORCE_WEAK_PER_CPU

bool "Force weak per-cpu definitions"

depends on DEBUG_KERNEL

help

s390 and alpha require percpu variables in modules to be

defined weak to work around addressing range issue which

puts the following two restrictions on percpu variable

definitions.

1. percpu symbols must be unique whether static or not

2. percpu variables can't be defined inside a function

To ensure that generic code follows the above rules, this

option forces all percpu variables to be defined as weak.

endmenu # "Compiler options"

config MAGIC_SYSRQ

bool "Magic SysRq key"

depends on !UML

help

If you say Y here, you will have some control over the system even

if the system crashes for example during kernel debugging (e.g., you

will be able to flush the buffer cache to disk, reboot the system

immediately or dump some status information). This is accomplished

by pressing various keys while holding SysRq (Alt+PrintScreen). It

also works on a serial console (on PC hardware at least), if you

send a BREAK and then within 5 seconds a command keypress. The

keys are documented in <file:Documentation/admin-guide/sysrq.rst>.

Don't say Y unless you really know what this hack does.

config MAGIC_SYSRQ_DEFAULT_ENABLE

hex "Enable magic SysRq key functions by default"

depends on MAGIC_SYSRQ

default 0x1

help

Specifies which SysRq key functions are enabled by default.

This may be set to 1 or 0 to enable or disable them all, or

to a bitmask as described in Documentation/admin-guide/sysrq.rst.

config MAGIC_SYSRQ_SERIAL

bool "Enable magic SysRq key over serial"

depends on MAGIC_SYSRQ

default y

help

Many embedded boards have a disconnected TTL level serial which can

generate some garbage that can lead to spurious false sysrq detects.

This option allows you to decide whether you want to enable the

magic SysRq key.

config DEBUG_KERNEL

bool "Kernel debugging"

help

Say Y here if you are developing drivers or trying to debug and

identify kernel problems.

config DEBUG_MISC

bool "Miscellaneous debug code"

default DEBUG_KERNEL

depends on DEBUG_KERNEL

help

Say Y here if you need to enable miscellaneous debug code that should

be under a more specific debug option but isn't.

menu "Memory Debugging"

source "mm/Kconfig.debug"

config DEBUG_OBJECTS

bool "Debug object operations"

depends on DEBUG_KERNEL

help

If you say Y here, additional code will be inserted into the

kernel to track the life time of various objects and validate

the operations on those objects.

config DEBUG_OBJECTS_SELFTEST

bool "Debug objects selftest"

depends on DEBUG_OBJECTS

help

This enables the selftest of the object debug code.

config DEBUG_OBJECTS_FREE

bool "Debug objects in freed memory"

depends on DEBUG_OBJECTS

help

This enables checks whether a k/v free operation frees an area

which contains an object which has not been deactivated

properly. This can make kmalloc/kfree-intensive workloads

much slower.

config DEBUG_OBJECTS_TIMERS

bool "Debug timer objects"

depends on DEBUG_OBJECTS

help

If you say Y here, additional code will be inserted into the

timer routines to track the life time of timer objects and

validate the timer operations.

config DEBUG_OBJECTS_WORK

bool "Debug work objects"

depends on DEBUG_OBJECTS

help

If you say Y here, additional code will be inserted into the

work queue routines to track the life time of work objects and

validate the work operations.

config DEBUG_OBJECTS_RCU_HEAD

bool "Debug RCU callbacks objects"

depends on DEBUG_OBJECTS

help

Enable this to turn on debugging of RCU list heads (call_rcu() usage).

config DEBUG_OBJECTS_PERCPU_COUNTER

bool "Debug percpu counter objects"

depends on DEBUG_OBJECTS

help

If you say Y here, additional code will be inserted into the

percpu counter routines to track the life time of percpu counter

objects and validate the percpu counter operations.

config DEBUG_OBJECTS_ENABLE_DEFAULT

int "debug_objects bootup default value (0-1)"

range 0 1

default "1"

depends on DEBUG_OBJECTS

help

Debug objects boot parameter default value

config DEBUG_SLAB

bool "Debug slab memory allocations"

depends on DEBUG_KERNEL && SLAB

help

Say Y here to have the kernel do limited verification on memory

allocation as well as poisoning memory on free to catch use of freed

memory. This can make kmalloc/kfree-intensive workloads much slower.

config SLUB_DEBUG_ON

bool "SLUB debugging on by default"

depends on SLUB && SLUB_DEBUG

default n

help

Boot with debugging on by default. SLUB boots by default with

the runtime debug capabilities switched off. Enabling this is

equivalent to specifying the "slub_debug" parameter on boot.

There is no support for more fine grained debug control like

possible with slub_debug=xxx. SLUB debugging may be switched

off in a kernel built with CONFIG_SLUB_DEBUG_ON by specifying

"slub_debug=-".

config SLUB_STATS

default n

bool "Enable SLUB performance statistics"

depends on SLUB && SYSFS

help

SLUB statistics are useful to debug SLUBs allocation behavior in

order find ways to optimize the allocator. This should never be

enabled for production use since keeping statistics slows down

the allocator by a few percentage points. The slabinfo command

supports the determination of the most active slabs to figure

out which slabs are relevant to a particular load.

Try running: slabinfo -DA

config HAVE_DEBUG_KMEMLEAK

bool

config DEBUG_KMEMLEAK

bool "Kernel memory leak detector"

depends on DEBUG_KERNEL && HAVE_DEBUG_KMEMLEAK

select DEBUG_FS

select STACKTRACE if STACKTRACE_SUPPORT

select KALLSYMS

select CRC32

help

Say Y here if you want to enable the memory leak

detector. The memory allocation/freeing is traced in a way

similar to the Boehm's conservative garbage collector, the

difference being that the orphan objects are not freed but

only shown in /sys/kernel/debug/kmemleak. Enabling this

feature will introduce an overhead to memory

allocations. See Documentation/dev-tools/kmemleak.rst for more

details.

Enabling DEBUG_SLAB or SLUB_DEBUG may increase the chances

of finding leaks due to the slab objects poisoning.

In order to access the kmemleak file, debugfs needs to be

mounted (usually at /sys/kernel/debug).

config DEBUG_KMEMLEAK_MEM_POOL_SIZE

int "Kmemleak memory pool size"

depends on DEBUG_KMEMLEAK

range 200 1000000

default 16000

help

Kmemleak must track all the memory allocations to avoid

reporting false positives. Since memory may be allocated or

freed before kmemleak is fully initialised, use a static pool

of metadata objects to track such callbacks. After kmemleak is

fully initialised, this memory pool acts as an emergency one

if slab allocations fail.

config DEBUG_KMEMLEAK_TEST

tristate "Simple test for the kernel memory leak detector"

depends on DEBUG_KMEMLEAK && m

help

This option enables a module that explicitly leaks memory.

If unsure, say N.

config DEBUG_KMEMLEAK_DEFAULT_OFF

bool "Default kmemleak to off"

depends on DEBUG_KMEMLEAK

help

Say Y here to disable kmemleak by default. It can then be enabled

on the command line via kmemleak=on.

config DEBUG_KMEMLEAK_AUTO_SCAN

bool "Enable kmemleak auto scan thread on boot up"

default y

depends on DEBUG_KMEMLEAK

help

Depending on the cpu, kmemleak scan may be cpu intensive and can

stall user tasks at times. This option enables/disables automatic

kmemleak scan at boot up.

Say N here to disable kmemleak auto scan thread to stop automatic

scanning. Disabling this option disables automatic reporting of

memory leaks.

If unsure, say Y.

config DEBUG_STACK_USAGE

bool "Stack utilization instrumentation"

depends on DEBUG_KERNEL && !IA64

help

Enables the display of the minimum amount of free stack which each

task has ever had available in the sysrq-T and sysrq-P debug output.

This option will slow down process creation somewhat.

config DEBUG_VM

bool "Debug VM"

depends on DEBUG_KERNEL

help

Enable this to turn on extended checks in the virtual-memory system

that may impact performance.

If unsure, say N.

config DEBUG_VM_VMACACHE

bool "Debug VMA caching"

depends on DEBUG_VM

help

Enable this to turn on VMA caching debug information. Doing so

can cause significant overhead, so only enable it in non-production

environments.

If unsure, say N.

config DEBUG_VM_RB

bool "Debug VM red-black trees"

depends on DEBUG_VM

help

Enable VM red-black tree debugging information and extra validations.

If unsure, say N.

config DEBUG_VM_PGFLAGS

bool "Debug page-flags operations"

depends on DEBUG_VM

help

Enables extra validation on page flags operations.

If unsure, say N.

config ARCH_HAS_DEBUG_VIRTUAL

bool

config DEBUG_VIRTUAL

bool "Debug VM translations"

depends on DEBUG_KERNEL && ARCH_HAS_DEBUG_VIRTUAL

help

Enable some costly sanity checks in virtual to page code. This can

catch mistakes with virt_to_page() and friends.

If unsure, say N.

config DEBUG_NOMMU_REGIONS

bool "Debug the global anon/private NOMMU mapping region tree"

depends on DEBUG_KERNEL && !MMU

help

This option causes the global tree of anonymous and private mapping

regions to be regularly checked for invalid topology.

config DEBUG_MEMORY_INIT

bool "Debug memory initialisation" if EXPERT

default !EXPERT

help

Enable this for additional checks during memory initialisation.

The sanity checks verify aspects of the VM such as the memory model

and other information provided by the architecture. Verbose

information will be printed at KERN_DEBUG loglevel depending

on the mminit_loglevel= command-line option.

If unsure, say Y

config MEMORY_NOTIFIER_ERROR_INJECT

tristate "Memory hotplug notifier error injection module"

depends on MEMORY_HOTPLUG_SPARSE && NOTIFIER_ERROR_INJECTION

help

This option provides the ability to inject artificial errors to

memory hotplug notifier chain callbacks. It is controlled through

debugfs interface under /sys/kernel/debug/notifier-error-inject/memory

If the notifier call chain should be failed with some events

notified, write the error code to "actions/<notifier event>/error".

Example: Inject memory hotplug offline error (-12 == -ENOMEM)

# cd /sys/kernel/debug/notifier-error-inject/memory

# echo -12 > actions/MEM_GOING_OFFLINE/error

# echo offline > /sys/devices/system/memory/memoryXXX/state

bash: echo: write error: Cannot allocate memory

To compile this code as a module, choose M here: the module will

be called memory-notifier-error-inject.

If unsure, say N.

config DEBUG_PER_CPU_MAPS

bool "Debug access to per_cpu maps"

depends on DEBUG_KERNEL

depends on SMP

help

Say Y to verify that the per_cpu map being accessed has

been set up. This adds a fair amount of code to kernel memory

and decreases performance.

Say N if unsure.

config DEBUG_HIGHMEM

bool "Highmem debugging"

depends on DEBUG_KERNEL && HIGHMEM

help

This option enables additional error checking for high memory

systems. Disable for production systems.

config HAVE_DEBUG_STACKOVERFLOW

bool

config DEBUG_STACKOVERFLOW

bool "Check for stack overflows"

depends on DEBUG_KERNEL && HAVE_DEBUG_STACKOVERFLOW

---help---

Say Y here if you want to check for overflows of kernel, IRQ

and exception stacks (if your architecture uses them). This

option will show detailed messages if free stack space drops

below a certain limit.

These kinds of bugs usually occur when call-chains in the

kernel get too deep, especially when interrupts are

involved.

Use this in cases where you see apparently random memory

corruption, especially if it appears in 'struct thread_info'

If in doubt, say "N".

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

help

Enable this to generate a spurious interrupt as soon as a shared

interrupt handler is registered, and just before one is deregistered.

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"

config LOCKUP_DETECTOR

bool

config SOFTLOCKUP_DETECTOR

bool "Detect Soft Lockups"

depends on DEBUG_KERNEL && !S390

select LOCKUP_DETECTOR

help

Say Y here to enable the kernel to act as a watchdog to detect

soft lockups.

Softlockups are bugs that cause the kernel to loop in kernel

mode for more than 20 seconds, without giving other tasks a

chance to run. The current stack trace is displayed upon

detection and the system will stay locked up.

config BOOTPARAM_SOFTLOCKUP_PANIC

bool "Panic (Reboot) On Soft Lockups"

depends on SOFTLOCKUP_DETECTOR

help

Say Y here to enable the kernel to panic on "soft lockups",

which are bugs that cause the kernel to loop in kernel

mode for more than 20 seconds (configurable using the watchdog_thresh

sysctl), without giving other tasks a chance to run.

The panic can be used in combination with panic_timeout,

to cause the system to reboot automatically after a

lockup has been detected. This feature is useful for

high-availability systems that have uptime guarantees and

where a lockup must be resolved ASAP.

Say N if unsure.

config BOOTPARAM_SOFTLOCKUP_PANIC_VALUE

int

depends on SOFTLOCKUP_DETECTOR

range 0 1

default 0 if !BOOTPARAM_SOFTLOCKUP_PANIC

default 1 if BOOTPARAM_SOFTLOCKUP_PANIC

config HARDLOCKUP_DETECTOR_PERF

bool

select SOFTLOCKUP_DETECTOR

#

# Enables a timestamp based low pass filter to compensate for perf based

# hard lockup detection which runs too fast due to turbo modes.

#

config HARDLOCKUP_CHECK_TIMESTAMP

bool

#

# arch/ can define HAVE_HARDLOCKUP_DETECTOR_ARCH to provide their own hard

# lockup detector rather than the perf based detector.

#

config HARDLOCKUP_DETECTOR

bool "Detect Hard Lockups"

depends on DEBUG_KERNEL && !S390

depends on HAVE_HARDLOCKUP_DETECTOR_PERF || HAVE_HARDLOCKUP_DETECTOR_ARCH

select LOCKUP_DETECTOR

select HARDLOCKUP_DETECTOR_PERF if HAVE_HARDLOCKUP_DETECTOR_PERF

help

Say Y here to enable the kernel to act as a watchdog to detect

hard lockups.

Hardlockups are bugs that cause the CPU to loop in kernel mode

for more than 10 seconds, without letting other interrupts have a

chance to run. The current stack trace is displayed upon detection

and the system will stay locked up.

config BOOTPARAM_HARDLOCKUP_PANIC

bool "Panic (Reboot) On Hard Lockups"

depends on HARDLOCKUP_DETECTOR

help

Say Y here to enable the kernel to panic on "hard lockups",

which are bugs that cause the kernel to loop in kernel

mode with interrupts disabled for more than 10 seconds (configurable

using the watchdog_thresh sysctl).

Say N if unsure.

config BOOTPARAM_HARDLOCKUP_PANIC_VALUE

int

depends on HARDLOCKUP_DETECTOR

range 0 1

default 0 if !BOOTPARAM_HARDLOCKUP_PANIC

default 1 if BOOTPARAM_HARDLOCKUP_PANIC

config DETECT_HUNG_TASK

bool "Detect Hung Tasks"

depends on DEBUG_KERNEL

default SOFTLOCKUP_DETECTOR

help

Say Y here to enable the kernel to detect "hung tasks",

which are bugs that cause the task to be stuck in

uninterruptible "D" state indefinitely.

When a hung task is detected, the kernel will print the

current stack trace (which you should report), but the

task will stay in uninterruptible state. If lockdep is

enabled then all held locks will also be reported. This

feature has negligible overhead.

config DEFAULT_HUNG_TASK_TIMEOUT

int "Default timeout for hung task detection (in seconds)"

depends on DETECT_HUNG_TASK

default 120

help

This option controls the default timeout (in seconds) used

to determine when a task has become non-responsive and should

be considered hung.

It can be adjusted at runtime via the kernel.hung_task_timeout_secs

sysctl or by writing a value to

/proc/sys/kernel/hung_task_timeout_secs.

A timeout of 0 disables the check. The default is two minutes.

Keeping the default should be fine in most cases.

config BOOTPARAM_HUNG_TASK_PANIC

bool "Panic (Reboot) On Hung Tasks"

depends on DETECT_HUNG_TASK

help

Say Y here to enable the kernel to panic on "hung tasks",

which are bugs that cause the kernel to leave a task stuck

in uninterruptible "D" state.

The panic can be used in combination with panic_timeout,

to cause the system to reboot automatically after a

hung task has been detected. This feature is useful for

high-availability systems that have uptime guarantees and

where a hung tasks must be resolved ASAP.

Say N if unsure.

config BOOTPARAM_HUNG_TASK_PANIC_VALUE

int

depends on DETECT_HUNG_TASK

range 0 1

default 0 if !BOOTPARAM_HUNG_TASK_PANIC

default 1 if BOOTPARAM_HUNG_TASK_PANIC

config WQ_WATCHDOG

bool "Detect Workqueue Stalls"

depends on DEBUG_KERNEL

help

Say Y here to enable stall detection on workqueues. If a

worker pool doesn't make forward progress on a pending work

item for over a given amount of time, 30s by default, a

warning message is printed along with dump of workqueue

state. This can be configured through kernel parameter

"workqueue.watchdog_thresh" and its sysfs counterpart.

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.

config SCHED_DEBUG

bool "Collect scheduler debugging info"

depends on DEBUG_KERNEL && PROC_FS

default y

help

If you say Y here, the /proc/sched_debug file will be provided