lib/Kconfig.debug

   1 # SPDX-License-Identifier: GPL-2.0-only
   2 menu "Kernel hacking"
   3
   4 menu "printk and dmesg options"
   5
   6 config PRINTK_TIME
   7         bool "Show timing information on printks"
   8         depends on PRINTK
   9         help
  10           Selecting this option causes time stamps of the printk()
  11           messages to be added to the output of the syslog() system
  12           call and at the console.
  13
  14           The timestamp is always recorded internally, and exported
  15           to /dev/kmsg. This flag just specifies if the timestamp should
  16           be included, not that the timestamp is recorded.
  17
  18           The behavior is also controlled by the kernel command line
  19           parameter printk.time=1. See Documentation/admin-guide/kernel-parameters.rst
  20
  21 config PRINTK_CALLER
  22         bool "Show caller information on printks"
  23         depends on PRINTK
  24         help
  25           Selecting this option causes printk() to add a caller "thread id" (if
  26           in task context) or a caller "processor id" (if not in task context)
  27           to every message.
  28
  29           This option is intended for environments where multiple threads
  30           concurrently call printk() for many times, for it is difficult to
  31           interpret without knowing where these lines (or sometimes individual
  32           line which was divided into multiple lines due to race) came from.
  33
  34           Since toggling after boot makes the code racy, currently there is
  35           no option to enable/disable at the kernel command line parameter or
  36           sysfs interface.
  37
  38 config CONSOLE_LOGLEVEL_DEFAULT
  39         int "Default console loglevel (1-15)"
  40         range 1 15
  41         default "7"
  42         help
  43           Default loglevel to determine what will be printed on the console.
  44
  45           Setting a default here is equivalent to passing in loglevel=<x> in
  46           the kernel bootargs. loglevel=<x> continues to override whatever
  47           value is specified here as well.
  48
  49           Note: This does not affect the log level of un-prefixed printk()
  50           usage in the kernel. That is controlled by the MESSAGE_LOGLEVEL_DEFAULT
  51           option.
  52
  53 config CONSOLE_LOGLEVEL_QUIET
  54         int "quiet console loglevel (1-15)"
  55         range 1 15
  56         default "4"
  57         help
  58           loglevel to use when "quiet" is passed on the kernel commandline.
  59
  60           When "quiet" is passed on the kernel commandline this loglevel
  61           will be used as the loglevel. IOW passing "quiet" will be the
  62           equivalent of passing "loglevel=<CONSOLE_LOGLEVEL_QUIET>"
  63
  64 config MESSAGE_LOGLEVEL_DEFAULT
  65         int "Default message log level (1-7)"
  66         range 1 7
  67         default "4"
  68         help
  69           Default log level for printk statements with no specified priority.
  70
  71           This was hard-coded to KERN_WARNING since at least 2.6.10 but folks
  72           that are auditing their logs closely may want to set it to a lower
  73           priority.
  74
  75           Note: This does not affect what message level gets printed on the console
  76           by default. To change that, use loglevel=<x> in the kernel bootargs,
  77           or pick a different CONSOLE_LOGLEVEL_DEFAULT configuration value.
  78
  79 config BOOT_PRINTK_DELAY
  80         bool "Delay each boot printk message by N milliseconds"
  81         depends on DEBUG_KERNEL && PRINTK && GENERIC_CALIBRATE_DELAY
  82         help
  83           This build option allows you to read kernel boot messages
  84           by inserting a short delay after each one.  The delay is
  85           specified in milliseconds on the kernel command line,
  86           using "boot_delay=N".
  87
  88           It is likely that you would also need to use "lpj=M" to preset
  89           the "loops per jiffie" value.
  90           See a previous boot log for the "lpj" value to use for your
  91           system, and then set "lpj=M" before setting "boot_delay=N".
  92           NOTE:  Using this option may adversely affect SMP systems.
  93           I.e., processors other than the first one may not boot up.
  94           BOOT_PRINTK_DELAY also may cause LOCKUP_DETECTOR to detect
  95           what it believes to be lockup conditions.
  96
  97 config DYNAMIC_DEBUG
  98         bool "Enable dynamic printk() support"
  99         default n
 100         depends on PRINTK
 101         depends on (DEBUG_FS || PROC_FS)
 102         select DYNAMIC_DEBUG_CORE
 103         help
 104
 105           Compiles debug level messages into the kernel, which would not
 106           otherwise be available at runtime. These messages can then be
 107           enabled/disabled based on various levels of scope - per source file,
 108           function, module, format string, and line number. This mechanism
 109           implicitly compiles in all pr_debug() and dev_dbg() calls, which
 110           enlarges the kernel text size by about 2%.
 111
 112           If a source file is compiled with DEBUG flag set, any
 113           pr_debug() calls in it are enabled by default, but can be
 114           disabled at runtime as below.  Note that DEBUG flag is
 115           turned on by many CONFIG_*DEBUG* options.
 116
 117           Usage:
 118
 119           Dynamic debugging is controlled via the 'dynamic_debug/control' file,
 120           which is contained in the 'debugfs' filesystem or procfs.
 121           Thus, the debugfs or procfs filesystem must first be mounted before
 122           making use of this feature.
 123           We refer the control file as: <debugfs>/dynamic_debug/control. This
 124           file contains a list of the debug statements that can be enabled. The
 125           format for each line of the file is:
 126
 127                 filename:lineno [module]function flags format
 128
 129           filename : source file of the debug statement
 130           lineno : line number of the debug statement
 131           module : module that contains the debug statement
 132           function : function that contains the debug statement
 133           flags : '=p' means the line is turned 'on' for printing
 134           format : the format used for the debug statement
 135
 136           From a live system:
 137
 138                 nullarbor:~ # cat <debugfs>/dynamic_debug/control
 139                 # filename:lineno [module]function flags format
 140                 fs/aio.c:222 [aio]__put_ioctx =_ "__put_ioctx:\040freeing\040%p\012"
 141                 fs/aio.c:248 [aio]ioctx_alloc =_ "ENOMEM:\040nr_events\040too\040high\012"
 142                 fs/aio.c:1770 [aio]sys_io_cancel =_ "calling\040cancel\012"
 143
 144           Example usage:
 145
 146                 // enable the message at line 1603 of file svcsock.c
 147                 nullarbor:~ # echo -n 'file svcsock.c line 1603 +p' >
 148                                                 <debugfs>/dynamic_debug/control
 149
 150                 // enable all the messages in file svcsock.c
 151                 nullarbor:~ # echo -n 'file svcsock.c +p' >
 152                                                 <debugfs>/dynamic_debug/control
 153
 154                 // enable all the messages in the NFS server module
 155                 nullarbor:~ # echo -n 'module nfsd +p' >
 156                                                 <debugfs>/dynamic_debug/control
 157
 158                 // enable all 12 messages in the function svc_process()
 159                 nullarbor:~ # echo -n 'func svc_process +p' >
 160                                                 <debugfs>/dynamic_debug/control
 161
 162                 // disable all 12 messages in the function svc_process()
 163                 nullarbor:~ # echo -n 'func svc_process -p' >
 164                                                 <debugfs>/dynamic_debug/control
 165
 166           See Documentation/admin-guide/dynamic-debug-howto.rst for additional
 167           information.
 168
 169 config DYNAMIC_DEBUG_CORE
 170         bool "Enable core function of dynamic debug support"
 171         depends on PRINTK
 172         depends on (DEBUG_FS || PROC_FS)
 173         help
 174           Enable core functional support of dynamic debug. It is useful
 175           when you want to tie dynamic debug to your kernel modules with
 176           DYNAMIC_DEBUG_MODULE defined for each of them, especially for
 177           the case of embedded system where the kernel image size is
 178           sensitive for people.
 179
 180 config SYMBOLIC_ERRNAME
 181         bool "Support symbolic error names in printf"
 182         default y if PRINTK
 183         help
 184           If you say Y here, the kernel's printf implementation will
 185           be able to print symbolic error names such as ENOSPC instead
 186           of the number 28. It makes the kernel image slightly larger
 187           (about 3KB), but can make the kernel logs easier to read.
 188
 189 config DEBUG_BUGVERBOSE
 190         bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT
 191         depends on BUG && (GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE)
 192         default y
 193         help
 194           Say Y here to make BUG() panics output the file name and line number
 195           of the BUG call as well as the EIP and oops trace.  This aids
 196           debugging but costs about 70-100K of memory.
 197
 198 endmenu # "printk and dmesg options"
 199
 200 menu "Compile-time checks and compiler options"
 201
 202 config DEBUG_INFO
 203         bool "Compile the kernel with debug info"
 204         depends on DEBUG_KERNEL && !COMPILE_TEST
 205         help
 206           If you say Y here the resulting kernel image will include
 207           debugging info resulting in a larger kernel image.
 208           This adds debug symbols to the kernel and modules (gcc -g), and
 209           is needed if you intend to use kernel crashdump or binary object
 210           tools like crash, kgdb, LKCD, gdb, etc on the kernel.
 211           Say Y here only if you plan to debug the kernel.
 212
 213           If unsure, say N.
 214
 215 if DEBUG_INFO
 216
 217 config DEBUG_INFO_REDUCED
 218         bool "Reduce debugging information"
 219         help
 220           If you say Y here gcc is instructed to generate less debugging
 221           information for structure types. This means that tools that
 222           need full debugging information (like kgdb or systemtap) won't
 223           be happy. But if you merely need debugging information to
 224           resolve line numbers there is no loss. Advantage is that
 225           build directory object sizes shrink dramatically over a full
 226           DEBUG_INFO build and compile times are reduced too.
 227           Only works with newer gcc versions.
 228
 229 config DEBUG_INFO_COMPRESSED
 230         bool "Compressed debugging information"
 231         depends on $(cc-option,-gz=zlib)
 232         depends on $(ld-option,--compress-debug-sections=zlib)
 233         help
 234           Compress the debug information using zlib.  Requires GCC 5.0+ or Clang
 235           5.0+, binutils 2.26+, and zlib.
 236
 237           Users of dpkg-deb via scripts/package/builddeb may find an increase in
 238           size of their debug .deb packages with this config set, due to the
 239           debug info being compressed with zlib, then the object files being
 240           recompressed with a different compression scheme. But this is still
 241           preferable to setting $KDEB_COMPRESS to "none" which would be even
 242           larger.
 243
 244 config DEBUG_INFO_SPLIT
 245         bool "Produce split debuginfo in .dwo files"
 246         depends on $(cc-option,-gsplit-dwarf)
 247         help
 248           Generate debug info into separate .dwo files. This significantly
 249           reduces the build directory size for builds with DEBUG_INFO,
 250           because it stores the information only once on disk in .dwo
 251           files instead of multiple times in object files and executables.
 252           In addition the debug information is also compressed.
 253
 254           Requires recent gcc (4.7+) and recent gdb/binutils.
 255           Any tool that packages or reads debug information would need
 256           to know about the .dwo files and include them.
 257           Incompatible with older versions of ccache.
 258
 259 choice
 260         prompt "DWARF version"
 261         help
 262           Which version of DWARF debug info to emit.
 263
 264 config DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT
 265         bool "Rely on the toolchain's implicit default DWARF version"
 266         help
 267           The implicit default version of DWARF debug info produced by a
 268           toolchain changes over time.
 269
 270           This can break consumers of the debug info that haven't upgraded to
 271           support newer revisions, and prevent testing newer versions, but
 272           those should be less common scenarios.
 273
 274           If unsure, say Y.
 275
 276 config DEBUG_INFO_DWARF4
 277         bool "Generate DWARF Version 4 debuginfo"
 278         help
 279           Generate DWARF v4 debug info. This requires gcc 4.5+ and gdb 7.0+.
 280
 281           If you have consumers of DWARF debug info that are not ready for
 282           newer revisions of DWARF, you may wish to choose this or have your
 283           config select this.
 284
 285 endchoice # "DWARF version"
 286
 287 config DEBUG_INFO_BTF
 288         bool "Generate BTF typeinfo"
 289         depends on !DEBUG_INFO_SPLIT && !DEBUG_INFO_REDUCED
 290         depends on !GCC_PLUGIN_RANDSTRUCT || COMPILE_TEST
 291         help
 292           Generate deduplicated BTF type information from DWARF debug info.
 293           Turning this on expects presence of pahole tool, which will convert
 294           DWARF type info into equivalent deduplicated BTF type info.
 295
 296 config PAHOLE_HAS_SPLIT_BTF
 297         def_bool $(success, test `$(PAHOLE) --version | sed -E 's/v([0-9]+)\.([0-9]+)/\1\2/'` -ge "119")
 298
 299 config DEBUG_INFO_BTF_MODULES
 300         def_bool y
 301         depends on DEBUG_INFO_BTF && MODULES && PAHOLE_HAS_SPLIT_BTF
 302         help
 303           Generate compact split BTF type information for kernel modules.
 304
 305 config GDB_SCRIPTS
 306         bool "Provide GDB scripts for kernel debugging"
 307         help
 308           This creates the required links to GDB helper scripts in the
 309           build directory. If you load vmlinux into gdb, the helper
 310           scripts will be automatically imported by gdb as well, and
 311           additional functions are available to analyze a Linux kernel
 312           instance. See Documentation/dev-tools/gdb-kernel-debugging.rst
 313           for further details.
 314
 315 endif # DEBUG_INFO
 316
 317 config FRAME_WARN
 318         int "Warn for stack frames larger than"
 319         range 0 8192
 320         default 2048 if GCC_PLUGIN_LATENT_ENTROPY
 321         default 1280 if (!64BIT && PARISC)
 322         default 1024 if (!64BIT && !PARISC)
 323         default 2048 if 64BIT
 324         help
 325           Tell gcc to warn at build time for stack frames larger than this.
 326           Setting this too low will cause a lot of warnings.
 327           Setting it to 0 disables the warning.
 328
 329 config STRIP_ASM_SYMS
 330         bool "Strip assembler-generated symbols during link"
 331         default n
 332         help
 333           Strip internal assembler-generated symbols during a link (symbols
 334           that look like '.Lxxx') so they don't pollute the output of
 335           get_wchan() and suchlike.
 336
 337 config READABLE_ASM
 338         bool "Generate readable assembler code"
 339         depends on DEBUG_KERNEL
 340         help
 341           Disable some compiler optimizations that tend to generate human unreadable
 342           assembler output. This may make the kernel slightly slower, but it helps
 343           to keep kernel developers who have to stare a lot at assembler listings
 344           sane.
 345
 346 config HEADERS_INSTALL
 347         bool "Install uapi headers to usr/include"
 348         depends on !UML
 349         help
 350           This option will install uapi headers (headers exported to user-space)
 351           into the usr/include directory for use during the kernel build.
 352           This is unneeded for building the kernel itself, but needed for some
 353           user-space program samples. It is also needed by some features such
 354           as uapi header sanity checks.
 355
 356 config DEBUG_SECTION_MISMATCH
 357         bool "Enable full Section mismatch analysis"
 358         help
 359           The section mismatch analysis checks if there are illegal
 360           references from one section to another section.
 361           During linktime or runtime, some sections are dropped;
 362           any use of code/data previously in these sections would
 363           most likely result in an oops.
 364           In the code, functions and variables are annotated with
 365           __init,, etc. (see the full list in include/linux/init.h),
 366           which results in the code/data being placed in specific sections.
 367           The section mismatch analysis is always performed after a full
 368           kernel build, and enabling this option causes the following
 369           additional step to occur:
 370           - Add the option -fno-inline-functions-called-once to gcc commands.
 371             When inlining a function annotated with __init in a non-init
 372             function, we would lose the section information and thus
 373             the analysis would not catch the illegal reference.
 374             This option tells gcc to inline less (but it does result in
 375             a larger kernel).
 376
 377 config SECTION_MISMATCH_WARN_ONLY
 378         bool "Make section mismatch errors non-fatal"
 379         default y
 380         help
 381           If you say N here, the build process will fail if there are any
 382           section mismatch, instead of just throwing warnings.
 383
 384           If unsure, say Y.
 385
 386 config DEBUG_FORCE_FUNCTION_ALIGN_32B
 387         bool "Force all function address 32B aligned" if EXPERT
 388         help
 389           There are cases that a commit from one domain changes the function
 390           address alignment of other domains, and cause magic performance
 391           bump (regression or improvement). Enable this option will help to
 392           verify if the bump is caused by function alignment changes, while
 393           it will slightly increase the kernel size and affect icache usage.
 394
 395           It is mainly for debug and performance tuning use.
 396
 397 #
 398 # Select this config option from the architecture Kconfig, if it
 399 # is preferred to always offer frame pointers as a config
 400 # option on the architecture (regardless of KERNEL_DEBUG):
 401 #
 402 config ARCH_WANT_FRAME_POINTERS
 403         bool
 404
 405 config FRAME_POINTER
 406         bool "Compile the kernel with frame pointers"
 407         depends on DEBUG_KERNEL && (M68K || UML || SUPERH) || ARCH_WANT_FRAME_POINTERS
 408         default y if (DEBUG_INFO && UML) || ARCH_WANT_FRAME_POINTERS
 409         help
 410           If you say Y here the resulting kernel image will be slightly
 411           larger and slower, but it gives very useful debugging information
 412           in case of kernel bugs. (precise oopses/stacktraces/warnings)
 413
 414 config STACK_VALIDATION
 415         bool "Compile-time stack metadata validation"
 416         depends on HAVE_STACK_VALIDATION
 417         default n
 418         help
 419           Add compile-time checks to validate stack metadata, including frame
 420           pointers (if CONFIG_FRAME_POINTER is enabled).  This helps ensure
 421           that runtime stack traces are more reliable.
 422
 423           This is also a prerequisite for generation of ORC unwind data, which
 424           is needed for CONFIG_UNWINDER_ORC.
 425
 426           For more information, see
 427           tools/objtool/Documentation/stack-validation.txt.
 428
 429 config VMLINUX_VALIDATION
 430         bool
 431         depends on STACK_VALIDATION && DEBUG_ENTRY && !PARAVIRT
 432         default y
 433
 434 config DEBUG_FORCE_WEAK_PER_CPU
 435         bool "Force weak per-cpu definitions"
 436         depends on DEBUG_KERNEL
 437         help
 438           s390 and alpha require percpu variables in modules to be
 439           defined weak to work around addressing range issue which
 440           puts the following two restrictions on percpu variable
 441           definitions.
 442
 443           1. percpu symbols must be unique whether static or not
 444           2. percpu variables can't be defined inside a function
 445
 446           To ensure that generic code follows the above rules, this
 447           option forces all percpu variables to be defined as weak.
 448
 449 endmenu # "Compiler options"
 450
 451 menu "Generic Kernel Debugging Instruments"
 452
 453 config MAGIC_SYSRQ
 454         bool "Magic SysRq key"
 455         depends on !UML
 456         help
 457           If you say Y here, you will have some control over the system even
 458           if the system crashes for example during kernel debugging (e.g., you
 459           will be able to flush the buffer cache to disk, reboot the system
 460           immediately or dump some status information). This is accomplished
 461           by pressing various keys while holding SysRq (Alt+PrintScreen). It
 462           also works on a serial console (on PC hardware at least), if you
 463           send a BREAK and then within 5 seconds a command keypress. The
 464           keys are documented in <file:Documentation/admin-guide/sysrq.rst>.
 465           Don't say Y unless you really know what this hack does.
 466
 467 config MAGIC_SYSRQ_DEFAULT_ENABLE
 468         hex "Enable magic SysRq key functions by default"
 469         depends on MAGIC_SYSRQ
 470         default 0x1
 471         help
 472           Specifies which SysRq key functions are enabled by default.
 473           This may be set to 1 or 0 to enable or disable them all, or
 474           to a bitmask as described in Documentation/admin-guide/sysrq.rst.
 475
 476 config MAGIC_SYSRQ_SERIAL
 477         bool "Enable magic SysRq key over serial"
 478         depends on MAGIC_SYSRQ
 479         default y
 480         help
 481           Many embedded boards have a disconnected TTL level serial which can
 482           generate some garbage that can lead to spurious false sysrq detects.
 483           This option allows you to decide whether you want to enable the
 484           magic SysRq key.
 485
 486 config MAGIC_SYSRQ_SERIAL_SEQUENCE
 487         string "Char sequence that enables magic SysRq over serial"
 488         depends on MAGIC_SYSRQ_SERIAL
 489         default ""
 490         help
 491           Specifies a sequence of characters that can follow BREAK to enable
 492           SysRq on a serial console.
 493
 494           If unsure, leave an empty string and the option will not be enabled.
 495
 496 config DEBUG_FS
 497         bool "Debug Filesystem"
 498         help
 499           debugfs is a virtual file system that kernel developers use to put
 500           debugging files into.  Enable this option to be able to read and
 501           write to these files.
 502
 503           For detailed documentation on the debugfs API, see
 504           Documentation/filesystems/.
 505
 506           If unsure, say N.
 507
 508 choice
 509         prompt "Debugfs default access"
 510         depends on DEBUG_FS
 511         default DEBUG_FS_ALLOW_ALL
 512         help
 513           This selects the default access restrictions for debugfs.
 514           It can be overridden with kernel command line option
 515           debugfs=[on,no-mount,off]. The restrictions apply for API access
 516           and filesystem registration.
 517
 518 config DEBUG_FS_ALLOW_ALL
 519         bool "Access normal"
 520         help
 521           No restrictions apply. Both API and filesystem registration
 522           is on. This is the normal default operation.
 523
 524 config DEBUG_FS_DISALLOW_MOUNT
 525         bool "Do not register debugfs as filesystem"
 526         help
 527           The API is open but filesystem is not loaded. Clients can still do
 528           their work and read with debug tools that do not need
 529           debugfs filesystem.
 530
 531 config DEBUG_FS_ALLOW_NONE
 532         bool "No access"
 533         help
 534           Access is off. Clients get -PERM when trying to create nodes in
 535           debugfs tree and debugfs is not registered as a filesystem.
 536           Client can then back-off or continue without debugfs access.
 537
 538 endchoice
 539
 540 source "lib/Kconfig.kgdb"
 541 source "lib/Kconfig.ubsan"
 542 source "lib/Kconfig.kcsan"
 543
 544 endmenu
 545
 546 config DEBUG_KERNEL
 547         bool "Kernel debugging"
 548         help
 549           Say Y here if you are developing drivers or trying to debug and
 550           identify kernel problems.
 551
 552 config DEBUG_MISC
 553         bool "Miscellaneous debug code"
 554         default DEBUG_KERNEL
 555         depends on DEBUG_KERNEL
 556         help
 557           Say Y here if you need to enable miscellaneous debug code that should
 558           be under a more specific debug option but isn't.
 559
 560
 561 menu "Memory Debugging"
 562
 563 source "mm/Kconfig.debug"
 564
 565 config DEBUG_OBJECTS
 566         bool "Debug object operations"
 567         depends on DEBUG_KERNEL
 568         help
 569           If you say Y here, additional code will be inserted into the
 570           kernel to track the life time of various objects and validate
 571           the operations on those objects.
 572
 573 config DEBUG_OBJECTS_SELFTEST
 574         bool "Debug objects selftest"
 575         depends on DEBUG_OBJECTS
 576         help
 577           This enables the selftest of the object debug code.
 578
 579 config DEBUG_OBJECTS_FREE
 580         bool "Debug objects in freed memory"
 581         depends on DEBUG_OBJECTS
 582         help
 583           This enables checks whether a k/v free operation frees an area
 584           which contains an object which has not been deactivated
 585           properly. This can make kmalloc/kfree-intensive workloads
 586           much slower.
 587
 588 config DEBUG_OBJECTS_TIMERS
 589         bool "Debug timer objects"
 590         depends on DEBUG_OBJECTS
 591         help
 592           If you say Y here, additional code will be inserted into the
 593           timer routines to track the life time of timer objects and
 594           validate the timer operations.
 595
 596 config DEBUG_OBJECTS_WORK
 597         bool "Debug work objects"
 598         depends on DEBUG_OBJECTS
 599         help
 600           If you say Y here, additional code will be inserted into the
 601           work queue routines to track the life time of work objects and
 602           validate the work operations.
 603
 604 config DEBUG_OBJECTS_RCU_HEAD
 605         bool "Debug RCU callbacks objects"
 606         depends on DEBUG_OBJECTS
 607         help
 608           Enable this to turn on debugging of RCU list heads (call_rcu() usage).
 609
 610 config DEBUG_OBJECTS_PERCPU_COUNTER
 611         bool "Debug percpu counter objects"
 612         depends on DEBUG_OBJECTS
 613         help
 614           If you say Y here, additional code will be inserted into the
 615           percpu counter routines to track the life time of percpu counter
 616           objects and validate the percpu counter operations.
 617
 618 config DEBUG_OBJECTS_ENABLE_DEFAULT
 619         int "debug_objects bootup default value (0-1)"
 620         range 0 1
 621         default "1"
 622         depends on DEBUG_OBJECTS
 623         help
 624           Debug objects boot parameter default value
 625
 626 config DEBUG_SLAB
 627         bool "Debug slab memory allocations"
 628         depends on DEBUG_KERNEL && SLAB
 629         help
 630           Say Y here to have the kernel do limited verification on memory
 631           allocation as well as poisoning memory on free to catch use of freed
 632           memory. This can make kmalloc/kfree-intensive workloads much slower.
 633
 634 config SLUB_DEBUG_ON
 635         bool "SLUB debugging on by default"
 636         depends on SLUB && SLUB_DEBUG
 637         default n
 638         help
 639           Boot with debugging on by default. SLUB boots by default with
 640           the runtime debug capabilities switched off. Enabling this is
 641           equivalent to specifying the "slub_debug" parameter on boot.
 642           There is no support for more fine grained debug control like
 643           possible with slub_debug=xxx. SLUB debugging may be switched
 644           off in a kernel built with CONFIG_SLUB_DEBUG_ON by specifying
 645           "slub_debug=-".
 646
 647 config SLUB_STATS
 648         default n
 649         bool "Enable SLUB performance statistics"
 650         depends on SLUB && SYSFS
 651         help
 652           SLUB statistics are useful to debug SLUBs allocation behavior in
 653           order find ways to optimize the allocator. This should never be
 654           enabled for production use since keeping statistics slows down
 655           the allocator by a few percentage points. The slabinfo command
 656           supports the determination of the most active slabs to figure
 657           out which slabs are relevant to a particular load.
 658           Try running: slabinfo -DA
 659
 660 config HAVE_DEBUG_KMEMLEAK
 661         bool
 662
 663 config DEBUG_KMEMLEAK
 664         bool "Kernel memory leak detector"
 665         depends on DEBUG_KERNEL && HAVE_DEBUG_KMEMLEAK
 666         select DEBUG_FS
 667         select STACKTRACE if STACKTRACE_SUPPORT
 668         select KALLSYMS
 669         select CRC32
 670         help
 671           Say Y here if you want to enable the memory leak
 672           detector. The memory allocation/freeing is traced in a way
 673           similar to the Boehm's conservative garbage collector, the
 674           difference being that the orphan objects are not freed but
 675           only shown in /sys/kernel/debug/kmemleak. Enabling this
 676           feature will introduce an overhead to memory
 677           allocations. See Documentation/dev-tools/kmemleak.rst for more
 678           details.
 679
 680           Enabling DEBUG_SLAB or SLUB_DEBUG may increase the chances
 681           of finding leaks due to the slab objects poisoning.
 682
 683           In order to access the kmemleak file, debugfs needs to be
 684           mounted (usually at /sys/kernel/debug).
 685
 686 config DEBUG_KMEMLEAK_MEM_POOL_SIZE
 687         int "Kmemleak memory pool size"
 688         depends on DEBUG_KMEMLEAK
 689         range 200 1000000
 690         default 16000
 691         help
 692           Kmemleak must track all the memory allocations to avoid
 693           reporting false positives. Since memory may be allocated or
 694           freed before kmemleak is fully initialised, use a static pool
 695           of metadata objects to track such callbacks. After kmemleak is
 696           fully initialised, this memory pool acts as an emergency one
 697           if slab allocations fail.
 698
 699 config DEBUG_KMEMLEAK_TEST
 700         tristate "Simple test for the kernel memory leak detector"
 701         depends on DEBUG_KMEMLEAK && m
 702         help
 703           This option enables a module that explicitly leaks memory.
 704
 705           If unsure, say N.
 706
 707 config DEBUG_KMEMLEAK_DEFAULT_OFF
 708         bool "Default kmemleak to off"
 709         depends on DEBUG_KMEMLEAK
 710         help
 711           Say Y here to disable kmemleak by default. It can then be enabled
 712           on the command line via kmemleak=on.
 713
 714 config DEBUG_KMEMLEAK_AUTO_SCAN
 715         bool "Enable kmemleak auto scan thread on boot up"
 716         default y
 717         depends on DEBUG_KMEMLEAK
 718         help
 719           Depending on the cpu, kmemleak scan may be cpu intensive and can
 720           stall user tasks at times. This option enables/disables automatic
 721           kmemleak scan at boot up.
 722
 723           Say N here to disable kmemleak auto scan thread to stop automatic
 724           scanning. Disabling this option disables automatic reporting of
 725           memory leaks.
 726
 727           If unsure, say Y.
 728
 729 config DEBUG_STACK_USAGE
 730         bool "Stack utilization instrumentation"
 731         depends on DEBUG_KERNEL && !IA64
 732         help
 733           Enables the display of the minimum amount of free stack which each
 734           task has ever had available in the sysrq-T and sysrq-P debug output.
 735
 736           This option will slow down process creation somewhat.
 737
 738 config SCHED_STACK_END_CHECK
 739         bool "Detect stack corruption on calls to schedule()"
 740         depends on DEBUG_KERNEL
 741         default n
 742         help
 743           This option checks for a stack overrun on calls to schedule().
 744           If the stack end location is found to be over written always panic as
 745           the content of the corrupted region can no longer be trusted.
 746           This is to ensure no erroneous behaviour occurs which could result in
 747           data corruption or a sporadic crash at a later stage once the region
 748           is examined. The runtime overhead introduced is minimal.
 749
 750 config ARCH_HAS_DEBUG_VM_PGTABLE
 751         bool
 752         help
 753           An architecture should select this when it can successfully
 754           build and run DEBUG_VM_PGTABLE.
 755
 756 config DEBUG_VM
 757         bool "Debug VM"
 758         depends on DEBUG_KERNEL
 759         help
 760           Enable this to turn on extended checks in the virtual-memory system
 761           that may impact performance.
 762
 763           If unsure, say N.
 764
 765 config DEBUG_VM_VMACACHE
 766         bool "Debug VMA caching"
 767         depends on DEBUG_VM
 768         help
 769           Enable this to turn on VMA caching debug information. Doing so
 770           can cause significant overhead, so only enable it in non-production
 771           environments.
 772
 773           If unsure, say N.
 774
 775 config DEBUG_VM_RB
 776         bool "Debug VM red-black trees"
 777         depends on DEBUG_VM
 778         help
 779           Enable VM red-black tree debugging information and extra validations.
 780
 781           If unsure, say N.
 782
 783 config DEBUG_VM_PGFLAGS
 784         bool "Debug page-flags operations"
 785         depends on DEBUG_VM
 786         help
 787           Enables extra validation on page flags operations.
 788
 789           If unsure, say N.
 790
 791 config DEBUG_VM_PGTABLE
 792         bool "Debug arch page table for semantics compliance"
 793         depends on MMU
 794         depends on ARCH_HAS_DEBUG_VM_PGTABLE
 795         default y if DEBUG_VM
 796         help
 797           This option provides a debug method which can be used to test
 798           architecture page table helper functions on various platforms in
 799           verifying if they comply with expected generic MM semantics. This
 800           will help architecture code in making sure that any changes or
 801           new additions of these helpers still conform to expected
 802           semantics of the generic MM. Platforms will have to opt in for
 803           this through ARCH_HAS_DEBUG_VM_PGTABLE.
 804
 805           If unsure, say N.
 806
 807 config ARCH_HAS_DEBUG_VIRTUAL
 808         bool
 809
 810 config DEBUG_VIRTUAL
 811         bool "Debug VM translations"
 812         depends on DEBUG_KERNEL && ARCH_HAS_DEBUG_VIRTUAL
 813         help
 814           Enable some costly sanity checks in virtual to page code. This can
 815           catch mistakes with virt_to_page() and friends.
 816
 817           If unsure, say N.
 818
 819 config DEBUG_NOMMU_REGIONS
 820         bool "Debug the global anon/private NOMMU mapping region tree"
 821         depends on DEBUG_KERNEL && !MMU
 822         help
 823           This option causes the global tree of anonymous and private mapping
 824           regions to be regularly checked for invalid topology.
 825
 826 config DEBUG_MEMORY_INIT
 827         bool "Debug memory initialisation" if EXPERT
 828         default !EXPERT
 829         help
 830           Enable this for additional checks during memory initialisation.
 831           The sanity checks verify aspects of the VM such as the memory model
 832           and other information provided by the architecture. Verbose
 833           information will be printed at KERN_DEBUG loglevel depending
 834           on the mminit_loglevel= command-line option.
 835
 836           If unsure, say Y
 837
 838 config MEMORY_NOTIFIER_ERROR_INJECT
 839         tristate "Memory hotplug notifier error injection module"
 840         depends on MEMORY_HOTPLUG_SPARSE && NOTIFIER_ERROR_INJECTION
 841         help
 842           This option provides the ability to inject artificial errors to
 843           memory hotplug notifier chain callbacks.  It is controlled through
 844           debugfs interface under /sys/kernel/debug/notifier-error-inject/memory
 845
 846           If the notifier call chain should be failed with some events
 847           notified, write the error code to "actions/<notifier event>/error".
 848
 849           Example: Inject memory hotplug offline error (-12 == -ENOMEM)
 850
 851           # cd /sys/kernel/debug/notifier-error-inject/memory
 852           # echo -12 > actions/MEM_GOING_OFFLINE/error
 853           # echo offline > /sys/devices/system/memory/memoryXXX/state
 854           bash: echo: write error: Cannot allocate memory
 855
 856           To compile this code as a module, choose M here: the module will
 857           be called memory-notifier-error-inject.
 858
 859           If unsure, say N.
 860
 861 config DEBUG_PER_CPU_MAPS
 862         bool "Debug access to per_cpu maps"
 863         depends on DEBUG_KERNEL
 864         depends on SMP
 865         help
 866           Say Y to verify that the per_cpu map being accessed has
 867           been set up. This adds a fair amount of code to kernel memory
 868           and decreases performance.
 869
 870           Say N if unsure.
 871
 872 config DEBUG_KMAP_LOCAL
 873         bool "Debug kmap_local temporary mappings"
 874         depends on DEBUG_KERNEL && KMAP_LOCAL
 875         help
 876           This option enables additional error checking for the kmap_local
 877           infrastructure.  Disable for production use.
 878
 879 config ARCH_SUPPORTS_KMAP_LOCAL_FORCE_MAP
 880         bool
 881
 882 config DEBUG_KMAP_LOCAL_FORCE_MAP
 883         bool "Enforce kmap_local temporary mappings"
 884         depends on DEBUG_KERNEL && ARCH_SUPPORTS_KMAP_LOCAL_FORCE_MAP
 885         select KMAP_LOCAL
 886         select DEBUG_KMAP_LOCAL
 887         help
 888           This option enforces temporary mappings through the kmap_local
 889           mechanism for non-highmem pages and on non-highmem systems.
 890           Disable this for production systems!
 891
 892 config DEBUG_HIGHMEM
 893         bool "Highmem debugging"
 894         depends on DEBUG_KERNEL && HIGHMEM
 895         select DEBUG_KMAP_LOCAL_FORCE_MAP if ARCH_SUPPORTS_KMAP_LOCAL_FORCE_MAP
 896         select DEBUG_KMAP_LOCAL
 897         help
 898           This option enables additional error checking for high memory
 899           systems.  Disable for production systems.
 900
 901 config HAVE_DEBUG_STACKOVERFLOW
 902         bool
 903
 904 config DEBUG_STACKOVERFLOW
 905         bool "Check for stack overflows"
 906         depends on DEBUG_KERNEL && HAVE_DEBUG_STACKOVERFLOW
 907         help
 908           Say Y here if you want to check for overflows of kernel, IRQ
 909           and exception stacks (if your architecture uses them). This
 910           option will show detailed messages if free stack space drops
 911           below a certain limit.
 912
 913           These kinds of bugs usually occur when call-chains in the
 914           kernel get too deep, especially when interrupts are
 915           involved.
 916
 917           Use this in cases where you see apparently random memory
 918           corruption, especially if it appears in 'struct thread_info'
 919
 920           If in doubt, say "N".
 921
 922 source "lib/Kconfig.kasan"
 923
 924 endmenu # "Memory Debugging"
 925
 926 config DEBUG_SHIRQ
 927         bool "Debug shared IRQ handlers"
 928         depends on DEBUG_KERNEL
 929         help
 930           Enable this to generate a spurious interrupt just before a shared
 931           interrupt handler is deregistered (generating one when registering
 932           is currently disabled). Drivers need to handle this correctly. Some
 933           don't and need to be caught.
 934
 935 menu "Debug Oops, Lockups and Hangs"
 936
 937 config PANIC_ON_OOPS
 938         bool "Panic on Oops"
 939         help
 940           Say Y here to enable the kernel to panic when it oopses. This
 941           has the same effect as setting oops=panic on the kernel command
 942           line.
 943
 944           This feature is useful to ensure that the kernel does not do
 945           anything erroneous after an oops which could result in data
 946           corruption or other issues.
 947
 948           Say N if unsure.
 949
 950 config PANIC_ON_OOPS_VALUE
 951         int
 952         range 0 1
 953         default 0 if !PANIC_ON_OOPS
 954         default 1 if PANIC_ON_OOPS
 955
 956 config PANIC_TIMEOUT
 957         int "panic timeout"
 958         default 0
 959         help
 960           Set the timeout value (in seconds) until a reboot occurs when
 961           the kernel panics. If n = 0, then we wait forever. A timeout
 962           value n > 0 will wait n seconds before rebooting, while a timeout
 963           value n < 0 will reboot immediately.
 964
 965 config LOCKUP_DETECTOR
 966         bool
 967
 968 config SOFTLOCKUP_DETECTOR
 969         bool "Detect Soft Lockups"
 970         depends on DEBUG_KERNEL && !S390
 971         select LOCKUP_DETECTOR
 972         help
 973           Say Y here to enable the kernel to act as a watchdog to detect
 974           soft lockups.
 975
 976           Softlockups are bugs that cause the kernel to loop in kernel
 977           mode for more than 20 seconds, without giving other tasks a
 978           chance to run.  The current stack trace is displayed upon
 979           detection and the system will stay locked up.
 980
 981 config BOOTPARAM_SOFTLOCKUP_PANIC
 982         bool "Panic (Reboot) On Soft Lockups"
 983         depends on SOFTLOCKUP_DETECTOR
 984         help
 985           Say Y here to enable the kernel to panic on "soft lockups",
 986           which are bugs that cause the kernel to loop in kernel
 987           mode for more than 20 seconds (configurable using the watchdog_thresh
 988           sysctl), without giving other tasks a chance to run.
 989
 990           The panic can be used in combination with panic_timeout,
 991           to cause the system to reboot automatically after a
 992           lockup has been detected. This feature is useful for
 993           high-availability systems that have uptime guarantees and
 994           where a lockup must be resolved ASAP.
 995
 996           Say N if unsure.
 997
 998 config BOOTPARAM_SOFTLOCKUP_PANIC_VALUE
 999         int
1000         depends on SOFTLOCKUP_DETECTOR
1001         range 0 1
1002         default 0 if !BOOTPARAM_SOFTLOCKUP_PANIC
1003         default 1 if BOOTPARAM_SOFTLOCKUP_PANIC
1004
1005 config HARDLOCKUP_DETECTOR_PERF
1006         bool
1007         select SOFTLOCKUP_DETECTOR
1008
1009 #
1010 # Enables a timestamp based low pass filter to compensate for perf based
1011 # hard lockup detection which runs too fast due to turbo modes.
1012 #
1013 config HARDLOCKUP_CHECK_TIMESTAMP
1014         bool
1015
1016 #
1017 # arch/ can define HAVE_HARDLOCKUP_DETECTOR_ARCH to provide their own hard
1018 # lockup detector rather than the perf based detector.
1019 #
1020 config HARDLOCKUP_DETECTOR
1021         bool "Detect Hard Lockups"
1022         depends on DEBUG_KERNEL && !S390
1023         depends on HAVE_HARDLOCKUP_DETECTOR_PERF || HAVE_HARDLOCKUP_DETECTOR_ARCH
1024         select LOCKUP_DETECTOR
1025         select HARDLOCKUP_DETECTOR_PERF if HAVE_HARDLOCKUP_DETECTOR_PERF
1026         select HARDLOCKUP_DETECTOR_ARCH if HAVE_HARDLOCKUP_DETECTOR_ARCH
1027         help
1028           Say Y here to enable the kernel to act as a watchdog to detect
1029           hard lockups.
1030
1031           Hardlockups are bugs that cause the CPU to loop in kernel mode
1032           for more than 10 seconds, without letting other interrupts have a
1033           chance to run.  The current stack trace is displayed upon detection
1034           and the system will stay locked up.
1035
1036 config BOOTPARAM_HARDLOCKUP_PANIC
1037         bool "Panic (Reboot) On Hard Lockups"
1038         depends on HARDLOCKUP_DETECTOR
1039         help
1040           Say Y here to enable the kernel to panic on "hard lockups",
1041           which are bugs that cause the kernel to loop in kernel
1042           mode with interrupts disabled for more than 10 seconds (configurable
1043           using the watchdog_thresh sysctl).
1044
1045           Say N if unsure.
1046
1047 config BOOTPARAM_HARDLOCKUP_PANIC_VALUE
1048         int
1049         depends on HARDLOCKUP_DETECTOR
1050         range 0 1
1051         default 0 if !BOOTPARAM_HARDLOCKUP_PANIC
1052         default 1 if BOOTPARAM_HARDLOCKUP_PANIC
1053
1054 config DETECT_HUNG_TASK
1055         bool "Detect Hung Tasks"
1056         depends on DEBUG_KERNEL
1057         default SOFTLOCKUP_DETECTOR
1058         help
1059           Say Y here to enable the kernel to detect "hung tasks",
1060           which are bugs that cause the task to be stuck in
1061           uninterruptible "D" state indefinitely.
1062
1063           When a hung task is detected, the kernel will print the
1064           current stack trace (which you should report), but the
1065           task will stay in uninterruptible state. If lockdep is
1066           enabled then all held locks will also be reported. This
1067           feature has negligible overhead.
1068
1069 config DEFAULT_HUNG_TASK_TIMEOUT
1070         int "Default timeout for hung task detection (in seconds)"
1071         depends on DETECT_HUNG_TASK
1072         default 120
1073         help
1074           This option controls the default timeout (in seconds) used
1075           to determine when a task has become non-responsive and should
1076           be considered hung.
1077
1078           It can be adjusted at runtime via the kernel.hung_task_timeout_secs
1079           sysctl or by writing a value to
1080           /proc/sys/kernel/hung_task_timeout_secs.
1081
1082           A timeout of 0 disables the check.  The default is two minutes.
1083           Keeping the default should be fine in most cases.
1084
1085 config BOOTPARAM_HUNG_TASK_PANIC
1086         bool "Panic (Reboot) On Hung Tasks"
1087         depends on DETECT_HUNG_TASK
1088         help
1089           Say Y here to enable the kernel to panic on "hung tasks",
1090           which are bugs that cause the kernel to leave a task stuck
1091           in uninterruptible "D" state.
1092
1093           The panic can be used in combination with panic_timeout,
1094           to cause the system to reboot automatically after a
1095           hung task has been detected. This feature is useful for
1096           high-availability systems that have uptime guarantees and
1097           where a hung tasks must be resolved ASAP.
1098
1099           Say N if unsure.
1100
1101 config BOOTPARAM_HUNG_TASK_PANIC_VALUE
1102         int
1103         depends on DETECT_HUNG_TASK
1104         range 0 1
1105         default 0 if !BOOTPARAM_HUNG_TASK_PANIC
1106         default 1 if BOOTPARAM_HUNG_TASK_PANIC
1107
1108 config WQ_WATCHDOG
1109         bool "Detect Workqueue Stalls"
1110         depends on DEBUG_KERNEL
1111         help
1112           Say Y here to enable stall detection on workqueues.  If a
1113           worker pool doesn't make forward progress on a pending work
1114           item for over a given amount of time, 30s by default, a
1115           warning message is printed along with dump of workqueue
1116           state.  This can be configured through kernel parameter
1117           "workqueue.watchdog_thresh" and its sysfs counterpart.
1118
1119 config TEST_LOCKUP
1120         tristate "Test module to generate lockups"
1121         depends on m
1122         help
1123           This builds the "test_lockup" module that helps to make sure
1124           that watchdogs and lockup detectors are working properly.
1125
1126           Depending on module parameters it could emulate soft or hard
1127           lockup, "hung task", or locking arbitrary lock for a long time.
1128           Also it could generate series of lockups with cooling-down periods.
1129
1130           If unsure, say N.
1131
1132 endmenu # "Debug lockups and hangs"
1133
1134 menu "Scheduler Debugging"
1135
1136 config SCHED_DEBUG
1137         bool "Collect scheduler debugging info"
1138         depends on DEBUG_KERNEL && PROC_FS
1139         default y
1140         help
1141           If you say Y here, the /proc/sched_debug file will be provided
1142           that can help debug the scheduler. The runtime overhead of this
1143           option is minimal.
1144
1145 config SCHED_INFO
1146         bool
1147         default n
1148
1149 config SCHEDSTATS
1150         bool "Collect scheduler statistics"
1151         depends on DEBUG_KERNEL && PROC_FS
1152         select SCHED_INFO
1153         help
1154           If you say Y here, additional code will be inserted into the
1155           scheduler and related routines to collect statistics about
1156           scheduler behavior and provide them in /proc/schedstat.  These
1157           stats may be useful for both tuning and debugging the scheduler
1158           If you aren't debugging the scheduler or trying to tune a specific
1159           application, you can say N to avoid the very slight overhead
1160           this adds.
1161
1162 endmenu
1163
1164 config DEBUG_TIMEKEEPING
1165         bool "Enable extra timekeeping sanity checking"
1166         help
1167           This option will enable additional timekeeping sanity checks
1168           which may be helpful when diagnosing issues where timekeeping
1169           problems are suspected.
1170
1171           This may include checks in the timekeeping hotpaths, so this
1172           option may have a (very small) performance impact to some
1173           workloads.
1174
1175           If unsure, say N.
1176
1177 config DEBUG_PREEMPT
1178         bool "Debug preemptible kernel"
1179         depends on DEBUG_KERNEL && PREEMPTION && TRACE_IRQFLAGS_SUPPORT
1180         default y
1181         help
1182           If you say Y here then the kernel will use a debug variant of the
1183           commonly used smp_processor_id() function and will print warnings
1184           if kernel code uses it in a preemption-unsafe way. Also, the kernel
1185           will detect preemption count underflows.
1186
1187 menu "Lock Debugging (spinlocks, mutexes, etc...)"
1188
1189 config LOCK_DEBUGGING_SUPPORT
1190         bool
1191         depends on TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
1192         default y
1193
1194 config PROVE_LOCKING
1195         bool "Lock debugging: prove locking correctness"
1196         depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
1197         select LOCKDEP
1198         select DEBUG_SPINLOCK
1199         select DEBUG_MUTEXES
1200         select DEBUG_RT_MUTEXES if RT_MUTEXES
1201         select DEBUG_RWSEMS
1202         select DEBUG_WW_MUTEX_SLOWPATH
1203         select DEBUG_LOCK_ALLOC
1204         select PREEMPT_COUNT if !ARCH_NO_PREEMPT
1205         select TRACE_IRQFLAGS
1206         default n
1207         help
1208          This feature enables the kernel to prove that all locking
1209          that occurs in the kernel runtime is mathematically
1210          correct: that under no circumstance could an arbitrary (and
1211          not yet triggered) combination of observed locking
1212          sequences (on an arbitrary number of CPUs, running an
1213          arbitrary number of tasks and interrupt contexts) cause a
1214          deadlock.
1215
1216          In short, this feature enables the kernel to report locking
1217          related deadlocks before they actually occur.
1218
1219          The proof does not depend on how hard and complex a
1220          deadlock scenario would be to trigger: how many
1221          participant CPUs, tasks and irq-contexts would be needed
1222          for it to trigger. The proof also does not depend on
1223          timing: if a race and a resulting deadlock is possible
1224          theoretically (no matter how unlikely the race scenario
1225          is), it will be proven so and will immediately be
1226          reported by the kernel (once the event is observed that
1227          makes the deadlock theoretically possible).
1228
1229          If a deadlock is impossible (i.e. the locking rules, as
1230          observed by the kernel, are mathematically correct), the
1231          kernel reports nothing.
1232
1233          NOTE: this feature can also be enabled for rwlocks, mutexes
1234          and rwsems - in which case all dependencies between these
1235          different locking variants are observed and mapped too, and
1236          the proof of observed correctness is also maintained for an
1237          arbitrary combination of these separate locking variants.
1238
1239          For more details, see Documentation/locking/lockdep-design.rst.
1240
1241 config PROVE_RAW_LOCK_NESTING
1242         bool "Enable raw_spinlock - spinlock nesting checks"
1243         depends on PROVE_LOCKING
1244         default n
1245         help
1246          Enable the raw_spinlock vs. spinlock nesting checks which ensure
1247          that the lock nesting rules for PREEMPT_RT enabled kernels are
1248          not violated.
1249
1250          NOTE: There are known nesting problems. So if you enable this
1251          option expect lockdep splats until these problems have been fully
1252          addressed which is work in progress. This config switch allows to
1253          identify and analyze these problems. It will be removed and the
1254          check permanentely enabled once the main issues have been fixed.
1255
1256          If unsure, select N.
1257
1258 config LOCK_STAT
1259         bool "Lock usage statistics"
1260         depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
1261         select LOCKDEP
1262         select DEBUG_SPINLOCK
1263         select DEBUG_MUTEXES
1264         select DEBUG_RT_MUTEXES if RT_MUTEXES
1265         select DEBUG_LOCK_ALLOC
1266         default n
1267         help
1268          This feature enables tracking lock contention points
1269
1270          For more details, see Documentation/locking/lockstat.rst
1271
1272          This also enables lock events required by "perf lock",
1273          subcommand of perf.
1274          If you want to use "perf lock", you also need to turn on
1275          CONFIG_EVENT_TRACING.
1276
1277          CONFIG_LOCK_STAT defines "contended" and "acquired" lock events.
1278          (CONFIG_LOCKDEP defines "acquire" and "release" events.)
1279
1280 config DEBUG_RT_MUTEXES
1281         bool "RT Mutex debugging, deadlock detection"
1282         depends on DEBUG_KERNEL && RT_MUTEXES
1283         help
1284          This allows rt mutex semantics violations and rt mutex related
1285          deadlocks (lockups) to be detected and reported automatically.
1286
1287 config DEBUG_SPINLOCK
1288         bool "Spinlock and rw-lock debugging: basic checks"
1289         depends on DEBUG_KERNEL
1290         select UNINLINE_SPIN_UNLOCK
1291         help
1292           Say Y here and build SMP to catch missing spinlock initialization
1293           and certain other kinds of spinlock errors commonly made.  This is
1294           best used in conjunction with the NMI watchdog so that spinlock
1295           deadlocks are also debuggable.
1296
1297 config DEBUG_MUTEXES
1298         bool "Mutex debugging: basic checks"
1299         depends on DEBUG_KERNEL
1300         help
1301          This feature allows mutex semantics violations to be detected and
1302          reported.
1303
1304 config DEBUG_WW_MUTEX_SLOWPATH
1305         bool "Wait/wound mutex debugging: Slowpath testing"
1306         depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
1307         select DEBUG_LOCK_ALLOC
1308         select DEBUG_SPINLOCK
1309         select DEBUG_MUTEXES
1310         help
1311          This feature enables slowpath testing for w/w mutex users by
1312          injecting additional -EDEADLK wound/backoff cases. Together with
1313          the full mutex checks enabled with (CONFIG_PROVE_LOCKING) this
1314          will test all possible w/w mutex interface abuse with the
1315          exception of simply not acquiring all the required locks.
1316          Note that this feature can introduce significant overhead, so
1317          it really should not be enabled in a production or distro kernel,
1318          even a debug kernel.  If you are a driver writer, enable it.  If
1319          you are a distro, do not.
1320
1321 config DEBUG_RWSEMS
1322         bool "RW Semaphore debugging: basic checks"
1323         depends on DEBUG_KERNEL
1324         help
1325           This debugging feature allows mismatched rw semaphore locks
1326           and unlocks to be detected and reported.
1327
1328 config DEBUG_LOCK_ALLOC
1329         bool "Lock debugging: detect incorrect freeing of live locks"
1330         depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
1331         select DEBUG_SPINLOCK
1332         select DEBUG_MUTEXES
1333         select DEBUG_RT_MUTEXES if RT_MUTEXES
1334         select LOCKDEP
1335         help
1336          This feature will check whether any held lock (spinlock, rwlock,
1337          mutex or rwsem) is incorrectly freed by the kernel, via any of the
1338          memory-freeing routines (kfree(), kmem_cache_free(), free_pages(),
1339          vfree(), etc.), whether a live lock is incorrectly reinitialized via
1340          spin_lock_init()/mutex_init()/etc., or whether there is any lock
1341          held during task exit.
1342
1343 config LOCKDEP
1344         bool
1345         depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
1346         select STACKTRACE
1347         select FRAME_POINTER if !MIPS && !PPC && !ARM && !S390 && !MICROBLAZE && !ARC && !X86
1348         select KALLSYMS
1349         select KALLSYMS_ALL
1350
1351 config LOCKDEP_SMALL
1352         bool
1353
1354 config DEBUG_LOCKDEP
1355         bool "Lock dependency engine debugging"
1356         depends on DEBUG_KERNEL && LOCKDEP
1357         help
1358           If you say Y here, the lock dependency engine will do
1359           additional runtime checks to debug itself, at the price
1360           of more runtime overhead.
1361
1362 config DEBUG_ATOMIC_SLEEP
1363         bool "Sleep inside atomic section checking"
1364         select PREEMPT_COUNT
1365         depends on DEBUG_KERNEL
1366         depends on !ARCH_NO_PREEMPT
1367         help
1368           If you say Y here, various routines which may sleep will become very
1369           noisy if they are called inside atomic sections: when a spinlock is
1370           held, inside an rcu read side critical section, inside preempt disabled
1371           sections, inside an interrupt, etc...
1372
1373 config DEBUG_LOCKING_API_SELFTESTS
1374         bool "Locking API boot-time self-tests"
1375         depends on DEBUG_KERNEL
1376         help
1377           Say Y here if you want the kernel to run a short self-test during
1378           bootup. The self-test checks whether common types of locking bugs
1379           are detected by debugging mechanisms or not. (if you disable
1380           lock debugging then those bugs wont be detected of course.)
1381           The following locking APIs are covered: spinlocks, rwlocks,
1382           mutexes and rwsems.
1383
1384 config LOCK_TORTURE_TEST
1385         tristate "torture tests for locking"
1386         depends on DEBUG_KERNEL
1387         select TORTURE_TEST
1388         help
1389           This option provides a kernel module that runs torture tests
1390           on kernel locking primitives.  The kernel module may be built
1391           after the fact on the running kernel to be tested, if desired.
1392
1393           Say Y here if you want kernel locking-primitive torture tests
1394           to be built into the kernel.
1395           Say M if you want these torture tests to build as a module.
1396           Say N if you are unsure.
1397
1398 config WW_MUTEX_SELFTEST
1399         tristate "Wait/wound mutex selftests"
1400         help
1401           This option provides a kernel module that runs tests on the
1402           on the struct ww_mutex locking API.
1403
1404           It is recommended to enable DEBUG_WW_MUTEX_SLOWPATH in conjunction
1405           with this test harness.
1406
1407           Say M if you want these self tests to build as a module.
1408           Say N if you are unsure.
1409
1410 config SCF_TORTURE_TEST
1411         tristate "torture tests for smp_call_function*()"
1412         depends on DEBUG_KERNEL
1413         select TORTURE_TEST
1414         help
1415           This option provides a kernel module that runs torture tests
1416           on the smp_call_function() family of primitives.  The kernel
1417           module may be built after the fact on the running kernel to
1418           be tested, if desired.
1419
1420 config CSD_LOCK_WAIT_DEBUG
1421         bool "Debugging for csd_lock_wait(), called from smp_call_function*()"
1422         depends on DEBUG_KERNEL
1423         depends on 64BIT
1424         default n
1425         help
1426           This option enables debug prints when CPUs are slow to respond
1427           to the smp_call_function*() IPI wrappers.  These debug prints
1428           include the IPI handler function currently executing (if any)
1429           and relevant stack traces.
1430
1431 endmenu # lock debugging
1432
1433 config TRACE_IRQFLAGS
1434         depends on TRACE_IRQFLAGS_SUPPORT
1435         bool
1436         help
1437           Enables hooks to interrupt enabling and disabling for
1438           either tracing or lock debugging.
1439
1440 config TRACE_IRQFLAGS_NMI
1441         def_bool y
1442         depends on TRACE_IRQFLAGS
1443         depends on TRACE_IRQFLAGS_NMI_SUPPORT
1444
1445 config STACKTRACE
1446         bool "Stack backtrace support"
1447         depends on STACKTRACE_SUPPORT
1448         help
1449           This option causes the kernel to create a /proc/pid/stack for
1450           every process, showing its current stack trace.
1451           It is also used by various kernel debugging features that require
1452           stack trace generation.
1453
1454 config WARN_ALL_UNSEEDED_RANDOM
1455         bool "Warn for all uses of unseeded randomness"
1456         default n
1457         help
1458           Some parts of the kernel contain bugs relating to their use of
1459           cryptographically secure random numbers before it's actually possible
1460           to generate those numbers securely. This setting ensures that these
1461           flaws don't go unnoticed, by enabling a message, should this ever
1462           occur. This will allow people with obscure setups to know when things
1463           are going wrong, so that they might contact developers about fixing
1464           it.
1465
1466           Unfortunately, on some models of some architectures getting
1467           a fully seeded CRNG is extremely difficult, and so this can
1468           result in dmesg getting spammed for a surprisingly long
1469           time.  This is really bad from a security perspective, and
1470           so architecture maintainers really need to do what they can
1471           to get the CRNG seeded sooner after the system is booted.
1472           However, since users cannot do anything actionable to
1473           address this, by default the kernel will issue only a single
1474           warning for the first use of unseeded randomness.
1475
1476           Say Y here if you want to receive warnings for all uses of
1477           unseeded randomness.  This will be of use primarily for
1478           those developers interested in improving the security of
1479           Linux kernels running on their architecture (or
1480           subarchitecture).
1481
1482 config DEBUG_KOBJECT
1483         bool "kobject debugging"
1484         depends on DEBUG_KERNEL
1485         help
1486           If you say Y here, some extra kobject debugging messages will be sent
1487           to the syslog.
1488
1489 config DEBUG_KOBJECT_RELEASE
1490         bool "kobject release debugging"
1491         depends on DEBUG_OBJECTS_TIMERS
1492         help
1493           kobjects are reference counted objects.  This means that their
1494           last reference count put is not predictable, and the kobject can
1495           live on past the point at which a driver decides to drop it's
1496           initial reference to the kobject gained on allocation.  An
1497           example of this would be a struct device which has just been
1498           unregistered.
1499
1500           However, some buggy drivers assume that after such an operation,
1501           the memory backing the kobject can be immediately freed.  This
1502           goes completely against the principles of a refcounted object.
1503
1504           If you say Y here, the kernel will delay the release of kobjects
1505           on the last reference count to improve the visibility of this
1506           kind of kobject release bug.
1507
1508 config HAVE_DEBUG_BUGVERBOSE
1509         bool
1510
1511 menu "Debug kernel data structures"
1512
1513 config DEBUG_LIST
1514         bool "Debug linked list manipulation"
1515         depends on DEBUG_KERNEL || BUG_ON_DATA_CORRUPTION
1516         help
1517           Enable this to turn on extended checks in the linked-list
1518           walking routines.
1519
1520           If unsure, say N.
1521
1522 config DEBUG_PLIST
1523         bool "Debug priority linked list manipulation"
1524         depends on DEBUG_KERNEL
1525         help
1526           Enable this to turn on extended checks in the priority-ordered
1527           linked-list (plist) walking routines.  This checks the entire
1528           list multiple times during each manipulation.
1529
1530           If unsure, say N.
1531
1532 config DEBUG_SG
1533         bool "Debug SG table operations"
1534         depends on DEBUG_KERNEL
1535         help
1536           Enable this to turn on checks on scatter-gather tables. This can
1537           help find problems with drivers that do not properly initialize
1538           their sg tables.
1539
1540           If unsure, say N.
1541
1542 config DEBUG_NOTIFIERS
1543         bool "Debug notifier call chains"
1544         depends on DEBUG_KERNEL
1545         help
1546           Enable this to turn on sanity checking for notifier call chains.
1547           This is most useful for kernel developers to make sure that
1548           modules properly unregister themselves from notifier chains.
1549           This is a relatively cheap check but if you care about maximum
1550           performance, say N.
1551
1552 config BUG_ON_DATA_CORRUPTION
1553         bool "Trigger a BUG when data corruption is detected"
1554         select DEBUG_LIST
1555         help
1556           Select this option if the kernel should BUG when it encounters
1557           data corruption in kernel memory structures when they get checked
1558           for validity.
1559
1560           If unsure, say N.
1561
1562 endmenu
1563
1564 config DEBUG_CREDENTIALS
1565         bool "Debug credential management"
1566         depends on DEBUG_KERNEL
1567         help
1568           Enable this to turn on some debug checking for credential
1569           management.  The additional code keeps track of the number of
1570           pointers from task_structs to any given cred struct, and checks to
1571           see that this number never exceeds the usage count of the cred
1572           struct.
1573
1574           Furthermore, if SELinux is enabled, this also checks that the
1575           security pointer in the cred struct is never seen to be invalid.
1576
1577           If unsure, say N.
1578
1579 source "kernel/rcu/Kconfig.debug"
1580
1581 config DEBUG_WQ_FORCE_RR_CPU
1582         bool "Force round-robin CPU selection for unbound work items"
1583         depends on DEBUG_KERNEL
1584         default n
1585         help
1586           Workqueue used to implicitly guarantee that work items queued
1587           without explicit CPU specified are put on the local CPU.  This
1588           guarantee is no longer true and while local CPU is still
1589           preferred work items may be put on foreign CPUs.  Kernel
1590           parameter "workqueue.debug_force_rr_cpu" is added to force
1591           round-robin CPU selection to flush out usages which depend on the
1592           now broken guarantee.  This config option enables the debug
1593           feature by default.  When enabled, memory and cache locality will
1594           be impacted.
1595
1596 config DEBUG_BLOCK_EXT_DEVT
1597         bool "Force extended block device numbers and spread them"
1598         depends on DEBUG_KERNEL
1599         depends on BLOCK
1600         default n
1601         help
1602           BIG FAT WARNING: ENABLING THIS OPTION MIGHT BREAK BOOTING ON
1603           SOME DISTRIBUTIONS.  DO NOT ENABLE THIS UNLESS YOU KNOW WHAT
1604           YOU ARE DOING.  Distros, please enable this and fix whatever
1605           is broken.
1606
1607           Conventionally, block device numbers are allocated from
1608           predetermined contiguous area.  However, extended block area
1609           may introduce non-contiguous block device numbers.  This
1610           option forces most block device numbers to be allocated from
1611           the extended space and spreads them to discover kernel or
1612           userland code paths which assume predetermined contiguous
1613           device number allocation.
1614
1615           Note that turning on this debug option shuffles all the
1616           device numbers for all IDE and SCSI devices including libata
1617           ones, so root partition specified using device number
1618           directly (via rdev or root=MAJ:MIN) won't work anymore.
1619           Textual device names (root=/dev/sdXn) will continue to work.
1620
1621           Say N if you are unsure.
1622
1623 config CPU_HOTPLUG_STATE_CONTROL
1624         bool "Enable CPU hotplug state control"
1625         depends on DEBUG_KERNEL
1626         depends on HOTPLUG_CPU
1627         default n
1628         help
1629           Allows to write steps between "offline" and "online" to the CPUs
1630           sysfs target file so states can be stepped granular. This is a debug
1631           option for now as the hotplug machinery cannot be stopped and
1632           restarted at arbitrary points yet.
1633
1634           Say N if your are unsure.
1635
1636 config LATENCYTOP
1637         bool "Latency measuring infrastructure"
1638         depends on DEBUG_KERNEL
1639         depends on STACKTRACE_SUPPORT
1640         depends on PROC_FS
1641         select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM && !ARC && !X86
1642         select KALLSYMS
1643         select KALLSYMS_ALL
1644         select STACKTRACE
1645         select SCHEDSTATS
1646         select SCHED_DEBUG
1647         help
1648           Enable this option if you want to use the LatencyTOP tool
1649           to find out which userspace is blocking on what kernel operations.
1650
1651 source "kernel/trace/Kconfig"
1652
1653 config PROVIDE_OHCI1394_DMA_INIT
1654         bool "Remote debugging over FireWire early on boot"
1655         depends on PCI && X86
1656         help
1657           If you want to debug problems which hang or crash the kernel early
1658           on boot and the crashing machine has a FireWire port, you can use
1659           this feature to remotely access the memory of the crashed machine
1660           over FireWire. This employs remote DMA as part of the OHCI1394
1661           specification which is now the standard for FireWire controllers.
1662
1663           With remote DMA, you can monitor the printk buffer remotely using
1664           firescope and access all memory below 4GB using fireproxy from gdb.
1665           Even controlling a kernel debugger is possible using remote DMA.
1666
1667           Usage:
1668
1669           If ohci1394_dma=early is used as boot parameter, it will initialize
1670           all OHCI1394 controllers which are found in the PCI config space.
1671
1672           As all changes to the FireWire bus such as enabling and disabling
1673           devices cause a bus reset and thereby disable remote DMA for all
1674           devices, be sure to have the cable plugged and FireWire enabled on
1675           the debugging host before booting the debug target for debugging.
1676
1677           This code (~1k) is freed after boot. By then, the firewire stack
1678           in charge of the OHCI-1394 controllers should be used instead.
1679
1680           See Documentation/core-api/debugging-via-ohci1394.rst for more information.
1681
1682 source "samples/Kconfig"
1683
1684 config ARCH_HAS_DEVMEM_IS_ALLOWED
1685         bool
1686
1687 config STRICT_DEVMEM
1688         bool "Filter access to /dev/mem"
1689         depends on MMU && DEVMEM
1690         depends on ARCH_HAS_DEVMEM_IS_ALLOWED || GENERIC_LIB_DEVMEM_IS_ALLOWED
1691         default y if PPC || X86 || ARM64
1692         help
1693           If this option is disabled, you allow userspace (root) access to all
1694           of memory, including kernel and userspace memory. Accidental
1695           access to this is obviously disastrous, but specific access can
1696           be used by people debugging the kernel. Note that with PAT support
1697           enabled, even in this case there are restrictions on /dev/mem
1698           use due to the cache aliasing requirements.
1699
1700           If this option is switched on, and IO_STRICT_DEVMEM=n, the /dev/mem
1701           file only allows userspace access to PCI space and the BIOS code and
1702           data regions.  This is sufficient for dosemu and X and all common
1703           users of /dev/mem.
1704
1705           If in doubt, say Y.
1706
1707 config IO_STRICT_DEVMEM
1708         bool "Filter I/O access to /dev/mem"
1709         depends on STRICT_DEVMEM
1710         help
1711           If this option is disabled, you allow userspace (root) access to all
1712           io-memory regardless of whether a driver is actively using that
1713           range.  Accidental access to this is obviously disastrous, but
1714           specific access can be used by people debugging kernel drivers.
1715
1716           If this option is switched on, the /dev/mem file only allows
1717           userspace access to *idle* io-memory ranges (see /proc/iomem) This
1718           may break traditional users of /dev/mem (dosemu, legacy X, etc...)
1719           if the driver using a given range cannot be disabled.
1720
1721           If in doubt, say Y.
1722
1723 menu "$(SRCARCH) Debugging"
1724
1725 source "arch/$(SRCARCH)/Kconfig.debug"
1726
1727 endmenu
1728
1729 menu "Kernel Testing and Coverage"
1730
1731 source "lib/kunit/Kconfig"
1732
1733 config NOTIFIER_ERROR_INJECTION
1734         tristate "Notifier error injection"
1735         depends on DEBUG_KERNEL
1736         select DEBUG_FS
1737         help
1738           This option provides the ability to inject artificial errors to
1739           specified notifier chain callbacks. It is useful to test the error
1740           handling of notifier call chain failures.
1741
1742           Say N if unsure.
1743
1744 config PM_NOTIFIER_ERROR_INJECT
1745         tristate "PM notifier error injection module"
1746         depends on PM && NOTIFIER_ERROR_INJECTION
1747         default m if PM_DEBUG
1748         help
1749           This option provides the ability to inject artificial errors to
1750           PM notifier chain callbacks.  It is controlled through debugfs
1751           interface /sys/kernel/debug/notifier-error-inject/pm
1752
1753           If the notifier call chain should be failed with some events
1754           notified, write the error code to "actions/<notifier event>/error".
1755
1756           Example: Inject PM suspend error (-12 = -ENOMEM)
1757
1758           # cd /sys/kernel/debug/notifier-error-inject/pm/
1759           # echo -12 > actions/PM_SUSPEND_PREPARE/error
1760           # echo mem > /sys/power/state
1761           bash: echo: write error: Cannot allocate memory
1762
1763           To compile this code as a module, choose M here: the module will
1764           be called pm-notifier-error-inject.
1765
1766           If unsure, say N.
1767
1768 config OF_RECONFIG_NOTIFIER_ERROR_INJECT
1769         tristate "OF reconfig notifier error injection module"
1770         depends on OF_DYNAMIC && NOTIFIER_ERROR_INJECTION
1771         help
1772           This option provides the ability to inject artificial errors to
1773           OF reconfig notifier chain callbacks.  It is controlled
1774           through debugfs interface under
1775           /sys/kernel/debug/notifier-error-inject/OF-reconfig/
1776
1777           If the notifier call chain should be failed with some events
1778           notified, write the error code to "actions/<notifier event>/error".
1779
1780           To compile this code as a module, choose M here: the module will
1781           be called of-reconfig-notifier-error-inject.
1782
1783           If unsure, say N.
1784
1785 config NETDEV_NOTIFIER_ERROR_INJECT
1786         tristate "Netdev notifier error injection module"
1787         depends on NET && NOTIFIER_ERROR_INJECTION
1788         help
1789           This option provides the ability to inject artificial errors to
1790           netdevice notifier chain callbacks.  It is controlled through debugfs
1791           interface /sys/kernel/debug/notifier-error-inject/netdev
1792
1793           If the notifier call chain should be failed with some events
1794           notified, write the error code to "actions/<notifier event>/error".
1795
1796           Example: Inject netdevice mtu change error (-22 = -EINVAL)
1797
1798           # cd /sys/kernel/debug/notifier-error-inject/netdev
1799           # echo -22 > actions/NETDEV_CHANGEMTU/error
1800           # ip link set eth0 mtu 1024
1801           RTNETLINK answers: Invalid argument
1802
1803           To compile this code as a module, choose M here: the module will
1804           be called netdev-notifier-error-inject.
1805
1806           If unsure, say N.
1807
1808 config FUNCTION_ERROR_INJECTION
1809         def_bool y
1810         depends on HAVE_FUNCTION_ERROR_INJECTION && KPROBES
1811
1812 config FAULT_INJECTION
1813         bool "Fault-injection framework"
1814         depends on DEBUG_KERNEL
1815         help
1816           Provide fault-injection framework.
1817           For more details, see Documentation/fault-injection/.
1818
1819 config FAILSLAB
1820         bool "Fault-injection capability for kmalloc"
1821         depends on FAULT_INJECTION
1822         depends on SLAB || SLUB
1823         help
1824           Provide fault-injection capability for kmalloc.
1825
1826 config FAIL_PAGE_ALLOC
1827         bool "Fault-injection capability for alloc_pages()"
1828         depends on FAULT_INJECTION
1829         help
1830           Provide fault-injection capability for alloc_pages().
1831
1832 config FAULT_INJECTION_USERCOPY
1833         bool "Fault injection capability for usercopy functions"
1834         depends on FAULT_INJECTION
1835         help
1836           Provides fault-injection capability to inject failures
1837           in usercopy functions (copy_from_user(), get_user(), ...).
1838
1839 config FAIL_MAKE_REQUEST
1840         bool "Fault-injection capability for disk IO"
1841         depends on FAULT_INJECTION && BLOCK
1842         help
1843           Provide fault-injection capability for disk IO.
1844
1845 config FAIL_IO_TIMEOUT
1846         bool "Fault-injection capability for faking disk interrupts"
1847         depends on FAULT_INJECTION && BLOCK
1848         help
1849           Provide fault-injection capability on end IO handling. This
1850           will make the block layer "forget" an interrupt as configured,
1851           thus exercising the error handling.
1852
1853           Only works with drivers that use the generic timeout handling,
1854           for others it wont do anything.
1855
1856 config FAIL_FUTEX
1857         bool "Fault-injection capability for futexes"
1858         select DEBUG_FS
1859         depends on FAULT_INJECTION && FUTEX
1860         help
1861           Provide fault-injection capability for futexes.
1862
1863 config FAULT_INJECTION_DEBUG_FS
1864         bool "Debugfs entries for fault-injection capabilities"
1865         depends on FAULT_INJECTION && SYSFS && DEBUG_FS
1866         help
1867           Enable configuration of fault-injection capabilities via debugfs.
1868
1869 config FAIL_FUNCTION
1870         bool "Fault-injection capability for functions"
1871         depends on FAULT_INJECTION_DEBUG_FS && FUNCTION_ERROR_INJECTION
1872         help
1873           Provide function-based fault-injection capability.
1874           This will allow you to override a specific function with a return
1875           with given return value. As a result, function caller will see
1876           an error value and have to handle it. This is useful to test the
1877           error handling in various subsystems.
1878
1879 config FAIL_MMC_REQUEST
1880         bool "Fault-injection capability for MMC IO"
1881         depends on FAULT_INJECTION_DEBUG_FS && MMC
1882         help
1883           Provide fault-injection capability for MMC IO.
1884           This will make the mmc core return data errors. This is
1885           useful to test the error handling in the mmc block device
1886           and to test how the mmc host driver handles retries from
1887           the block device.
1888
1889 config FAULT_INJECTION_STACKTRACE_FILTER
1890         bool "stacktrace filter for fault-injection capabilities"
1891         depends on FAULT_INJECTION_DEBUG_FS && STACKTRACE_SUPPORT
1892         depends on !X86_64
1893         select STACKTRACE
1894         select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM && !ARC && !X86
1895         help
1896           Provide stacktrace filter for fault-injection capabilities
1897
1898 config ARCH_HAS_KCOV
1899         bool
1900         help
1901           An architecture should select this when it can successfully
1902           build and run with CONFIG_KCOV. This typically requires
1903           disabling instrumentation for some early boot code.
1904
1905 config CC_HAS_SANCOV_TRACE_PC
1906         def_bool $(cc-option,-fsanitize-coverage=trace-pc)
1907
1908
1909 config KCOV
1910         bool "Code coverage for fuzzing"
1911         depends on ARCH_HAS_KCOV
1912         depends on CC_HAS_SANCOV_TRACE_PC || GCC_PLUGINS
1913         select DEBUG_FS
1914         select GCC_PLUGIN_SANCOV if !CC_HAS_SANCOV_TRACE_PC
1915         help
1916           KCOV exposes kernel code coverage information in a form suitable
1917           for coverage-guided fuzzing (randomized testing).
1918
1919           If RANDOMIZE_BASE is enabled, PC values will not be stable across
1920           different machines and across reboots. If you need stable PC values,
1921           disable RANDOMIZE_BASE.
1922
1923           For more details, see Documentation/dev-tools/kcov.rst.
1924
1925 config KCOV_ENABLE_COMPARISONS
1926         bool "Enable comparison operands collection by KCOV"
1927         depends on KCOV
1928         depends on $(cc-option,-fsanitize-coverage=trace-cmp)
1929         help
1930           KCOV also exposes operands of every comparison in the instrumented
1931           code along with operand sizes and PCs of the comparison instructions.
1932           These operands can be used by fuzzing engines to improve the quality
1933           of fuzzing coverage.
1934
1935 config KCOV_INSTRUMENT_ALL
1936         bool "Instrument all code by default"
1937         depends on KCOV
1938         default y
1939         help
1940           If you are doing generic system call fuzzing (like e.g. syzkaller),
1941           then you will want to instrument the whole kernel and you should
1942           say y here. If you are doing more targeted fuzzing (like e.g.
1943           filesystem fuzzing with AFL) then you will want to enable coverage
1944           for more specific subsets of files, and should say n here.
1945
1946 config KCOV_IRQ_AREA_SIZE
1947         hex "Size of interrupt coverage collection area in words"
1948         depends on KCOV
1949         default 0x40000
1950         help
1951           KCOV uses preallocated per-cpu areas to collect coverage from
1952           soft interrupts. This specifies the size of those areas in the
1953           number of unsigned long words.
1954
1955 menuconfig RUNTIME_TESTING_MENU
1956         bool "Runtime Testing"
1957         def_bool y
1958
1959 if RUNTIME_TESTING_MENU
1960
1961 config LKDTM
1962         tristate "Linux Kernel Dump Test Tool Module"
1963         depends on DEBUG_FS
1964         help
1965         This module enables testing of the different dumping mechanisms by
1966         inducing system failures at predefined crash points.
1967         If you don't need it: say N
1968         Choose M here to compile this code as a module. The module will be
1969         called lkdtm.
1970
1971         Documentation on how to use the module can be found in
1972         Documentation/fault-injection/provoke-crashes.rst
1973
1974 config TEST_LIST_SORT
1975         tristate "Linked list sorting test"
1976         depends on DEBUG_KERNEL || m
1977         help
1978           Enable this to turn on 'list_sort()' function test. This test is
1979           executed only once during system boot (so affects only boot time),
1980           or at module load time.
1981
1982           If unsure, say N.
1983
1984 config TEST_MIN_HEAP
1985         tristate "Min heap test"
1986         depends on DEBUG_KERNEL || m
1987         help
1988           Enable this to turn on min heap function tests. This test is
1989           executed only once during system boot (so affects only boot time),
1990           or at module load time.
1991
1992           If unsure, say N.
1993
1994 config TEST_SORT
1995         tristate "Array-based sort test"
1996         depends on DEBUG_KERNEL || m
1997         help
1998           This option enables the self-test function of 'sort()' at boot,
1999           or at module load time.
2000
2001           If unsure, say N.
2002
2003 config KPROBES_SANITY_TEST
2004         bool "Kprobes sanity tests"
2005         depends on DEBUG_KERNEL
2006         depends on KPROBES
2007         help
2008           This option provides for testing basic kprobes functionality on
2009           boot. Samples of kprobe and kretprobe are inserted and
2010           verified for functionality.
2011
2012           Say N if you are unsure.
2013
2014 config BACKTRACE_SELF_TEST
2015         tristate "Self test for the backtrace code"
2016         depends on DEBUG_KERNEL
2017         help
2018           This option provides a kernel module that can be used to test
2019           the kernel stack backtrace code. This option is not useful
2020           for distributions or general kernels, but only for kernel
2021           developers working on architecture code.
2022
2023           Note that if you want to also test saved backtraces, you will
2024           have to enable STACKTRACE as well.
2025
2026           Say N if you are unsure.
2027
2028 config RBTREE_TEST
2029         tristate "Red-Black tree test"
2030         depends on DEBUG_KERNEL
2031         help
2032           A benchmark measuring the performance of the rbtree library.
2033           Also includes rbtree invariant checks.
2034
2035 config REED_SOLOMON_TEST
2036         tristate "Reed-Solomon library test"
2037         depends on DEBUG_KERNEL || m
2038         select REED_SOLOMON
2039         select REED_SOLOMON_ENC16
2040         select REED_SOLOMON_DEC16
2041         help
2042           This option enables the self-test function of rslib at boot,
2043           or at module load time.
2044
2045           If unsure, say N.
2046
2047 config INTERVAL_TREE_TEST
2048         tristate "Interval tree test"
2049         depends on DEBUG_KERNEL
2050         select INTERVAL_TREE
2051         help
2052           A benchmark measuring the performance of the interval tree library
2053
2054 config PERCPU_TEST
2055         tristate "Per cpu operations test"
2056         depends on m && DEBUG_KERNEL
2057         help
2058           Enable this option to build test module which validates per-cpu
2059           operations.
2060
2061           If unsure, say N.
2062
2063 config ATOMIC64_SELFTEST
2064         tristate "Perform an atomic64_t self-test"
2065         help
2066           Enable this option to test the atomic64_t functions at boot or
2067           at module load time.
2068
2069           If unsure, say N.
2070
2071 config ASYNC_RAID6_TEST
2072         tristate "Self test for hardware accelerated raid6 recovery"
2073         depends on ASYNC_RAID6_RECOV
2074         select ASYNC_MEMCPY
2075         help
2076           This is a one-shot self test that permutes through the
2077           recovery of all the possible two disk failure scenarios for a
2078           N-disk array.  Recovery is performed with the asynchronous
2079           raid6 recovery routines, and will optionally use an offload
2080           engine if one is available.
2081
2082           If unsure, say N.
2083
2084 config TEST_HEXDUMP
2085         tristate "Test functions located in the hexdump module at runtime"
2086
2087 config TEST_STRING_HELPERS
2088         tristate "Test functions located in the string_helpers module at runtime"
2089
2090 config TEST_STRSCPY
2091         tristate "Test strscpy*() family of functions at runtime"
2092
2093 config TEST_KSTRTOX
2094         tristate "Test kstrto*() family of functions at runtime"
2095
2096 config TEST_PRINTF
2097         tristate "Test printf() family of functions at runtime"
2098
2099 config TEST_BITMAP
2100         tristate "Test bitmap_*() family of functions at runtime"
2101         help
2102           Enable this option to test the bitmap functions at boot.
2103
2104           If unsure, say N.
2105
2106 config TEST_UUID
2107         tristate "Test functions located in the uuid module at runtime"
2108
2109 config TEST_XARRAY
2110         tristate "Test the XArray code at runtime"
2111
2112 config TEST_OVERFLOW
2113         tristate "Test check_*_overflow() functions at runtime"
2114
2115 config TEST_RHASHTABLE
2116         tristate "Perform selftest on resizable hash table"
2117         help
2118           Enable this option to test the rhashtable functions at boot.
2119
2120           If unsure, say N.
2121
2122 config TEST_HASH
2123         tristate "Perform selftest on hash functions"
2124         help
2125           Enable this option to test the kernel's integer (<linux/hash.h>),
2126           string (<linux/stringhash.h>), and siphash (<linux/siphash.h>)
2127           hash functions on boot (or module load).
2128
2129           This is intended to help people writing architecture-specific
2130           optimized versions.  If unsure, say N.
2131
2132 config TEST_IDA
2133         tristate "Perform selftest on IDA functions"
2134
2135 config TEST_PARMAN
2136         tristate "Perform selftest on priority array manager"
2137         depends on PARMAN
2138         help
2139           Enable this option to test priority array manager on boot
2140           (or module load).
2141
2142           If unsure, say N.
2143
2144 config TEST_IRQ_TIMINGS
2145         bool "IRQ timings selftest"
2146         depends on IRQ_TIMINGS
2147         help
2148           Enable this option to test the irq timings code on boot.
2149
2150           If unsure, say N.
2151
2152 config TEST_LKM
2153         tristate "Test module loading with 'hello world' module"
2154         depends on m
2155         help
2156           This builds the "test_module" module that emits "Hello, world"
2157           on printk when loaded. It is designed to be used for basic
2158           evaluation of the module loading subsystem (for example when
2159           validating module verification). It lacks any extra dependencies,
2160           and will not normally be loaded by the system unless explicitly
2161           requested by name.
2162
2163           If unsure, say N.
2164
2165 config TEST_BITOPS
2166         tristate "Test module for compilation of bitops operations"
2167         depends on m
2168         help
2169           This builds the "test_bitops" module that is much like the
2170           TEST_LKM module except that it does a basic exercise of the
2171           set/clear_bit macros and get_count_order/long to make sure there are
2172           no compiler warnings from C=1 sparse checker or -Wextra
2173           compilations. It has no dependencies and doesn't run or load unless
2174           explicitly requested by name.  for example: modprobe test_bitops.
2175
2176           If unsure, say N.
2177
2178 config TEST_VMALLOC
2179         tristate "Test module for stress/performance analysis of vmalloc allocator"
2180         default n
2181        depends on MMU
2182         depends on m
2183         help
2184           This builds the "test_vmalloc" module that should be used for
2185           stress and performance analysis. So, any new change for vmalloc
2186           subsystem can be evaluated from performance and stability point
2187           of view.
2188
2189           If unsure, say N.
2190
2191 config TEST_USER_COPY
2192         tristate "Test user/kernel boundary protections"
2193         depends on m
2194         help
2195           This builds the "test_user_copy" module that runs sanity checks
2196           on the copy_to/from_user infrastructure, making sure basic
2197           user/kernel boundary testing is working. If it fails to load,
2198           a regression has been detected in the user/kernel memory boundary
2199           protections.
2200
2201           If unsure, say N.
2202
2203 config TEST_BPF
2204         tristate "Test BPF filter functionality"
2205         depends on m && NET
2206         help
2207           This builds the "test_bpf" module that runs various test vectors
2208           against the BPF interpreter or BPF JIT compiler depending on the
2209           current setting. This is in particular useful for BPF JIT compiler
2210           development, but also to run regression tests against changes in
2211           the interpreter code. It also enables test stubs for eBPF maps and
2212           verifier used by user space verifier testsuite.
2213
2214           If unsure, say N.
2215
2216 config TEST_BLACKHOLE_DEV
2217         tristate "Test blackhole netdev functionality"
2218         depends on m && NET
2219         help
2220           This builds the "test_blackhole_dev" module that validates the
2221           data path through this blackhole netdev.
2222
2223           If unsure, say N.
2224
2225 config FIND_BIT_BENCHMARK
2226         tristate "Test find_bit functions"
2227         help
2228           This builds the "test_find_bit" module that measure find_*_bit()
2229           functions performance.
2230
2231           If unsure, say N.
2232
2233 config TEST_FIRMWARE
2234         tristate "Test firmware loading via userspace interface"
2235         depends on FW_LOADER
2236         help
2237           This builds the "test_firmware" module that creates a userspace
2238           interface for testing firmware loading. This can be used to
2239           control the triggering of firmware loading without needing an
2240           actual firmware-using device. The contents can be rechecked by
2241           userspace.
2242
2243           If unsure, say N.
2244
2245 config TEST_SYSCTL
2246         tristate "sysctl test driver"
2247         depends on PROC_SYSCTL
2248         help
2249           This builds the "test_sysctl" module. This driver enables to test the
2250           proc sysctl interfaces available to drivers safely without affecting
2251           production knobs which might alter system functionality.
2252
2253           If unsure, say N.
2254
2255 config BITFIELD_KUNIT
2256         tristate "KUnit test bitfield functions at runtime"
2257         depends on KUNIT
2258         help
2259           Enable this option to test the bitfield functions at boot.
2260
2261           KUnit tests run during boot and output the results to the debug log
2262           in TAP format (http://testanything.org/). Only useful for kernel devs
2263           running the KUnit test harness, and not intended for inclusion into a
2264           production build.
2265
2266           For more information on KUnit and unit tests in general please refer
2267           to the KUnit documentation in Documentation/dev-tools/kunit/.
2268
2269           If unsure, say N.
2270
2271 config RESOURCE_KUNIT_TEST
2272         tristate "KUnit test for resource API"
2273         depends on KUNIT
2274         help
2275           This builds the resource API unit test.
2276           Tests the logic of API provided by resource.c and ioport.h.
2277           For more information on KUnit and unit tests in general please refer
2278           to the KUnit documentation in Documentation/dev-tools/kunit/.
2279
2280           If unsure, say N.
2281
2282 config SYSCTL_KUNIT_TEST
2283         tristate "KUnit test for sysctl" if !KUNIT_ALL_TESTS
2284         depends on KUNIT
2285         default KUNIT_ALL_TESTS
2286         help
2287           This builds the proc sysctl unit test, which runs on boot.
2288           Tests the API contract and implementation correctness of sysctl.
2289           For more information on KUnit and unit tests in general please refer
2290           to the KUnit documentation in Documentation/dev-tools/kunit/.
2291
2292           If unsure, say N.
2293
2294 config LIST_KUNIT_TEST
2295         tristate "KUnit Test for Kernel Linked-list structures" if !KUNIT_ALL_TESTS
2296         depends on KUNIT
2297         default KUNIT_ALL_TESTS
2298         help
2299           This builds the linked list KUnit test suite.
2300           It tests that the API and basic functionality of the list_head type
2301           and associated macros.
2302
2303           KUnit tests run during boot and output the results to the debug log
2304           in TAP format (https://testanything.org/). Only useful for kernel devs
2305           running the KUnit test harness, and not intended for inclusion into a
2306           production build.
2307
2308           For more information on KUnit and unit tests in general please refer
2309           to the KUnit documentation in Documentation/dev-tools/kunit/.
2310
2311           If unsure, say N.
2312
2313 config LINEAR_RANGES_TEST
2314         tristate "KUnit test for linear_ranges"
2315         depends on KUNIT
2316         select LINEAR_RANGES
2317         help
2318           This builds the linear_ranges unit test, which runs on boot.
2319           Tests the linear_ranges logic correctness.
2320           For more information on KUnit and unit tests in general please refer
2321           to the KUnit documentation in Documentation/dev-tools/kunit/.
2322
2323           If unsure, say N.
2324
2325 config CMDLINE_KUNIT_TEST
2326         tristate "KUnit test for cmdline API"
2327         depends on KUNIT
2328         help
2329           This builds the cmdline API unit test.
2330           Tests the logic of API provided by cmdline.c.
2331           For more information on KUnit and unit tests in general please refer
2332           to the KUnit documentation in Documentation/dev-tools/kunit/.
2333
2334           If unsure, say N.
2335
2336 config BITS_TEST
2337         tristate "KUnit test for bits.h"
2338         depends on KUNIT
2339         help
2340           This builds the bits unit test.
2341           Tests the logic of macros defined in bits.h.
2342           For more information on KUnit and unit tests in general please refer
2343           to the KUnit documentation in Documentation/dev-tools/kunit/.
2344
2345           If unsure, say N.
2346
2347 config TEST_UDELAY
2348         tristate "udelay test driver"
2349         help
2350           This builds the "udelay_test" module that helps to make sure
2351           that udelay() is working properly.
2352
2353           If unsure, say N.
2354
2355 config TEST_STATIC_KEYS
2356         tristate "Test static keys"
2357         depends on m
2358         help
2359           Test the static key interfaces.
2360
2361           If unsure, say N.
2362
2363 config TEST_KMOD
2364         tristate "kmod stress tester"
2365         depends on m
2366         depends on NETDEVICES && NET_CORE && INET # for TUN
2367         depends on BLOCK
2368         select TEST_LKM
2369         select XFS_FS
2370         select TUN
2371         select BTRFS_FS
2372         help
2373           Test the kernel's module loading mechanism: kmod. kmod implements
2374           support to load modules using the Linux kernel's usermode helper.
2375           This test provides a series of tests against kmod.
2376
2377           Although technically you can either build test_kmod as a module or
2378           into the kernel we disallow building it into the kernel since
2379           it stress tests request_module() and this will very likely cause
2380           some issues by taking over precious threads available from other
2381           module load requests, ultimately this could be fatal.
2382
2383           To run tests run:
2384
2385           tools/testing/selftests/kmod/kmod.sh --help
2386
2387           If unsure, say N.
2388
2389 config TEST_DEBUG_VIRTUAL
2390         tristate "Test CONFIG_DEBUG_VIRTUAL feature"
2391         depends on DEBUG_VIRTUAL
2392         help
2393           Test the kernel's ability to detect incorrect calls to
2394           virt_to_phys() done against the non-linear part of the
2395           kernel's virtual address map.
2396
2397           If unsure, say N.
2398
2399 config TEST_MEMCAT_P
2400         tristate "Test memcat_p() helper function"
2401         help
2402           Test the memcat_p() helper for correctly merging two
2403           pointer arrays together.
2404
2405           If unsure, say N.
2406
2407 config TEST_LIVEPATCH
2408         tristate "Test livepatching"
2409         default n
2410         depends on DYNAMIC_DEBUG
2411         depends on LIVEPATCH
2412         depends on m
2413         help
2414           Test kernel livepatching features for correctness.  The tests will
2415           load test modules that will be livepatched in various scenarios.
2416
2417           To run all the livepatching tests:
2418
2419           make -C tools/testing/selftests TARGETS=livepatch run_tests
2420
2421           Alternatively, individual tests may be invoked:
2422
2423           tools/testing/selftests/livepatch/test-callbacks.sh
2424           tools/testing/selftests/livepatch/test-livepatch.sh
2425           tools/testing/selftests/livepatch/test-shadow-vars.sh
2426
2427           If unsure, say N.
2428
2429 config TEST_OBJAGG
2430         tristate "Perform selftest on object aggreration manager"
2431         default n
2432         depends on OBJAGG
2433         help
2434           Enable this option to test object aggregation manager on boot
2435           (or module load).
2436
2437
2438 config TEST_STACKINIT
2439         tristate "Test level of stack variable initialization"
2440         help
2441           Test if the kernel is zero-initializing stack variables and
2442           padding. Coverage is controlled by compiler flags,
2443           CONFIG_GCC_PLUGIN_STRUCTLEAK, CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF,
2444           or CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL.
2445
2446           If unsure, say N.
2447
2448 config TEST_MEMINIT
2449         tristate "Test heap/page initialization"
2450         help
2451           Test if the kernel is zero-initializing heap and page allocations.
2452           This can be useful to test init_on_alloc and init_on_free features.
2453
2454           If unsure, say N.
2455
2456 config TEST_HMM
2457         tristate "Test HMM (Heterogeneous Memory Management)"
2458         depends on TRANSPARENT_HUGEPAGE
2459         depends on DEVICE_PRIVATE
2460         select HMM_MIRROR
2461         select MMU_NOTIFIER
2462         help
2463           This is a pseudo device driver solely for testing HMM.
2464           Say M here if you want to build the HMM test module.
2465           Doing so will allow you to run tools/testing/selftest/vm/hmm-tests.
2466
2467           If unsure, say N.
2468
2469 config TEST_FREE_PAGES
2470         tristate "Test freeing pages"
2471         help
2472           Test that a memory leak does not occur due to a race between
2473           freeing a block of pages and a speculative page reference.
2474           Loading this module is safe if your kernel has the bug fixed.
2475           If the bug is not fixed, it will leak gigabytes of memory and
2476           probably OOM your system.
2477
2478 config TEST_FPU
2479         tristate "Test floating point operations in kernel space"
2480         depends on X86 && !KCOV_INSTRUMENT_ALL
2481         help
2482           Enable this option to add /sys/kernel/debug/selftest_helpers/test_fpu
2483           which will trigger a sequence of floating point operations. This is used
2484           for self-testing floating point control register setting in
2485           kernel_fpu_begin().
2486
2487           If unsure, say N.
2488
2489 endif # RUNTIME_TESTING_MENU
2490
2491 config MEMTEST
2492         bool "Memtest"
2493         help
2494           This option adds a kernel parameter 'memtest', which allows memtest
2495           to be set.
2496                 memtest=0, mean disabled; -- default
2497                 memtest=1, mean do 1 test pattern;
2498                 ...
2499                 memtest=17, mean do 17 test patterns.
2500           If you are unsure how to answer this question, answer N.
2501
2502
2503
2504 config HYPERV_TESTING
2505         bool "Microsoft Hyper-V driver testing"
2506         default n
2507         depends on HYPERV && DEBUG_FS
2508         help
2509           Select this option to enable Hyper-V vmbus testing.
2510
2511 endmenu # "Kernel Testing and Coverage"
2512
2513 source "Documentation/Kconfig"
2514
2515 endmenu # Kernel hacking