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