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 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 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 || PROC_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 or procfs.

Thus, the debugfs or procfs 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 && !FRV

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

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 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_WARN_DEPRECATED

bool "Enable __deprecated logic"

default y

help

Enable the __deprecated logic in the kernel build.

Disable this to suppress the "warning: 'foo' is deprecated

(declared at kernel/power/somefile.c:1234)" messages.

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 1280 if (!64BIT && PARISC)

default 1024 if (!64BIT && !PARISC)

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 UNUSED_SYMBOLS

bool "Enable unused/obsolete exported symbols"

default y if X86

help

Unused but exported symbols make the kernel needlessly bigger. For

that reason most of these unused exports will soon be removed. This

option is provided temporarily to provide a transition period in case

some external kernel module needs one of these symbols anyway. If you

encounter such a case in your module, consider if you are actually

using the right API. (rationale: since nobody in the kernel is using

this in a module, there is a pretty good chance it's actually the

wrong interface to use). If you really need the symbol, please send a

mail to the linux kernel mailing list mentioning the symbol and why

you really need it, and what the merge plan to the mainline kernel for

your module is.

config PAGE_OWNER

bool "Track page owner"

depends on DEBUG_KERNEL && STACKTRACE_SUPPORT

select DEBUG_FS

select STACKTRACE

select STACKDEPOT

select PAGE_EXTENSION

help

This keeps track of what call chain is the owner of a page, may

help to find bare alloc_page(s) leaks. Even if you include this

feature on your build, it is disabled in default. You should pass

"page_owner=on" to boot parameter in order to enable it. Eats

a fair amount of memory if enabled. See tools/vm/page_owner_sort.c

for user-space helper.

If unsure, say N.

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_CHECK

bool "Run 'make headers_check' when building vmlinux"

depends on !UML

help

This option will extract the user-visible kernel headers whenever

building the kernel, and will run basic sanity checks on them to

ensure that exported files do not attempt to include files which

were not exported, etc.

If you're making modifications to header files which are

relevant for userspace, say 'Y', and check the headers

exported to $(INSTALL_HDR_PATH) (usually 'usr/include' in

your build tree), to make sure they're suitable.

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 steps 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).

- Run the section mismatch analysis for each module/built-in.o file.

When we run the section mismatch analysis on vmlinux.o, we

lose valuable information about where the mismatch was

introduced.

Running the analysis for each module/built-in.o file

tells where the mismatch happens much closer to the

source. The drawback is that the same mismatch is

reported at least twice.

- Enable verbose reporting from modpost in order to help resolve

the section mismatches that are reported.

config SECTION_MISMATCH_WARN_ONLY

bool "Make section mismatch errors non-fatal"

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

help

config FRAME_POINTER

bool "Compile the kernel with frame pointers"

depends on DEBUG_KERNEL && \

(CRIS || M68K || FRV || UML || \

SUPERH || BLACKFIN || MN10300 || METAG) || \

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.

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 DEBUG_SLAB_LEAK

bool "Memory leak debugging"

depends on DEBUG_SLAB

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_EARLY_LOG_SIZE

int "Maximum kmemleak early log entries"

depends on DEBUG_KMEMLEAK

range 200 40000

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 initialised, an early log buffer is

used to store these actions. If kmemleak reports "early log

buffer exceeded", please increase this value.

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_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.

# Upstream uses $(cc-option, -fsanitize-coverage=trace-pc), which requires

# cc-option support. Here we instead check CC in scripts/Makefile.kcov.

config CC_HAS_SANCOV_TRACE_PC

def_bool ARCH_HAS_KCOV

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.

# Upstream uses $(cc-option, -fsanitize-coverage=trace-cmp), which requires

# cc-option support. Here we instead check CC in scripts/Makefile.kcov.

config KCOV_ENABLE_COMPARISONS

bool "Enable comparison operands collection by KCOV"

depends on KCOV

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 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 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 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

that can help debug the scheduler. The runtime overhead of this

option is minimal.

config SCHED_INFO

bool

default n

config SCHEDSTATS

bool "Collect scheduler statistics"

depends on DEBUG_KERNEL && PROC_FS

select SCHED_INFO

help

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

scheduler and related routines to collect statistics about

scheduler behavior and provide them in /proc/schedstat. These

stats may be useful for both tuning and debugging the scheduler