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