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