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