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