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