lib/Kconfig.debug

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