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