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