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