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 STACKTRACE_BUILD_ID 39 bool "Show build ID information in stacktraces" 40 depends on PRINTK 41 help 42 Selecting this option adds build ID information for symbols in 43 stacktraces printed with the printk format '%p[SR]b'. 44 45 This option is intended for distros where debuginfo is not easily 46 accessible but can be downloaded given the build ID of the vmlinux or 47 kernel module where the function is located. 48 49config CONSOLE_LOGLEVEL_DEFAULT 50 int "Default console loglevel (1-15)" 51 range 1 15 52 default "7" 53 help 54 Default loglevel to determine what will be printed on the console. 55 56 Setting a default here is equivalent to passing in loglevel=<x> in 57 the kernel bootargs. loglevel=<x> continues to override whatever 58 value is specified here as well. 59 60 Note: This does not affect the log level of un-prefixed printk() 61 usage in the kernel. That is controlled by the MESSAGE_LOGLEVEL_DEFAULT 62 option. 63 64config CONSOLE_LOGLEVEL_QUIET 65 int "quiet console loglevel (1-15)" 66 range 1 15 67 default "4" 68 help 69 loglevel to use when "quiet" is passed on the kernel commandline. 70 71 When "quiet" is passed on the kernel commandline this loglevel 72 will be used as the loglevel. IOW passing "quiet" will be the 73 equivalent of passing "loglevel=<CONSOLE_LOGLEVEL_QUIET>" 74 75config MESSAGE_LOGLEVEL_DEFAULT 76 int "Default message log level (1-7)" 77 range 1 7 78 default "4" 79 help 80 Default log level for printk statements with no specified priority. 81 82 This was hard-coded to KERN_WARNING since at least 2.6.10 but folks 83 that are auditing their logs closely may want to set it to a lower 84 priority. 85 86 Note: This does not affect what message level gets printed on the console 87 by default. To change that, use loglevel=<x> in the kernel bootargs, 88 or pick a different CONSOLE_LOGLEVEL_DEFAULT configuration value. 89 90config BOOT_PRINTK_DELAY 91 bool "Delay each boot printk message by N milliseconds" 92 depends on DEBUG_KERNEL && PRINTK && GENERIC_CALIBRATE_DELAY 93 help 94 This build option allows you to read kernel boot messages 95 by inserting a short delay after each one. The delay is 96 specified in milliseconds on the kernel command line, 97 using "boot_delay=N". 98 99 It is likely that you would also need to use "lpj=M" to preset 100 the "loops per jiffy" value. 101 See a previous boot log for the "lpj" value to use for your 102 system, and then set "lpj=M" before setting "boot_delay=N". 103 NOTE: Using this option may adversely affect SMP systems. 104 I.e., processors other than the first one may not boot up. 105 BOOT_PRINTK_DELAY also may cause LOCKUP_DETECTOR to detect 106 what it believes to be lockup conditions. 107 108config DYNAMIC_DEBUG 109 bool "Enable dynamic printk() support" 110 default n 111 depends on PRINTK 112 depends on (DEBUG_FS || PROC_FS) 113 select DYNAMIC_DEBUG_CORE 114 help 115 116 Compiles debug level messages into the kernel, which would not 117 otherwise be available at runtime. These messages can then be 118 enabled/disabled based on various levels of scope - per source file, 119 function, module, format string, and line number. This mechanism 120 implicitly compiles in all pr_debug() and dev_dbg() calls, which 121 enlarges the kernel text size by about 2%. 122 123 If a source file is compiled with DEBUG flag set, any 124 pr_debug() calls in it are enabled by default, but can be 125 disabled at runtime as below. Note that DEBUG flag is 126 turned on by many CONFIG_*DEBUG* options. 127 128 Usage: 129 130 Dynamic debugging is controlled via the 'dynamic_debug/control' file, 131 which is contained in the 'debugfs' filesystem or procfs. 132 Thus, the debugfs or procfs filesystem must first be mounted before 133 making use of this feature. 134 We refer the control file as: <debugfs>/dynamic_debug/control. This 135 file contains a list of the debug statements that can be enabled. The 136 format for each line of the file is: 137 138 filename:lineno [module]function flags format 139 140 filename : source file of the debug statement 141 lineno : line number of the debug statement 142 module : module that contains the debug statement 143 function : function that contains the debug statement 144 flags : '=p' means the line is turned 'on' for printing 145 format : the format used for the debug statement 146 147 From a live system: 148 149 nullarbor:~ # cat <debugfs>/dynamic_debug/control 150 # filename:lineno [module]function flags format 151 fs/aio.c:222 [aio]__put_ioctx =_ "__put_ioctx:\040freeing\040%p\012" 152 fs/aio.c:248 [aio]ioctx_alloc =_ "ENOMEM:\040nr_events\040too\040high\012" 153 fs/aio.c:1770 [aio]sys_io_cancel =_ "calling\040cancel\012" 154 155 Example usage: 156 157 // enable the message at line 1603 of file svcsock.c 158 nullarbor:~ # echo -n 'file svcsock.c line 1603 +p' > 159 <debugfs>/dynamic_debug/control 160 161 // enable all the messages in file svcsock.c 162 nullarbor:~ # echo -n 'file svcsock.c +p' > 163 <debugfs>/dynamic_debug/control 164 165 // enable all the messages in the NFS server module 166 nullarbor:~ # echo -n 'module nfsd +p' > 167 <debugfs>/dynamic_debug/control 168 169 // enable all 12 messages in the function svc_process() 170 nullarbor:~ # echo -n 'func svc_process +p' > 171 <debugfs>/dynamic_debug/control 172 173 // disable all 12 messages in the function svc_process() 174 nullarbor:~ # echo -n 'func svc_process -p' > 175 <debugfs>/dynamic_debug/control 176 177 See Documentation/admin-guide/dynamic-debug-howto.rst for additional 178 information. 179 180config DYNAMIC_DEBUG_CORE 181 bool "Enable core function of dynamic debug support" 182 depends on PRINTK 183 depends on (DEBUG_FS || PROC_FS) 184 help 185 Enable core functional support of dynamic debug. It is useful 186 when you want to tie dynamic debug to your kernel modules with 187 DYNAMIC_DEBUG_MODULE defined for each of them, especially for 188 the case of embedded system where the kernel image size is 189 sensitive for people. 190 191config SYMBOLIC_ERRNAME 192 bool "Support symbolic error names in printf" 193 default y if PRINTK 194 help 195 If you say Y here, the kernel's printf implementation will 196 be able to print symbolic error names such as ENOSPC instead 197 of the number 28. It makes the kernel image slightly larger 198 (about 3KB), but can make the kernel logs easier to read. 199 200config DEBUG_BUGVERBOSE 201 bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT 202 depends on BUG && (GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE) 203 default y 204 help 205 Say Y here to make BUG() panics output the file name and line number 206 of the BUG call as well as the EIP and oops trace. This aids 207 debugging but costs about 70-100K of memory. 208 209endmenu # "printk and dmesg options" 210 211config DEBUG_KERNEL 212 bool "Kernel debugging" 213 help 214 Say Y here if you are developing drivers or trying to debug and 215 identify kernel problems. 216 217config DEBUG_MISC 218 bool "Miscellaneous debug code" 219 default DEBUG_KERNEL 220 depends on DEBUG_KERNEL 221 help 222 Say Y here if you need to enable miscellaneous debug code that should 223 be under a more specific debug option but isn't. 224 225menu "Compile-time checks and compiler options" 226 227config DEBUG_INFO 228 bool 229 help 230 A kernel debug info option other than "None" has been selected 231 in the "Debug information" choice below, indicating that debug 232 information will be generated for build targets. 233 234# Clang generates .uleb128 with label differences for DWARF v5, a feature that 235# older binutils ports do not support when utilizing RISC-V style linker 236# relaxation: https://sourceware.org/bugzilla/show_bug.cgi?id=27215 237config AS_HAS_NON_CONST_ULEB128 238 def_bool $(as-instr,.uleb128 .Lexpr_end4 - .Lexpr_start3\n.Lexpr_start3:\n.Lexpr_end4:) 239 240choice 241 prompt "Debug information" 242 depends on DEBUG_KERNEL 243 help 244 Selecting something other than "None" results in a kernel image 245 that will include debugging info resulting in a larger kernel image. 246 This adds debug symbols to the kernel and modules (gcc -g), and 247 is needed if you intend to use kernel crashdump or binary object 248 tools like crash, kgdb, LKCD, gdb, etc on the kernel. 249 250 Choose which version of DWARF debug info to emit. If unsure, 251 select "Toolchain default". 252 253config DEBUG_INFO_NONE 254 bool "Disable debug information" 255 help 256 Do not build the kernel with debugging information, which will 257 result in a faster and smaller build. 258 259config DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT 260 bool "Rely on the toolchain's implicit default DWARF version" 261 select DEBUG_INFO 262 depends on !CC_IS_CLANG || AS_IS_LLVM || CLANG_VERSION < 140000 || (AS_IS_GNU && AS_VERSION >= 23502 && AS_HAS_NON_CONST_ULEB128) 263 help 264 The implicit default version of DWARF debug info produced by a 265 toolchain changes over time. 266 267 This can break consumers of the debug info that haven't upgraded to 268 support newer revisions, and prevent testing newer versions, but 269 those should be less common scenarios. 270 271config DEBUG_INFO_DWARF4 272 bool "Generate DWARF Version 4 debuginfo" 273 select DEBUG_INFO 274 depends on !CC_IS_CLANG || AS_IS_LLVM || (AS_IS_GNU && AS_VERSION >= 23502) 275 help 276 Generate DWARF v4 debug info. This requires gcc 4.5+, binutils 2.35.2 277 if using clang without clang's integrated assembler, and gdb 7.0+. 278 279 If you have consumers of DWARF debug info that are not ready for 280 newer revisions of DWARF, you may wish to choose this or have your 281 config select this. 282 283config DEBUG_INFO_DWARF5 284 bool "Generate DWARF Version 5 debuginfo" 285 select DEBUG_INFO 286 depends on !ARCH_HAS_BROKEN_DWARF5 287 depends on !CC_IS_CLANG || AS_IS_LLVM || (AS_IS_GNU && AS_VERSION >= 23502 && AS_HAS_NON_CONST_ULEB128) 288 help 289 Generate DWARF v5 debug info. Requires binutils 2.35.2, gcc 5.0+ (gcc 290 5.0+ accepts the -gdwarf-5 flag but only had partial support for some 291 draft features until 7.0), and gdb 8.0+. 292 293 Changes to the structure of debug info in Version 5 allow for around 294 15-18% savings in resulting image and debug info section sizes as 295 compared to DWARF Version 4. DWARF Version 5 standardizes previous 296 extensions such as accelerators for symbol indexing and the format 297 for fission (.dwo/.dwp) files. Users may not want to select this 298 config if they rely on tooling that has not yet been updated to 299 support DWARF Version 5. 300 301endchoice # "Debug information" 302 303if DEBUG_INFO 304 305config DEBUG_INFO_REDUCED 306 bool "Reduce debugging information" 307 help 308 If you say Y here gcc is instructed to generate less debugging 309 information for structure types. This means that tools that 310 need full debugging information (like kgdb or systemtap) won't 311 be happy. But if you merely need debugging information to 312 resolve line numbers there is no loss. Advantage is that 313 build directory object sizes shrink dramatically over a full 314 DEBUG_INFO build and compile times are reduced too. 315 Only works with newer gcc versions. 316 317choice 318 prompt "Compressed Debug information" 319 help 320 Compress the resulting debug info. Results in smaller debug info sections, 321 but requires that consumers are able to decompress the results. 322 323 If unsure, choose DEBUG_INFO_COMPRESSED_NONE. 324 325config DEBUG_INFO_COMPRESSED_NONE 326 bool "Don't compress debug information" 327 help 328 Don't compress debug info sections. 329 330config DEBUG_INFO_COMPRESSED_ZLIB 331 bool "Compress debugging information with zlib" 332 depends on $(cc-option,-gz=zlib) 333 depends on $(ld-option,--compress-debug-sections=zlib) 334 help 335 Compress the debug information using zlib. Requires GCC 5.0+ or Clang 336 5.0+, binutils 2.26+, and zlib. 337 338 Users of dpkg-deb via debian/rules may find an increase in 339 size of their debug .deb packages with this config set, due to the 340 debug info being compressed with zlib, then the object files being 341 recompressed with a different compression scheme. But this is still 342 preferable to setting KDEB_COMPRESS or DPKG_DEB_COMPRESSOR_TYPE to 343 "none" which would be even larger. 344 345config DEBUG_INFO_COMPRESSED_ZSTD 346 bool "Compress debugging information with zstd" 347 depends on $(cc-option,-gz=zstd) 348 depends on $(ld-option,--compress-debug-sections=zstd) 349 help 350 Compress the debug information using zstd. This may provide better 351 compression than zlib, for about the same time costs, but requires newer 352 toolchain support. Requires GCC 13.0+ or Clang 16.0+, binutils 2.40+, and 353 zstd. 354 355endchoice # "Compressed Debug information" 356 357config DEBUG_INFO_SPLIT 358 bool "Produce split debuginfo in .dwo files" 359 depends on $(cc-option,-gsplit-dwarf) 360 # RISC-V linker relaxation + -gsplit-dwarf has issues with LLVM and GCC 361 # prior to 12.x: 362 # https://github.com/llvm/llvm-project/issues/56642 363 # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99090 364 depends on !RISCV || GCC_VERSION >= 120000 365 help 366 Generate debug info into separate .dwo files. This significantly 367 reduces the build directory size for builds with DEBUG_INFO, 368 because it stores the information only once on disk in .dwo 369 files instead of multiple times in object files and executables. 370 In addition the debug information is also compressed. 371 372 Requires recent gcc (4.7+) and recent gdb/binutils. 373 Any tool that packages or reads debug information would need 374 to know about the .dwo files and include them. 375 Incompatible with older versions of ccache. 376 377config DEBUG_INFO_BTF 378 bool "Generate BTF type information" 379 depends on !DEBUG_INFO_SPLIT && !DEBUG_INFO_REDUCED 380 depends on !GCC_PLUGIN_RANDSTRUCT || COMPILE_TEST 381 depends on BPF_SYSCALL 382 depends on PAHOLE_VERSION >= 116 383 depends on DEBUG_INFO_DWARF4 || PAHOLE_VERSION >= 121 384 # pahole uses elfutils, which does not have support for Hexagon relocations 385 depends on !HEXAGON 386 help 387 Generate deduplicated BTF type information from DWARF debug info. 388 Turning this on requires pahole v1.16 or later (v1.21 or later to 389 support DWARF 5), which will convert DWARF type info into equivalent 390 deduplicated BTF type info. 391 392config PAHOLE_HAS_SPLIT_BTF 393 def_bool PAHOLE_VERSION >= 119 394 395config PAHOLE_HAS_BTF_TAG 396 def_bool PAHOLE_VERSION >= 123 397 depends on CC_IS_CLANG 398 help 399 Decide whether pahole emits btf_tag attributes (btf_type_tag and 400 btf_decl_tag) or not. Currently only clang compiler implements 401 these attributes, so make the config depend on CC_IS_CLANG. 402 403config PAHOLE_HAS_LANG_EXCLUDE 404 def_bool PAHOLE_VERSION >= 124 405 help 406 Support for the --lang_exclude flag which makes pahole exclude 407 compilation units from the supplied language. Used in Kbuild to 408 omit Rust CUs which are not supported in version 1.24 of pahole, 409 otherwise it would emit malformed kernel and module binaries when 410 using DEBUG_INFO_BTF_MODULES. 411 412config DEBUG_INFO_BTF_MODULES 413 bool "Generate BTF type information for kernel modules" 414 default y 415 depends on DEBUG_INFO_BTF && MODULES && PAHOLE_HAS_SPLIT_BTF 416 help 417 Generate compact split BTF type information for kernel modules. 418 419config MODULE_ALLOW_BTF_MISMATCH 420 bool "Allow loading modules with non-matching BTF type info" 421 depends on DEBUG_INFO_BTF_MODULES 422 help 423 For modules whose split BTF does not match vmlinux, load without 424 BTF rather than refusing to load. The default behavior with 425 module BTF enabled is to reject modules with such mismatches; 426 this option will still load module BTF where possible but ignore 427 it when a mismatch is found. 428 429config GDB_SCRIPTS 430 bool "Provide GDB scripts for kernel debugging" 431 help 432 This creates the required links to GDB helper scripts in the 433 build directory. If you load vmlinux into gdb, the helper 434 scripts will be automatically imported by gdb as well, and 435 additional functions are available to analyze a Linux kernel 436 instance. See Documentation/process/debugging/gdb-kernel-debugging.rst 437 for further details. 438 439endif # DEBUG_INFO 440 441config FRAME_WARN 442 int "Warn for stack frames larger than" 443 range 0 8192 444 default 0 if KMSAN 445 default 2048 if GCC_PLUGIN_LATENT_ENTROPY 446 default 2048 if PARISC 447 default 1536 if (!64BIT && XTENSA) 448 default 1280 if KASAN && !64BIT 449 default 1024 if !64BIT 450 default 2048 if 64BIT 451 help 452 Tell the compiler to warn at build time for stack frames larger than this. 453 Setting this too low will cause a lot of warnings. 454 Setting it to 0 disables the warning. 455 456config STRIP_ASM_SYMS 457 bool "Strip assembler-generated symbols during link" 458 default n 459 help 460 Strip internal assembler-generated symbols during a link (symbols 461 that look like '.Lxxx') so they don't pollute the output of 462 get_wchan() and suchlike. 463 464config READABLE_ASM 465 bool "Generate readable assembler code" 466 depends on DEBUG_KERNEL 467 depends on CC_IS_GCC 468 help 469 Disable some compiler optimizations that tend to generate human unreadable 470 assembler output. This may make the kernel slightly slower, but it helps 471 to keep kernel developers who have to stare a lot at assembler listings 472 sane. 473 474config HEADERS_INSTALL 475 bool "Install uapi headers to usr/include" 476 help 477 This option will install uapi headers (headers exported to user-space) 478 into the usr/include directory for use during the kernel build. 479 This is unneeded for building the kernel itself, but needed for some 480 user-space program samples. It is also needed by some features such 481 as uapi header sanity checks. 482 483config DEBUG_SECTION_MISMATCH 484 bool "Enable full Section mismatch analysis" 485 depends on CC_IS_GCC 486 help 487 The section mismatch analysis checks if there are illegal 488 references from one section to another section. 489 During linktime or runtime, some sections are dropped; 490 any use of code/data previously in these sections would 491 most likely result in an oops. 492 In the code, functions and variables are annotated with 493 __init,, etc. (see the full list in include/linux/init.h), 494 which results in the code/data being placed in specific sections. 495 The section mismatch analysis is always performed after a full 496 kernel build, and enabling this option causes the following 497 additional step to occur: 498 - Add the option -fno-inline-functions-called-once to gcc commands. 499 When inlining a function annotated with __init in a non-init 500 function, we would lose the section information and thus 501 the analysis would not catch the illegal reference. 502 This option tells gcc to inline less (but it does result in 503 a larger kernel). 504 505config SECTION_MISMATCH_WARN_ONLY 506 bool "Make section mismatch errors non-fatal" 507 default y 508 help 509 If you say N here, the build process will fail if there are any 510 section mismatch, instead of just throwing warnings. 511 512 If unsure, say Y. 513 514config DEBUG_FORCE_FUNCTION_ALIGN_64B 515 bool "Force all function address 64B aligned" 516 depends on EXPERT && (X86_64 || ARM64 || PPC32 || PPC64 || ARC || RISCV || S390) 517 select FUNCTION_ALIGNMENT_64B 518 help 519 There are cases that a commit from one domain changes the function 520 address alignment of other domains, and cause magic performance 521 bump (regression or improvement). Enable this option will help to 522 verify if the bump is caused by function alignment changes, while 523 it will slightly increase the kernel size and affect icache usage. 524 525 It is mainly for debug and performance tuning use. 526 527# 528# Select this config option from the architecture Kconfig, if it 529# is preferred to always offer frame pointers as a config 530# option on the architecture (regardless of KERNEL_DEBUG): 531# 532config ARCH_WANT_FRAME_POINTERS 533 bool 534 535config FRAME_POINTER 536 bool "Compile the kernel with frame pointers" 537 depends on DEBUG_KERNEL && (M68K || UML || SUPERH) || ARCH_WANT_FRAME_POINTERS 538 default y if (DEBUG_INFO && UML) || ARCH_WANT_FRAME_POINTERS 539 help 540 If you say Y here the resulting kernel image will be slightly 541 larger and slower, but it gives very useful debugging information 542 in case of kernel bugs. (precise oopses/stacktraces/warnings) 543 544config OBJTOOL 545 bool 546 547config OBJTOOL_WERROR 548 bool "Upgrade objtool warnings to errors" 549 depends on OBJTOOL && !COMPILE_TEST 550 help 551 Fail the build on objtool warnings. 552 553 Objtool warnings can indicate kernel instability, including boot 554 failures. This option is highly recommended. 555 556 If unsure, say Y. 557 558config STACK_VALIDATION 559 bool "Compile-time stack metadata validation" 560 depends on HAVE_STACK_VALIDATION && UNWINDER_FRAME_POINTER 561 select OBJTOOL 562 default n 563 help 564 Validate frame pointer rules at compile-time. This helps ensure that 565 runtime stack traces are more reliable. 566 567 For more information, see 568 tools/objtool/Documentation/objtool.txt. 569 570config NOINSTR_VALIDATION 571 bool 572 depends on HAVE_NOINSTR_VALIDATION && DEBUG_ENTRY 573 select OBJTOOL 574 default y 575 576config VMLINUX_MAP 577 bool "Generate vmlinux.map file when linking" 578 depends on EXPERT 579 help 580 Selecting this option will pass "-Map=vmlinux.map" to ld 581 when linking vmlinux. That file can be useful for verifying 582 and debugging magic section games, and for seeing which 583 pieces of code get eliminated with 584 CONFIG_LD_DEAD_CODE_DATA_ELIMINATION. 585 586config BUILTIN_MODULE_RANGES 587 bool "Generate address range information for builtin modules" 588 depends on !LTO 589 depends on VMLINUX_MAP 590 help 591 When modules are built into the kernel, there will be no module name 592 associated with its symbols in /proc/kallsyms. Tracers may want to 593 identify symbols by module name and symbol name regardless of whether 594 the module is configured as loadable or not. 595 596 This option generates modules.builtin.ranges in the build tree with 597 offset ranges (per ELF section) for the module(s) they belong to. 598 It also records an anchor symbol to determine the load address of the 599 section. 600 601config DEBUG_FORCE_WEAK_PER_CPU 602 bool "Force weak per-cpu definitions" 603 depends on DEBUG_KERNEL 604 help 605 s390 and alpha require percpu variables in modules to be 606 defined weak to work around addressing range issue which 607 puts the following two restrictions on percpu variable 608 definitions. 609 610 1. percpu symbols must be unique whether static or not 611 2. percpu variables can't be defined inside a function 612 613 To ensure that generic code follows the above rules, this 614 option forces all percpu variables to be defined as weak. 615 616endmenu # "Compiler options" 617 618menu "Generic Kernel Debugging Instruments" 619 620config MAGIC_SYSRQ 621 bool "Magic SysRq key" 622 depends on !UML 623 help 624 If you say Y here, you will have some control over the system even 625 if the system crashes for example during kernel debugging (e.g., you 626 will be able to flush the buffer cache to disk, reboot the system 627 immediately or dump some status information). This is accomplished 628 by pressing various keys while holding SysRq (Alt+PrintScreen). It 629 also works on a serial console (on PC hardware at least), if you 630 send a BREAK and then within 5 seconds a command keypress. The 631 keys are documented in <file:Documentation/admin-guide/sysrq.rst>. 632 Don't say Y unless you really know what this hack does. 633 634config MAGIC_SYSRQ_DEFAULT_ENABLE 635 hex "Enable magic SysRq key functions by default" 636 depends on MAGIC_SYSRQ 637 default 0x1 638 help 639 Specifies which SysRq key functions are enabled by default. 640 This may be set to 1 or 0 to enable or disable them all, or 641 to a bitmask as described in Documentation/admin-guide/sysrq.rst. 642 643config MAGIC_SYSRQ_SERIAL 644 bool "Enable magic SysRq key over serial" 645 depends on MAGIC_SYSRQ 646 default y 647 help 648 Many embedded boards have a disconnected TTL level serial which can 649 generate some garbage that can lead to spurious false sysrq detects. 650 This option allows you to decide whether you want to enable the 651 magic SysRq key. 652 653config MAGIC_SYSRQ_SERIAL_SEQUENCE 654 string "Char sequence that enables magic SysRq over serial" 655 depends on MAGIC_SYSRQ_SERIAL 656 default "" 657 help 658 Specifies a sequence of characters that can follow BREAK to enable 659 SysRq on a serial console. 660 661 If unsure, leave an empty string and the option will not be enabled. 662 663config DEBUG_FS 664 bool "Debug Filesystem" 665 help 666 debugfs is a virtual file system that kernel developers use to put 667 debugging files into. Enable this option to be able to read and 668 write to these files. 669 670 For detailed documentation on the debugfs API, see 671 Documentation/filesystems/. 672 673 If unsure, say N. 674 675choice 676 prompt "Debugfs default access" 677 depends on DEBUG_FS 678 default DEBUG_FS_ALLOW_ALL 679 help 680 This selects the default access restrictions for debugfs. 681 It can be overridden with kernel command line option 682 debugfs=[on,no-mount,off]. The restrictions apply for API access 683 and filesystem registration. 684 685config DEBUG_FS_ALLOW_ALL 686 bool "Access normal" 687 help 688 No restrictions apply. Both API and filesystem registration 689 is on. This is the normal default operation. 690 691config DEBUG_FS_DISALLOW_MOUNT 692 bool "Do not register debugfs as filesystem" 693 help 694 The API is open but filesystem is not loaded. Clients can still do 695 their work and read with debug tools that do not need 696 debugfs filesystem. 697 698config DEBUG_FS_ALLOW_NONE 699 bool "No access" 700 help 701 Access is off. Clients get -PERM when trying to create nodes in 702 debugfs tree and debugfs is not registered as a filesystem. 703 Client can then back-off or continue without debugfs access. 704 705endchoice 706 707source "lib/Kconfig.kgdb" 708source "lib/Kconfig.ubsan" 709source "lib/Kconfig.kcsan" 710 711endmenu 712 713menu "Networking Debugging" 714 715source "net/Kconfig.debug" 716 717endmenu # "Networking Debugging" 718 719menu "Memory Debugging" 720 721source "mm/Kconfig.debug" 722 723config DEBUG_OBJECTS 724 bool "Debug object operations" 725 depends on DEBUG_KERNEL 726 help 727 If you say Y here, additional code will be inserted into the 728 kernel to track the life time of various objects and validate 729 the operations on those objects. 730 731config DEBUG_OBJECTS_SELFTEST 732 bool "Debug objects selftest" 733 depends on DEBUG_OBJECTS 734 help 735 This enables the selftest of the object debug code. 736 737config DEBUG_OBJECTS_FREE 738 bool "Debug objects in freed memory" 739 depends on DEBUG_OBJECTS 740 help 741 This enables checks whether a k/v free operation frees an area 742 which contains an object which has not been deactivated 743 properly. This can make kmalloc/kfree-intensive workloads 744 much slower. 745 746config DEBUG_OBJECTS_TIMERS 747 bool "Debug timer objects" 748 depends on DEBUG_OBJECTS 749 help 750 If you say Y here, additional code will be inserted into the 751 timer routines to track the life time of timer objects and 752 validate the timer operations. 753 754config DEBUG_OBJECTS_WORK 755 bool "Debug work objects" 756 depends on DEBUG_OBJECTS 757 help 758 If you say Y here, additional code will be inserted into the 759 work queue routines to track the life time of work objects and 760 validate the work operations. 761 762config DEBUG_OBJECTS_RCU_HEAD 763 bool "Debug RCU callbacks objects" 764 depends on DEBUG_OBJECTS 765 help 766 Enable this to turn on debugging of RCU list heads (call_rcu() usage). 767 768config DEBUG_OBJECTS_PERCPU_COUNTER 769 bool "Debug percpu counter objects" 770 depends on DEBUG_OBJECTS 771 help 772 If you say Y here, additional code will be inserted into the 773 percpu counter routines to track the life time of percpu counter 774 objects and validate the percpu counter operations. 775 776config DEBUG_OBJECTS_ENABLE_DEFAULT 777 int "debug_objects bootup default value (0-1)" 778 range 0 1 779 default "1" 780 depends on DEBUG_OBJECTS 781 help 782 Debug objects boot parameter default value 783 784config SHRINKER_DEBUG 785 bool "Enable shrinker debugging support" 786 depends on DEBUG_FS 787 help 788 Say Y to enable the shrinker debugfs interface which provides 789 visibility into the kernel memory shrinkers subsystem. 790 Disable it to avoid an extra memory footprint. 791 792config DEBUG_STACK_USAGE 793 bool "Stack utilization instrumentation" 794 depends on DEBUG_KERNEL 795 help 796 Enables the display of the minimum amount of free stack which each 797 task has ever had available in the sysrq-T and sysrq-P debug output. 798 Also emits a message to dmesg when a process exits if that process 799 used more stack space than previously exiting processes. 800 801 This option will slow down process creation somewhat. 802 803config SCHED_STACK_END_CHECK 804 bool "Detect stack corruption on calls to schedule()" 805 depends on DEBUG_KERNEL 806 default n 807 help 808 This option checks for a stack overrun on calls to schedule(). 809 If the stack end location is found to be over written always panic as 810 the content of the corrupted region can no longer be trusted. 811 This is to ensure no erroneous behaviour occurs which could result in 812 data corruption or a sporadic crash at a later stage once the region 813 is examined. The runtime overhead introduced is minimal. 814 815config ARCH_HAS_DEBUG_VM_PGTABLE 816 bool 817 help 818 An architecture should select this when it can successfully 819 build and run DEBUG_VM_PGTABLE. 820 821config DEBUG_VFS 822 bool "Debug VFS" 823 depends on DEBUG_KERNEL 824 help 825 Enable this to turn on extended checks in the VFS layer that may impact 826 performance. 827 828 If unsure, say N. 829 830config DEBUG_VM_IRQSOFF 831 def_bool DEBUG_VM && !PREEMPT_RT 832 833config DEBUG_VM 834 bool "Debug VM" 835 depends on DEBUG_KERNEL 836 help 837 Enable this to turn on extended checks in the virtual-memory system 838 that may impact performance. 839 840 If unsure, say N. 841 842config DEBUG_VM_SHOOT_LAZIES 843 bool "Debug MMU_LAZY_TLB_SHOOTDOWN implementation" 844 depends on DEBUG_VM 845 depends on MMU_LAZY_TLB_SHOOTDOWN 846 help 847 Enable additional IPIs that ensure lazy tlb mm references are removed 848 before the mm is freed. 849 850 If unsure, say N. 851 852config DEBUG_VM_MAPLE_TREE 853 bool "Debug VM maple trees" 854 depends on DEBUG_VM 855 select DEBUG_MAPLE_TREE 856 help 857 Enable VM maple tree debugging information and extra validations. 858 859 If unsure, say N. 860 861config DEBUG_VM_RB 862 bool "Debug VM red-black trees" 863 depends on DEBUG_VM 864 help 865 Enable VM red-black tree debugging information and extra validations. 866 867 If unsure, say N. 868 869config DEBUG_VM_PGFLAGS 870 bool "Debug page-flags operations" 871 depends on DEBUG_VM 872 help 873 Enables extra validation on page flags operations. 874 875 If unsure, say N. 876 877config DEBUG_VM_PGTABLE 878 bool "Debug arch page table for semantics compliance" 879 depends on MMU 880 depends on ARCH_HAS_DEBUG_VM_PGTABLE 881 default y if DEBUG_VM 882 help 883 This option provides a debug method which can be used to test 884 architecture page table helper functions on various platforms in 885 verifying if they comply with expected generic MM semantics. This 886 will help architecture code in making sure that any changes or 887 new additions of these helpers still conform to expected 888 semantics of the generic MM. Platforms will have to opt in for 889 this through ARCH_HAS_DEBUG_VM_PGTABLE. 890 891 If unsure, say N. 892 893config ARCH_HAS_DEBUG_VIRTUAL 894 bool 895 896config DEBUG_VIRTUAL 897 bool "Debug VM translations" 898 depends on DEBUG_KERNEL && ARCH_HAS_DEBUG_VIRTUAL 899 help 900 Enable some costly sanity checks in virtual to page code. This can 901 catch mistakes with virt_to_page() and friends. 902 903 If unsure, say N. 904 905config DEBUG_NOMMU_REGIONS 906 bool "Debug the global anon/private NOMMU mapping region tree" 907 depends on DEBUG_KERNEL && !MMU 908 help 909 This option causes the global tree of anonymous and private mapping 910 regions to be regularly checked for invalid topology. 911 912config DEBUG_MEMORY_INIT 913 bool "Debug memory initialisation" if EXPERT 914 default !EXPERT 915 help 916 Enable this for additional checks during memory initialisation. 917 The sanity checks verify aspects of the VM such as the memory model 918 and other information provided by the architecture. Verbose 919 information will be printed at KERN_DEBUG loglevel depending 920 on the mminit_loglevel= command-line option. 921 922 If unsure, say Y 923 924config MEMORY_NOTIFIER_ERROR_INJECT 925 tristate "Memory hotplug notifier error injection module" 926 depends on MEMORY_HOTPLUG && NOTIFIER_ERROR_INJECTION 927 help 928 This option provides the ability to inject artificial errors to 929 memory hotplug notifier chain callbacks. It is controlled through 930 debugfs interface under /sys/kernel/debug/notifier-error-inject/memory 931 932 If the notifier call chain should be failed with some events 933 notified, write the error code to "actions/<notifier event>/error". 934 935 Example: Inject memory hotplug offline error (-12 == -ENOMEM) 936 937 # cd /sys/kernel/debug/notifier-error-inject/memory 938 # echo -12 > actions/MEM_GOING_OFFLINE/error 939 # echo offline > /sys/devices/system/memory/memoryXXX/state 940 bash: echo: write error: Cannot allocate memory 941 942 To compile this code as a module, choose M here: the module will 943 be called memory-notifier-error-inject. 944 945 If unsure, say N. 946 947config DEBUG_PER_CPU_MAPS 948 bool "Debug access to per_cpu maps" 949 depends on DEBUG_KERNEL 950 depends on SMP 951 help 952 Say Y to verify that the per_cpu map being accessed has 953 been set up. This adds a fair amount of code to kernel memory 954 and decreases performance. 955 956 Say N if unsure. 957 958config DEBUG_KMAP_LOCAL 959 bool "Debug kmap_local temporary mappings" 960 depends on DEBUG_KERNEL && KMAP_LOCAL 961 help 962 This option enables additional error checking for the kmap_local 963 infrastructure. Disable for production use. 964 965config ARCH_SUPPORTS_KMAP_LOCAL_FORCE_MAP 966 bool 967 968config DEBUG_KMAP_LOCAL_FORCE_MAP 969 bool "Enforce kmap_local temporary mappings" 970 depends on DEBUG_KERNEL && ARCH_SUPPORTS_KMAP_LOCAL_FORCE_MAP 971 select KMAP_LOCAL 972 select DEBUG_KMAP_LOCAL 973 help 974 This option enforces temporary mappings through the kmap_local 975 mechanism for non-highmem pages and on non-highmem systems. 976 Disable this for production systems! 977 978config DEBUG_HIGHMEM 979 bool "Highmem debugging" 980 depends on DEBUG_KERNEL && HIGHMEM 981 select DEBUG_KMAP_LOCAL_FORCE_MAP if ARCH_SUPPORTS_KMAP_LOCAL_FORCE_MAP 982 select DEBUG_KMAP_LOCAL 983 help 984 This option enables additional error checking for high memory 985 systems. Disable for production systems. 986 987config HAVE_DEBUG_STACKOVERFLOW 988 bool 989 990config DEBUG_STACKOVERFLOW 991 bool "Check for stack overflows" 992 depends on DEBUG_KERNEL && HAVE_DEBUG_STACKOVERFLOW 993 help 994 Say Y here if you want to check for overflows of kernel, IRQ 995 and exception stacks (if your architecture uses them). This 996 option will show detailed messages if free stack space drops 997 below a certain limit. 998 999 These kinds of bugs usually occur when call-chains in the 1000 kernel get too deep, especially when interrupts are 1001 involved. 1002 1003 Use this in cases where you see apparently random memory 1004 corruption, especially if it appears in 'struct thread_info' 1005 1006 If in doubt, say "N". 1007 1008config CODE_TAGGING 1009 bool 1010 select KALLSYMS 1011 1012config MEM_ALLOC_PROFILING 1013 bool "Enable memory allocation profiling" 1014 default n 1015 depends on MMU 1016 depends on PROC_FS 1017 depends on !DEBUG_FORCE_WEAK_PER_CPU 1018 select CODE_TAGGING 1019 select PAGE_EXTENSION 1020 select SLAB_OBJ_EXT 1021 help 1022 Track allocation source code and record total allocation size 1023 initiated at that code location. The mechanism can be used to track 1024 memory leaks with a low performance and memory impact. 1025 1026config MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT 1027 bool "Enable memory allocation profiling by default" 1028 default y 1029 depends on MEM_ALLOC_PROFILING 1030 1031config MEM_ALLOC_PROFILING_DEBUG 1032 bool "Memory allocation profiler debugging" 1033 default n 1034 depends on MEM_ALLOC_PROFILING 1035 select MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT 1036 help 1037 Adds warnings with helpful error messages for memory allocation 1038 profiling. 1039 1040source "lib/Kconfig.kasan" 1041source "lib/Kconfig.kfence" 1042source "lib/Kconfig.kmsan" 1043 1044endmenu # "Memory Debugging" 1045 1046config DEBUG_SHIRQ 1047 bool "Debug shared IRQ handlers" 1048 depends on DEBUG_KERNEL 1049 help 1050 Enable this to generate a spurious interrupt just before a shared 1051 interrupt handler is deregistered (generating one when registering 1052 is currently disabled). Drivers need to handle this correctly. Some 1053 don't and need to be caught. 1054 1055menu "Debug Oops, Lockups and Hangs" 1056 1057config PANIC_ON_OOPS 1058 bool "Panic on Oops" 1059 help 1060 Say Y here to enable the kernel to panic when it oopses. This 1061 has the same effect as setting oops=panic on the kernel command 1062 line. 1063 1064 This feature is useful to ensure that the kernel does not do 1065 anything erroneous after an oops which could result in data 1066 corruption or other issues. 1067 1068 Say N if unsure. 1069 1070config PANIC_ON_OOPS_VALUE 1071 int 1072 range 0 1 1073 default 0 if !PANIC_ON_OOPS 1074 default 1 if PANIC_ON_OOPS 1075 1076config PANIC_TIMEOUT 1077 int "panic timeout" 1078 default 0 1079 help 1080 Set the timeout value (in seconds) until a reboot occurs when 1081 the kernel panics. If n = 0, then we wait forever. A timeout 1082 value n > 0 will wait n seconds before rebooting, while a timeout 1083 value n < 0 will reboot immediately. This setting can be overridden 1084 with the kernel command line option panic=, and from userspace via 1085 /proc/sys/kernel/panic. 1086 1087config LOCKUP_DETECTOR 1088 bool 1089 1090config SOFTLOCKUP_DETECTOR 1091 bool "Detect Soft Lockups" 1092 depends on DEBUG_KERNEL && !S390 1093 select LOCKUP_DETECTOR 1094 help 1095 Say Y here to enable the kernel to act as a watchdog to detect 1096 soft lockups. 1097 1098 Softlockups are bugs that cause the kernel to loop in kernel 1099 mode for more than 20 seconds, without giving other tasks a 1100 chance to run. The current stack trace is displayed upon 1101 detection and the system will stay locked up. 1102 1103config SOFTLOCKUP_DETECTOR_INTR_STORM 1104 bool "Detect Interrupt Storm in Soft Lockups" 1105 depends on SOFTLOCKUP_DETECTOR && IRQ_TIME_ACCOUNTING 1106 select GENERIC_IRQ_STAT_SNAPSHOT 1107 default y if NR_CPUS <= 128 1108 help 1109 Say Y here to enable the kernel to detect interrupt storm 1110 during "soft lockups". 1111 1112 "soft lockups" can be caused by a variety of reasons. If one is 1113 caused by an interrupt storm, then the storming interrupts will not 1114 be on the callstack. To detect this case, it is necessary to report 1115 the CPU stats and the interrupt counts during the "soft lockups". 1116 1117config BOOTPARAM_SOFTLOCKUP_PANIC 1118 bool "Panic (Reboot) On Soft Lockups" 1119 depends on SOFTLOCKUP_DETECTOR 1120 help 1121 Say Y here to enable the kernel to panic on "soft lockups", 1122 which are bugs that cause the kernel to loop in kernel 1123 mode for more than 20 seconds (configurable using the watchdog_thresh 1124 sysctl), without giving other tasks a chance to run. 1125 1126 The panic can be used in combination with panic_timeout, 1127 to cause the system to reboot automatically after a 1128 lockup has been detected. This feature is useful for 1129 high-availability systems that have uptime guarantees and 1130 where a lockup must be resolved ASAP. 1131 1132 Say N if unsure. 1133 1134config HAVE_HARDLOCKUP_DETECTOR_BUDDY 1135 bool 1136 depends on SMP 1137 default y 1138 1139# 1140# Global switch whether to build a hardlockup detector at all. It is available 1141# only when the architecture supports at least one implementation. There are 1142# two exceptions. The hardlockup detector is never enabled on: 1143# 1144# s390: it reported many false positives there 1145# 1146# sparc64: has a custom implementation which is not using the common 1147# hardlockup command line options and sysctl interface. 1148# 1149config HARDLOCKUP_DETECTOR 1150 bool "Detect Hard Lockups" 1151 depends on DEBUG_KERNEL && !S390 && !HARDLOCKUP_DETECTOR_SPARC64 1152 depends on HAVE_HARDLOCKUP_DETECTOR_PERF || HAVE_HARDLOCKUP_DETECTOR_BUDDY || HAVE_HARDLOCKUP_DETECTOR_ARCH 1153 imply HARDLOCKUP_DETECTOR_PERF 1154 imply HARDLOCKUP_DETECTOR_BUDDY 1155 imply HARDLOCKUP_DETECTOR_ARCH 1156 select LOCKUP_DETECTOR 1157 1158 help 1159 Say Y here to enable the kernel to act as a watchdog to detect 1160 hard lockups. 1161 1162 Hardlockups are bugs that cause the CPU to loop in kernel mode 1163 for more than 10 seconds, without letting other interrupts have a 1164 chance to run. The current stack trace is displayed upon detection 1165 and the system will stay locked up. 1166 1167# 1168# Note that arch-specific variants are always preferred. 1169# 1170config HARDLOCKUP_DETECTOR_PREFER_BUDDY 1171 bool "Prefer the buddy CPU hardlockup detector" 1172 depends on HARDLOCKUP_DETECTOR 1173 depends on HAVE_HARDLOCKUP_DETECTOR_PERF && HAVE_HARDLOCKUP_DETECTOR_BUDDY 1174 depends on !HAVE_HARDLOCKUP_DETECTOR_ARCH 1175 help 1176 Say Y here to prefer the buddy hardlockup detector over the perf one. 1177 1178 With the buddy detector, each CPU uses its softlockup hrtimer 1179 to check that the next CPU is processing hrtimer interrupts by 1180 verifying that a counter is increasing. 1181 1182 This hardlockup detector is useful on systems that don't have 1183 an arch-specific hardlockup detector or if resources needed 1184 for the hardlockup detector are better used for other things. 1185 1186config HARDLOCKUP_DETECTOR_PERF 1187 bool 1188 depends on HARDLOCKUP_DETECTOR 1189 depends on HAVE_HARDLOCKUP_DETECTOR_PERF && !HARDLOCKUP_DETECTOR_PREFER_BUDDY 1190 depends on !HAVE_HARDLOCKUP_DETECTOR_ARCH 1191 select HARDLOCKUP_DETECTOR_COUNTS_HRTIMER 1192 1193config HARDLOCKUP_DETECTOR_BUDDY 1194 bool 1195 depends on HARDLOCKUP_DETECTOR 1196 depends on HAVE_HARDLOCKUP_DETECTOR_BUDDY 1197 depends on !HAVE_HARDLOCKUP_DETECTOR_PERF || HARDLOCKUP_DETECTOR_PREFER_BUDDY 1198 depends on !HAVE_HARDLOCKUP_DETECTOR_ARCH 1199 select HARDLOCKUP_DETECTOR_COUNTS_HRTIMER 1200 1201config HARDLOCKUP_DETECTOR_ARCH 1202 bool 1203 depends on HARDLOCKUP_DETECTOR 1204 depends on HAVE_HARDLOCKUP_DETECTOR_ARCH 1205 help 1206 The arch-specific implementation of the hardlockup detector will 1207 be used. 1208 1209# 1210# Both the "perf" and "buddy" hardlockup detectors count hrtimer 1211# interrupts. This config enables functions managing this common code. 1212# 1213config HARDLOCKUP_DETECTOR_COUNTS_HRTIMER 1214 bool 1215 select SOFTLOCKUP_DETECTOR 1216 1217# 1218# Enables a timestamp based low pass filter to compensate for perf based 1219# hard lockup detection which runs too fast due to turbo modes. 1220# 1221config HARDLOCKUP_CHECK_TIMESTAMP 1222 bool 1223 1224config BOOTPARAM_HARDLOCKUP_PANIC 1225 bool "Panic (Reboot) On Hard Lockups" 1226 depends on HARDLOCKUP_DETECTOR 1227 help 1228 Say Y here to enable the kernel to panic on "hard lockups", 1229 which are bugs that cause the kernel to loop in kernel 1230 mode with interrupts disabled for more than 10 seconds (configurable 1231 using the watchdog_thresh sysctl). 1232 1233 Say N if unsure. 1234 1235config DETECT_HUNG_TASK 1236 bool "Detect Hung Tasks" 1237 depends on DEBUG_KERNEL 1238 default SOFTLOCKUP_DETECTOR 1239 help 1240 Say Y here to enable the kernel to detect "hung tasks", 1241 which are bugs that cause the task to be stuck in 1242 uninterruptible "D" state indefinitely. 1243 1244 When a hung task is detected, the kernel will print the 1245 current stack trace (which you should report), but the 1246 task will stay in uninterruptible state. If lockdep is 1247 enabled then all held locks will also be reported. This 1248 feature has negligible overhead. 1249 1250config DEFAULT_HUNG_TASK_TIMEOUT 1251 int "Default timeout for hung task detection (in seconds)" 1252 depends on DETECT_HUNG_TASK 1253 default 120 1254 help 1255 This option controls the default timeout (in seconds) used 1256 to determine when a task has become non-responsive and should 1257 be considered hung. 1258 1259 It can be adjusted at runtime via the kernel.hung_task_timeout_secs 1260 sysctl or by writing a value to 1261 /proc/sys/kernel/hung_task_timeout_secs. 1262 1263 A timeout of 0 disables the check. The default is two minutes. 1264 Keeping the default should be fine in most cases. 1265 1266config BOOTPARAM_HUNG_TASK_PANIC 1267 bool "Panic (Reboot) On Hung Tasks" 1268 depends on DETECT_HUNG_TASK 1269 help 1270 Say Y here to enable the kernel to panic on "hung tasks", 1271 which are bugs that cause the kernel to leave a task stuck 1272 in uninterruptible "D" state. 1273 1274 The panic can be used in combination with panic_timeout, 1275 to cause the system to reboot automatically after a 1276 hung task has been detected. This feature is useful for 1277 high-availability systems that have uptime guarantees and 1278 where a hung tasks must be resolved ASAP. 1279 1280 Say N if unsure. 1281 1282config DETECT_HUNG_TASK_BLOCKER 1283 bool "Dump Hung Tasks Blocker" 1284 depends on DETECT_HUNG_TASK 1285 depends on !PREEMPT_RT 1286 default y 1287 help 1288 Say Y here to show the blocker task's stacktrace who acquires 1289 the mutex lock which "hung tasks" are waiting. 1290 This will add overhead a bit but shows suspicious tasks and 1291 call trace if it comes from waiting a mutex. 1292 1293config WQ_WATCHDOG 1294 bool "Detect Workqueue Stalls" 1295 depends on DEBUG_KERNEL 1296 help 1297 Say Y here to enable stall detection on workqueues. If a 1298 worker pool doesn't make forward progress on a pending work 1299 item for over a given amount of time, 30s by default, a 1300 warning message is printed along with dump of workqueue 1301 state. This can be configured through kernel parameter 1302 "workqueue.watchdog_thresh" and its sysfs counterpart. 1303 1304config WQ_CPU_INTENSIVE_REPORT 1305 bool "Report per-cpu work items which hog CPU for too long" 1306 depends on DEBUG_KERNEL 1307 help 1308 Say Y here to enable reporting of concurrency-managed per-cpu work 1309 items that hog CPUs for longer than 1310 workqueue.cpu_intensive_thresh_us. Workqueue automatically 1311 detects and excludes them from concurrency management to prevent 1312 them from stalling other per-cpu work items. Occassional 1313 triggering may not necessarily indicate a problem. Repeated 1314 triggering likely indicates that the work item should be switched 1315 to use an unbound workqueue. 1316 1317config TEST_LOCKUP 1318 tristate "Test module to generate lockups" 1319 depends on m 1320 help 1321 This builds the "test_lockup" module that helps to make sure 1322 that watchdogs and lockup detectors are working properly. 1323 1324 Depending on module parameters it could emulate soft or hard 1325 lockup, "hung task", or locking arbitrary lock for a long time. 1326 Also it could generate series of lockups with cooling-down periods. 1327 1328 If unsure, say N. 1329 1330endmenu # "Debug lockups and hangs" 1331 1332menu "Scheduler Debugging" 1333 1334config SCHED_INFO 1335 bool 1336 default n 1337 1338config SCHEDSTATS 1339 bool "Collect scheduler statistics" 1340 depends on PROC_FS 1341 select SCHED_INFO 1342 help 1343 If you say Y here, additional code will be inserted into the 1344 scheduler and related routines to collect statistics about 1345 scheduler behavior and provide them in /proc/schedstat. These 1346 stats may be useful for both tuning and debugging the scheduler 1347 If you aren't debugging the scheduler or trying to tune a specific 1348 application, you can say N to avoid the very slight overhead 1349 this adds. 1350 1351endmenu 1352 1353config DEBUG_PREEMPT 1354 bool "Debug preemptible kernel" 1355 depends on DEBUG_KERNEL && PREEMPTION && TRACE_IRQFLAGS_SUPPORT 1356 help 1357 If you say Y here then the kernel will use a debug variant of the 1358 commonly used smp_processor_id() function and will print warnings 1359 if kernel code uses it in a preemption-unsafe way. Also, the kernel 1360 will detect preemption count underflows. 1361 1362 This option has potential to introduce high runtime overhead, 1363 depending on workload as it triggers debugging routines for each 1364 this_cpu operation. It should only be used for debugging purposes. 1365 1366menu "Lock Debugging (spinlocks, mutexes, etc...)" 1367 1368config LOCK_DEBUGGING_SUPPORT 1369 bool 1370 depends on TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT 1371 default y 1372 1373config PROVE_LOCKING 1374 bool "Lock debugging: prove locking correctness" 1375 depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT 1376 select LOCKDEP 1377 select DEBUG_SPINLOCK 1378 select DEBUG_MUTEXES if !PREEMPT_RT 1379 select DEBUG_RT_MUTEXES if RT_MUTEXES 1380 select DEBUG_RWSEMS if !PREEMPT_RT 1381 select DEBUG_WW_MUTEX_SLOWPATH 1382 select DEBUG_LOCK_ALLOC 1383 select PREEMPT_COUNT if !ARCH_NO_PREEMPT 1384 select TRACE_IRQFLAGS 1385 default n 1386 help 1387 This feature enables the kernel to prove that all locking 1388 that occurs in the kernel runtime is mathematically 1389 correct: that under no circumstance could an arbitrary (and 1390 not yet triggered) combination of observed locking 1391 sequences (on an arbitrary number of CPUs, running an 1392 arbitrary number of tasks and interrupt contexts) cause a 1393 deadlock. 1394 1395 In short, this feature enables the kernel to report locking 1396 related deadlocks before they actually occur. 1397 1398 The proof does not depend on how hard and complex a 1399 deadlock scenario would be to trigger: how many 1400 participant CPUs, tasks and irq-contexts would be needed 1401 for it to trigger. The proof also does not depend on 1402 timing: if a race and a resulting deadlock is possible 1403 theoretically (no matter how unlikely the race scenario 1404 is), it will be proven so and will immediately be 1405 reported by the kernel (once the event is observed that 1406 makes the deadlock theoretically possible). 1407 1408 If a deadlock is impossible (i.e. the locking rules, as 1409 observed by the kernel, are mathematically correct), the 1410 kernel reports nothing. 1411 1412 NOTE: this feature can also be enabled for rwlocks, mutexes 1413 and rwsems - in which case all dependencies between these 1414 different locking variants are observed and mapped too, and 1415 the proof of observed correctness is also maintained for an 1416 arbitrary combination of these separate locking variants. 1417 1418 For more details, see Documentation/locking/lockdep-design.rst. 1419 1420config PROVE_RAW_LOCK_NESTING 1421 bool "Enable raw_spinlock - spinlock nesting checks" if !ARCH_SUPPORTS_RT 1422 depends on PROVE_LOCKING 1423 default y if ARCH_SUPPORTS_RT 1424 help 1425 Enable the raw_spinlock vs. spinlock nesting checks which ensure 1426 that the lock nesting rules for PREEMPT_RT enabled kernels are 1427 not violated. 1428 1429config LOCK_STAT 1430 bool "Lock usage statistics" 1431 depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT 1432 select LOCKDEP 1433 select DEBUG_SPINLOCK 1434 select DEBUG_MUTEXES if !PREEMPT_RT 1435 select DEBUG_RT_MUTEXES if RT_MUTEXES 1436 select DEBUG_LOCK_ALLOC 1437 default n 1438 help 1439 This feature enables tracking lock contention points 1440 1441 For more details, see Documentation/locking/lockstat.rst 1442 1443 This also enables lock events required by "perf lock", 1444 subcommand of perf. 1445 If you want to use "perf lock", you also need to turn on 1446 CONFIG_EVENT_TRACING. 1447 1448 CONFIG_LOCK_STAT defines "contended" and "acquired" lock events. 1449 (CONFIG_LOCKDEP defines "acquire" and "release" events.) 1450 1451config DEBUG_RT_MUTEXES 1452 bool "RT Mutex debugging, deadlock detection" 1453 depends on DEBUG_KERNEL && RT_MUTEXES 1454 help 1455 This allows rt mutex semantics violations and rt mutex related 1456 deadlocks (lockups) to be detected and reported automatically. 1457 1458config DEBUG_SPINLOCK 1459 bool "Spinlock and rw-lock debugging: basic checks" 1460 depends on DEBUG_KERNEL 1461 select UNINLINE_SPIN_UNLOCK 1462 help 1463 Say Y here and build SMP to catch missing spinlock initialization 1464 and certain other kinds of spinlock errors commonly made. This is 1465 best used in conjunction with the NMI watchdog so that spinlock 1466 deadlocks are also debuggable. 1467 1468config DEBUG_MUTEXES 1469 bool "Mutex debugging: basic checks" 1470 depends on DEBUG_KERNEL && !PREEMPT_RT 1471 help 1472 This feature allows mutex semantics violations to be detected and 1473 reported. 1474 1475config DEBUG_WW_MUTEX_SLOWPATH 1476 bool "Wait/wound mutex debugging: Slowpath testing" 1477 depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT 1478 select DEBUG_LOCK_ALLOC 1479 select DEBUG_SPINLOCK 1480 select DEBUG_MUTEXES if !PREEMPT_RT 1481 select DEBUG_RT_MUTEXES if PREEMPT_RT 1482 help 1483 This feature enables slowpath testing for w/w mutex users by 1484 injecting additional -EDEADLK wound/backoff cases. Together with 1485 the full mutex checks enabled with (CONFIG_PROVE_LOCKING) this 1486 will test all possible w/w mutex interface abuse with the 1487 exception of simply not acquiring all the required locks. 1488 Note that this feature can introduce significant overhead, so 1489 it really should not be enabled in a production or distro kernel, 1490 even a debug kernel. If you are a driver writer, enable it. If 1491 you are a distro, do not. 1492 1493config DEBUG_RWSEMS 1494 bool "RW Semaphore debugging: basic checks" 1495 depends on DEBUG_KERNEL && !PREEMPT_RT 1496 help 1497 This debugging feature allows mismatched rw semaphore locks 1498 and unlocks to be detected and reported. 1499 1500config DEBUG_LOCK_ALLOC 1501 bool "Lock debugging: detect incorrect freeing of live locks" 1502 depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT 1503 select DEBUG_SPINLOCK 1504 select DEBUG_MUTEXES if !PREEMPT_RT 1505 select DEBUG_RT_MUTEXES if RT_MUTEXES 1506 select LOCKDEP 1507 help 1508 This feature will check whether any held lock (spinlock, rwlock, 1509 mutex or rwsem) is incorrectly freed by the kernel, via any of the 1510 memory-freeing routines (kfree(), kmem_cache_free(), free_pages(), 1511 vfree(), etc.), whether a live lock is incorrectly reinitialized via 1512 spin_lock_init()/mutex_init()/etc., or whether there is any lock 1513 held during task exit. 1514 1515config LOCKDEP 1516 bool 1517 depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT 1518 select STACKTRACE 1519 select KALLSYMS 1520 select KALLSYMS_ALL 1521 1522config LOCKDEP_SMALL 1523 bool 1524 1525config LOCKDEP_BITS 1526 int "Size for MAX_LOCKDEP_ENTRIES (as Nth power of 2)" 1527 depends on LOCKDEP && !LOCKDEP_SMALL 1528 range 10 24 1529 default 15 1530 help 1531 Try increasing this value if you hit "BUG: MAX_LOCKDEP_ENTRIES too low!" message. 1532 1533config LOCKDEP_CHAINS_BITS 1534 int "Size for MAX_LOCKDEP_CHAINS (as Nth power of 2)" 1535 depends on LOCKDEP && !LOCKDEP_SMALL 1536 range 10 21 1537 default 16 1538 help 1539 Try increasing this value if you hit "BUG: MAX_LOCKDEP_CHAINS too low!" message. 1540 1541config LOCKDEP_STACK_TRACE_BITS 1542 int "Size for MAX_STACK_TRACE_ENTRIES (as Nth power of 2)" 1543 depends on LOCKDEP && !LOCKDEP_SMALL 1544 range 10 26 1545 default 19 1546 help 1547 Try increasing this value if you hit "BUG: MAX_STACK_TRACE_ENTRIES too low!" message. 1548 1549config LOCKDEP_STACK_TRACE_HASH_BITS 1550 int "Size for STACK_TRACE_HASH_SIZE (as Nth power of 2)" 1551 depends on LOCKDEP && !LOCKDEP_SMALL 1552 range 10 26 1553 default 14 1554 help 1555 Try increasing this value if you need large STACK_TRACE_HASH_SIZE. 1556 1557config LOCKDEP_CIRCULAR_QUEUE_BITS 1558 int "Size for elements in circular_queue struct (as Nth power of 2)" 1559 depends on LOCKDEP 1560 range 10 26 1561 default 12 1562 help 1563 Try increasing this value if you hit "lockdep bfs error:-1" warning due to __cq_enqueue() failure. 1564 1565config DEBUG_LOCKDEP 1566 bool "Lock dependency engine debugging" 1567 depends on DEBUG_KERNEL && LOCKDEP 1568 select DEBUG_IRQFLAGS 1569 help 1570 If you say Y here, the lock dependency engine will do 1571 additional runtime checks to debug itself, at the price 1572 of more runtime overhead. 1573 1574config DEBUG_ATOMIC_SLEEP 1575 bool "Sleep inside atomic section checking" 1576 select PREEMPT_COUNT 1577 depends on DEBUG_KERNEL 1578 depends on !ARCH_NO_PREEMPT 1579 help 1580 If you say Y here, various routines which may sleep will become very 1581 noisy if they are called inside atomic sections: when a spinlock is 1582 held, inside an rcu read side critical section, inside preempt disabled 1583 sections, inside an interrupt, etc... 1584 1585config DEBUG_LOCKING_API_SELFTESTS 1586 bool "Locking API boot-time self-tests" 1587 depends on DEBUG_KERNEL 1588 help 1589 Say Y here if you want the kernel to run a short self-test during 1590 bootup. The self-test checks whether common types of locking bugs 1591 are detected by debugging mechanisms or not. (if you disable 1592 lock debugging then those bugs won't be detected of course.) 1593 The following locking APIs are covered: spinlocks, rwlocks, 1594 mutexes and rwsems. 1595 1596config LOCK_TORTURE_TEST 1597 tristate "torture tests for locking" 1598 depends on DEBUG_KERNEL 1599 select TORTURE_TEST 1600 help 1601 This option provides a kernel module that runs torture tests 1602 on kernel locking primitives. The kernel module may be built 1603 after the fact on the running kernel to be tested, if desired. 1604 1605 Say Y here if you want kernel locking-primitive torture tests 1606 to be built into the kernel. 1607 Say M if you want these torture tests to build as a module. 1608 Say N if you are unsure. 1609 1610config WW_MUTEX_SELFTEST 1611 tristate "Wait/wound mutex selftests" 1612 help 1613 This option provides a kernel module that runs tests on the 1614 on the struct ww_mutex locking API. 1615 1616 It is recommended to enable DEBUG_WW_MUTEX_SLOWPATH in conjunction 1617 with this test harness. 1618 1619 Say M if you want these self tests to build as a module. 1620 Say N if you are unsure. 1621 1622config SCF_TORTURE_TEST 1623 tristate "torture tests for smp_call_function*()" 1624 depends on DEBUG_KERNEL 1625 select TORTURE_TEST 1626 help 1627 This option provides a kernel module that runs torture tests 1628 on the smp_call_function() family of primitives. The kernel 1629 module may be built after the fact on the running kernel to 1630 be tested, if desired. 1631 1632config CSD_LOCK_WAIT_DEBUG 1633 bool "Debugging for csd_lock_wait(), called from smp_call_function*()" 1634 depends on DEBUG_KERNEL 1635 depends on SMP 1636 depends on 64BIT 1637 default n 1638 help 1639 This option enables debug prints when CPUs are slow to respond 1640 to the smp_call_function*() IPI wrappers. These debug prints 1641 include the IPI handler function currently executing (if any) 1642 and relevant stack traces. 1643 1644config CSD_LOCK_WAIT_DEBUG_DEFAULT 1645 bool "Default csd_lock_wait() debugging on at boot time" 1646 depends on CSD_LOCK_WAIT_DEBUG 1647 depends on 64BIT 1648 default n 1649 help 1650 This option causes the csdlock_debug= kernel boot parameter to 1651 default to 1 (basic debugging) instead of 0 (no debugging). 1652 1653endmenu # lock debugging 1654 1655config TRACE_IRQFLAGS 1656 depends on TRACE_IRQFLAGS_SUPPORT 1657 bool 1658 help 1659 Enables hooks to interrupt enabling and disabling for 1660 either tracing or lock debugging. 1661 1662config TRACE_IRQFLAGS_NMI 1663 def_bool y 1664 depends on TRACE_IRQFLAGS 1665 depends on TRACE_IRQFLAGS_NMI_SUPPORT 1666 1667config NMI_CHECK_CPU 1668 bool "Debugging for CPUs failing to respond to backtrace requests" 1669 depends on DEBUG_KERNEL 1670 depends on X86 1671 default n 1672 help 1673 Enables debug prints when a CPU fails to respond to a given 1674 backtrace NMI. These prints provide some reasons why a CPU 1675 might legitimately be failing to respond, for example, if it 1676 is offline of if ignore_nmis is set. 1677 1678config DEBUG_IRQFLAGS 1679 bool "Debug IRQ flag manipulation" 1680 help 1681 Enables checks for potentially unsafe enabling or disabling of 1682 interrupts, such as calling raw_local_irq_restore() when interrupts 1683 are enabled. 1684 1685config STACKTRACE 1686 bool "Stack backtrace support" 1687 depends on STACKTRACE_SUPPORT 1688 help 1689 This option causes the kernel to create a /proc/pid/stack for 1690 every process, showing its current stack trace. 1691 It is also used by various kernel debugging features that require 1692 stack trace generation. 1693 1694config WARN_ALL_UNSEEDED_RANDOM 1695 bool "Warn for all uses of unseeded randomness" 1696 default n 1697 help 1698 Some parts of the kernel contain bugs relating to their use of 1699 cryptographically secure random numbers before it's actually possible 1700 to generate those numbers securely. This setting ensures that these 1701 flaws don't go unnoticed, by enabling a message, should this ever 1702 occur. This will allow people with obscure setups to know when things 1703 are going wrong, so that they might contact developers about fixing 1704 it. 1705 1706 Unfortunately, on some models of some architectures getting 1707 a fully seeded CRNG is extremely difficult, and so this can 1708 result in dmesg getting spammed for a surprisingly long 1709 time. This is really bad from a security perspective, and 1710 so architecture maintainers really need to do what they can 1711 to get the CRNG seeded sooner after the system is booted. 1712 However, since users cannot do anything actionable to 1713 address this, by default this option is disabled. 1714 1715 Say Y here if you want to receive warnings for all uses of 1716 unseeded randomness. This will be of use primarily for 1717 those developers interested in improving the security of 1718 Linux kernels running on their architecture (or 1719 subarchitecture). 1720 1721config DEBUG_KOBJECT 1722 bool "kobject debugging" 1723 depends on DEBUG_KERNEL 1724 help 1725 If you say Y here, some extra kobject debugging messages will be sent 1726 to the syslog. 1727 1728config DEBUG_KOBJECT_RELEASE 1729 bool "kobject release debugging" 1730 depends on DEBUG_OBJECTS_TIMERS 1731 help 1732 kobjects are reference counted objects. This means that their 1733 last reference count put is not predictable, and the kobject can 1734 live on past the point at which a driver decides to drop its 1735 initial reference to the kobject gained on allocation. An 1736 example of this would be a struct device which has just been 1737 unregistered. 1738 1739 However, some buggy drivers assume that after such an operation, 1740 the memory backing the kobject can be immediately freed. This 1741 goes completely against the principles of a refcounted object. 1742 1743 If you say Y here, the kernel will delay the release of kobjects 1744 on the last reference count to improve the visibility of this 1745 kind of kobject release bug. 1746 1747config HAVE_DEBUG_BUGVERBOSE 1748 bool 1749 1750menu "Debug kernel data structures" 1751 1752config DEBUG_LIST 1753 bool "Debug linked list manipulation" 1754 depends on DEBUG_KERNEL 1755 select LIST_HARDENED 1756 help 1757 Enable this to turn on extended checks in the linked-list walking 1758 routines. 1759 1760 This option trades better quality error reports for performance, and 1761 is more suitable for kernel debugging. If you care about performance, 1762 you should only enable CONFIG_LIST_HARDENED instead. 1763 1764 If unsure, say N. 1765 1766config DEBUG_PLIST 1767 bool "Debug priority linked list manipulation" 1768 depends on DEBUG_KERNEL 1769 help 1770 Enable this to turn on extended checks in the priority-ordered 1771 linked-list (plist) walking routines. This checks the entire 1772 list multiple times during each manipulation. 1773 1774 If unsure, say N. 1775 1776config DEBUG_SG 1777 bool "Debug SG table operations" 1778 depends on DEBUG_KERNEL 1779 help 1780 Enable this to turn on checks on scatter-gather tables. This can 1781 help find problems with drivers that do not properly initialize 1782 their sg tables. 1783 1784 If unsure, say N. 1785 1786config DEBUG_NOTIFIERS 1787 bool "Debug notifier call chains" 1788 depends on DEBUG_KERNEL 1789 help 1790 Enable this to turn on sanity checking for notifier call chains. 1791 This is most useful for kernel developers to make sure that 1792 modules properly unregister themselves from notifier chains. 1793 This is a relatively cheap check but if you care about maximum 1794 performance, say N. 1795 1796config DEBUG_CLOSURES 1797 bool "Debug closures (bcache async widgits)" 1798 depends on CLOSURES 1799 select DEBUG_FS 1800 help 1801 Keeps all active closures in a linked list and provides a debugfs 1802 interface to list them, which makes it possible to see asynchronous 1803 operations that get stuck. 1804 1805config DEBUG_MAPLE_TREE 1806 bool "Debug maple trees" 1807 depends on DEBUG_KERNEL 1808 help 1809 Enable maple tree debugging information and extra validations. 1810 1811 If unsure, say N. 1812 1813endmenu 1814 1815source "kernel/rcu/Kconfig.debug" 1816 1817config DEBUG_WQ_FORCE_RR_CPU 1818 bool "Force round-robin CPU selection for unbound work items" 1819 depends on DEBUG_KERNEL 1820 default n 1821 help 1822 Workqueue used to implicitly guarantee that work items queued 1823 without explicit CPU specified are put on the local CPU. This 1824 guarantee is no longer true and while local CPU is still 1825 preferred work items may be put on foreign CPUs. Kernel 1826 parameter "workqueue.debug_force_rr_cpu" is added to force 1827 round-robin CPU selection to flush out usages which depend on the 1828 now broken guarantee. This config option enables the debug 1829 feature by default. When enabled, memory and cache locality will 1830 be impacted. 1831 1832config CPU_HOTPLUG_STATE_CONTROL 1833 bool "Enable CPU hotplug state control" 1834 depends on DEBUG_KERNEL 1835 depends on HOTPLUG_CPU 1836 default n 1837 help 1838 Allows to write steps between "offline" and "online" to the CPUs 1839 sysfs target file so states can be stepped granular. This is a debug 1840 option for now as the hotplug machinery cannot be stopped and 1841 restarted at arbitrary points yet. 1842 1843 Say N if your are unsure. 1844 1845config LATENCYTOP 1846 bool "Latency measuring infrastructure" 1847 depends on DEBUG_KERNEL 1848 depends on STACKTRACE_SUPPORT 1849 depends on PROC_FS 1850 depends on FRAME_POINTER || MIPS || PPC || S390 || MICROBLAZE || ARM || ARC || X86 1851 select KALLSYMS 1852 select KALLSYMS_ALL 1853 select STACKTRACE 1854 select SCHEDSTATS 1855 help 1856 Enable this option if you want to use the LatencyTOP tool 1857 to find out which userspace is blocking on what kernel operations. 1858 1859config DEBUG_CGROUP_REF 1860 bool "Disable inlining of cgroup css reference count functions" 1861 depends on DEBUG_KERNEL 1862 depends on CGROUPS 1863 depends on KPROBES 1864 default n 1865 help 1866 Force cgroup css reference count functions to not be inlined so 1867 that they can be kprobed for debugging. 1868 1869source "kernel/trace/Kconfig" 1870 1871config PROVIDE_OHCI1394_DMA_INIT 1872 bool "Remote debugging over FireWire early on boot" 1873 depends on PCI && X86 1874 help 1875 If you want to debug problems which hang or crash the kernel early 1876 on boot and the crashing machine has a FireWire port, you can use 1877 this feature to remotely access the memory of the crashed machine 1878 over FireWire. This employs remote DMA as part of the OHCI1394 1879 specification which is now the standard for FireWire controllers. 1880 1881 With remote DMA, you can monitor the printk buffer remotely using 1882 firescope and access all memory below 4GB using fireproxy from gdb. 1883 Even controlling a kernel debugger is possible using remote DMA. 1884 1885 Usage: 1886 1887 If ohci1394_dma=early is used as boot parameter, it will initialize 1888 all OHCI1394 controllers which are found in the PCI config space. 1889 1890 As all changes to the FireWire bus such as enabling and disabling 1891 devices cause a bus reset and thereby disable remote DMA for all 1892 devices, be sure to have the cable plugged and FireWire enabled on 1893 the debugging host before booting the debug target for debugging. 1894 1895 This code (~1k) is freed after boot. By then, the firewire stack 1896 in charge of the OHCI-1394 controllers should be used instead. 1897 1898 See Documentation/core-api/debugging-via-ohci1394.rst for more information. 1899 1900source "samples/Kconfig" 1901 1902config ARCH_HAS_DEVMEM_IS_ALLOWED 1903 bool 1904 1905config STRICT_DEVMEM 1906 bool "Filter access to /dev/mem" 1907 depends on MMU && DEVMEM 1908 depends on ARCH_HAS_DEVMEM_IS_ALLOWED || GENERIC_LIB_DEVMEM_IS_ALLOWED 1909 default y if PPC || X86 || ARM64 || S390 1910 help 1911 If this option is disabled, you allow userspace (root) access to all 1912 of memory, including kernel and userspace memory. Accidental 1913 access to this is obviously disastrous, but specific access can 1914 be used by people debugging the kernel. Note that with PAT support 1915 enabled, even in this case there are restrictions on /dev/mem 1916 use due to the cache aliasing requirements. 1917 1918 If this option is switched on, and IO_STRICT_DEVMEM=n, the /dev/mem 1919 file only allows userspace access to PCI space and the BIOS code and 1920 data regions. This is sufficient for dosemu and X and all common 1921 users of /dev/mem. 1922 1923 If in doubt, say Y. 1924 1925config IO_STRICT_DEVMEM 1926 bool "Filter I/O access to /dev/mem" 1927 depends on STRICT_DEVMEM 1928 help 1929 If this option is disabled, you allow userspace (root) access to all 1930 io-memory regardless of whether a driver is actively using that 1931 range. Accidental access to this is obviously disastrous, but 1932 specific access can be used by people debugging kernel drivers. 1933 1934 If this option is switched on, the /dev/mem file only allows 1935 userspace access to *idle* io-memory ranges (see /proc/iomem) This 1936 may break traditional users of /dev/mem (dosemu, legacy X, etc...) 1937 if the driver using a given range cannot be disabled. 1938 1939 If in doubt, say Y. 1940 1941menu "$(SRCARCH) Debugging" 1942 1943source "arch/$(SRCARCH)/Kconfig.debug" 1944 1945endmenu 1946 1947menu "Kernel Testing and Coverage" 1948 1949source "lib/kunit/Kconfig" 1950 1951config NOTIFIER_ERROR_INJECTION 1952 tristate "Notifier error injection" 1953 depends on DEBUG_KERNEL 1954 select DEBUG_FS 1955 help 1956 This option provides the ability to inject artificial errors to 1957 specified notifier chain callbacks. It is useful to test the error 1958 handling of notifier call chain failures. 1959 1960 Say N if unsure. 1961 1962config PM_NOTIFIER_ERROR_INJECT 1963 tristate "PM notifier error injection module" 1964 depends on PM && NOTIFIER_ERROR_INJECTION 1965 default m if PM_DEBUG 1966 help 1967 This option provides the ability to inject artificial errors to 1968 PM notifier chain callbacks. It is controlled through debugfs 1969 interface /sys/kernel/debug/notifier-error-inject/pm 1970 1971 If the notifier call chain should be failed with some events 1972 notified, write the error code to "actions/<notifier event>/error". 1973 1974 Example: Inject PM suspend error (-12 = -ENOMEM) 1975 1976 # cd /sys/kernel/debug/notifier-error-inject/pm/ 1977 # echo -12 > actions/PM_SUSPEND_PREPARE/error 1978 # echo mem > /sys/power/state 1979 bash: echo: write error: Cannot allocate memory 1980 1981 To compile this code as a module, choose M here: the module will 1982 be called pm-notifier-error-inject. 1983 1984 If unsure, say N. 1985 1986config OF_RECONFIG_NOTIFIER_ERROR_INJECT 1987 tristate "OF reconfig notifier error injection module" 1988 depends on OF_DYNAMIC && NOTIFIER_ERROR_INJECTION 1989 help 1990 This option provides the ability to inject artificial errors to 1991 OF reconfig notifier chain callbacks. It is controlled 1992 through debugfs interface under 1993 /sys/kernel/debug/notifier-error-inject/OF-reconfig/ 1994 1995 If the notifier call chain should be failed with some events 1996 notified, write the error code to "actions/<notifier event>/error". 1997 1998 To compile this code as a module, choose M here: the module will 1999 be called of-reconfig-notifier-error-inject. 2000 2001 If unsure, say N. 2002 2003config NETDEV_NOTIFIER_ERROR_INJECT 2004 tristate "Netdev notifier error injection module" 2005 depends on NET && NOTIFIER_ERROR_INJECTION 2006 help 2007 This option provides the ability to inject artificial errors to 2008 netdevice notifier chain callbacks. It is controlled through debugfs 2009 interface /sys/kernel/debug/notifier-error-inject/netdev 2010 2011 If the notifier call chain should be failed with some events 2012 notified, write the error code to "actions/<notifier event>/error". 2013 2014 Example: Inject netdevice mtu change error (-22 = -EINVAL) 2015 2016 # cd /sys/kernel/debug/notifier-error-inject/netdev 2017 # echo -22 > actions/NETDEV_CHANGEMTU/error 2018 # ip link set eth0 mtu 1024 2019 RTNETLINK answers: Invalid argument 2020 2021 To compile this code as a module, choose M here: the module will 2022 be called netdev-notifier-error-inject. 2023 2024 If unsure, say N. 2025 2026config FUNCTION_ERROR_INJECTION 2027 bool "Fault-injections of functions" 2028 depends on HAVE_FUNCTION_ERROR_INJECTION && KPROBES 2029 help 2030 Add fault injections into various functions that are annotated with 2031 ALLOW_ERROR_INJECTION() in the kernel. BPF may also modify the return 2032 value of these functions. This is useful to test error paths of code. 2033 2034 If unsure, say N 2035 2036config FAULT_INJECTION 2037 bool "Fault-injection framework" 2038 depends on DEBUG_KERNEL 2039 help 2040 Provide fault-injection framework. 2041 For more details, see Documentation/fault-injection/. 2042 2043config FAILSLAB 2044 bool "Fault-injection capability for kmalloc" 2045 depends on FAULT_INJECTION 2046 help 2047 Provide fault-injection capability for kmalloc. 2048 2049config FAIL_PAGE_ALLOC 2050 bool "Fault-injection capability for alloc_pages()" 2051 depends on FAULT_INJECTION 2052 help 2053 Provide fault-injection capability for alloc_pages(). 2054 2055config FAULT_INJECTION_USERCOPY 2056 bool "Fault injection capability for usercopy functions" 2057 depends on FAULT_INJECTION 2058 help 2059 Provides fault-injection capability to inject failures 2060 in usercopy functions (copy_from_user(), get_user(), ...). 2061 2062config FAIL_MAKE_REQUEST 2063 bool "Fault-injection capability for disk IO" 2064 depends on FAULT_INJECTION && BLOCK 2065 help 2066 Provide fault-injection capability for disk IO. 2067 2068config FAIL_IO_TIMEOUT 2069 bool "Fault-injection capability for faking disk interrupts" 2070 depends on FAULT_INJECTION && BLOCK 2071 help 2072 Provide fault-injection capability on end IO handling. This 2073 will make the block layer "forget" an interrupt as configured, 2074 thus exercising the error handling. 2075 2076 Only works with drivers that use the generic timeout handling, 2077 for others it won't do anything. 2078 2079config FAIL_FUTEX 2080 bool "Fault-injection capability for futexes" 2081 select DEBUG_FS 2082 depends on FAULT_INJECTION && FUTEX 2083 help 2084 Provide fault-injection capability for futexes. 2085 2086config FAULT_INJECTION_DEBUG_FS 2087 bool "Debugfs entries for fault-injection capabilities" 2088 depends on FAULT_INJECTION && SYSFS && DEBUG_FS 2089 help 2090 Enable configuration of fault-injection capabilities via debugfs. 2091 2092config FAIL_FUNCTION 2093 bool "Fault-injection capability for functions" 2094 depends on FAULT_INJECTION_DEBUG_FS && FUNCTION_ERROR_INJECTION 2095 help 2096 Provide function-based fault-injection capability. 2097 This will allow you to override a specific function with a return 2098 with given return value. As a result, function caller will see 2099 an error value and have to handle it. This is useful to test the 2100 error handling in various subsystems. 2101 2102config FAIL_MMC_REQUEST 2103 bool "Fault-injection capability for MMC IO" 2104 depends on FAULT_INJECTION_DEBUG_FS && MMC 2105 help 2106 Provide fault-injection capability for MMC IO. 2107 This will make the mmc core return data errors. This is 2108 useful to test the error handling in the mmc block device 2109 and to test how the mmc host driver handles retries from 2110 the block device. 2111 2112config FAIL_SUNRPC 2113 bool "Fault-injection capability for SunRPC" 2114 depends on FAULT_INJECTION_DEBUG_FS && SUNRPC_DEBUG 2115 help 2116 Provide fault-injection capability for SunRPC and 2117 its consumers. 2118 2119config FAIL_SKB_REALLOC 2120 bool "Fault-injection capability forcing skb to reallocate" 2121 depends on FAULT_INJECTION_DEBUG_FS 2122 help 2123 Provide fault-injection capability that forces the skb to be 2124 reallocated, catching possible invalid pointers to the skb. 2125 2126 For more information, check 2127 Documentation/fault-injection/fault-injection.rst 2128 2129config FAULT_INJECTION_CONFIGFS 2130 bool "Configfs interface for fault-injection capabilities" 2131 depends on FAULT_INJECTION 2132 select CONFIGFS_FS 2133 help 2134 This option allows configfs-based drivers to dynamically configure 2135 fault-injection via configfs. Each parameter for driver-specific 2136 fault-injection can be made visible as a configfs attribute in a 2137 configfs group. 2138 2139 2140config FAULT_INJECTION_STACKTRACE_FILTER 2141 bool "stacktrace filter for fault-injection capabilities" 2142 depends on FAULT_INJECTION 2143 depends on (FAULT_INJECTION_DEBUG_FS || FAULT_INJECTION_CONFIGFS) && STACKTRACE_SUPPORT 2144 select STACKTRACE 2145 depends on FRAME_POINTER || MIPS || PPC || S390 || MICROBLAZE || ARM || ARC || X86 2146 help 2147 Provide stacktrace filter for fault-injection capabilities 2148 2149config ARCH_HAS_KCOV 2150 bool 2151 help 2152 An architecture should select this when it can successfully 2153 build and run with CONFIG_KCOV. This typically requires 2154 disabling instrumentation for some early boot code. 2155 2156config KCOV 2157 bool "Code coverage for fuzzing" 2158 depends on ARCH_HAS_KCOV 2159 depends on !ARCH_WANTS_NO_INSTR || HAVE_NOINSTR_HACK || \ 2160 GCC_VERSION >= 120000 || CC_IS_CLANG 2161 select DEBUG_FS 2162 select OBJTOOL if HAVE_NOINSTR_HACK 2163 help 2164 KCOV exposes kernel code coverage information in a form suitable 2165 for coverage-guided fuzzing (randomized testing). 2166 2167 For more details, see Documentation/dev-tools/kcov.rst. 2168 2169config KCOV_ENABLE_COMPARISONS 2170 bool "Enable comparison operands collection by KCOV" 2171 depends on KCOV 2172 depends on $(cc-option,-fsanitize-coverage=trace-cmp) 2173 help 2174 KCOV also exposes operands of every comparison in the instrumented 2175 code along with operand sizes and PCs of the comparison instructions. 2176 These operands can be used by fuzzing engines to improve the quality 2177 of fuzzing coverage. 2178 2179config KCOV_INSTRUMENT_ALL 2180 bool "Instrument all code by default" 2181 depends on KCOV 2182 default y 2183 help 2184 If you are doing generic system call fuzzing (like e.g. syzkaller), 2185 then you will want to instrument the whole kernel and you should 2186 say y here. If you are doing more targeted fuzzing (like e.g. 2187 filesystem fuzzing with AFL) then you will want to enable coverage 2188 for more specific subsets of files, and should say n here. 2189 2190config KCOV_IRQ_AREA_SIZE 2191 hex "Size of interrupt coverage collection area in words" 2192 depends on KCOV 2193 default 0x40000 2194 help 2195 KCOV uses preallocated per-cpu areas to collect coverage from 2196 soft interrupts. This specifies the size of those areas in the 2197 number of unsigned long words. 2198 2199config KCOV_SELFTEST 2200 bool "Perform short selftests on boot" 2201 depends on KCOV 2202 help 2203 Run short KCOV coverage collection selftests on boot. 2204 On test failure, causes the kernel to panic. Recommended to be 2205 enabled, ensuring critical functionality works as intended. 2206 2207menuconfig RUNTIME_TESTING_MENU 2208 bool "Runtime Testing" 2209 default y 2210 2211if RUNTIME_TESTING_MENU 2212 2213config TEST_DHRY 2214 tristate "Dhrystone benchmark test" 2215 help 2216 Enable this to include the Dhrystone 2.1 benchmark. This test 2217 calculates the number of Dhrystones per second, and the number of 2218 DMIPS (Dhrystone MIPS) obtained when the Dhrystone score is divided 2219 by 1757 (the number of Dhrystones per second obtained on the VAX 2220 11/780, nominally a 1 MIPS machine). 2221 2222 To run the benchmark, it needs to be enabled explicitly, either from 2223 the kernel command line (when built-in), or from userspace (when 2224 built-in or modular). 2225 2226 Run once during kernel boot: 2227 2228 test_dhry.run 2229 2230 Set number of iterations from kernel command line: 2231 2232 test_dhry.iterations=<n> 2233 2234 Set number of iterations from userspace: 2235 2236 echo <n> > /sys/module/test_dhry/parameters/iterations 2237 2238 Trigger manual run from userspace: 2239 2240 echo y > /sys/module/test_dhry/parameters/run 2241 2242 If the number of iterations is <= 0, the test will devise a suitable 2243 number of iterations (test runs for at least 2s) automatically. 2244 This process takes ca. 4s. 2245 2246 If unsure, say N. 2247 2248config LKDTM 2249 tristate "Linux Kernel Dump Test Tool Module" 2250 depends on DEBUG_FS 2251 help 2252 This module enables testing of the different dumping mechanisms by 2253 inducing system failures at predefined crash points. 2254 If you don't need it: say N 2255 Choose M here to compile this code as a module. The module will be 2256 called lkdtm. 2257 2258 Documentation on how to use the module can be found in 2259 Documentation/fault-injection/provoke-crashes.rst 2260 2261config CPUMASK_KUNIT_TEST 2262 tristate "KUnit test for cpumask" if !KUNIT_ALL_TESTS 2263 depends on KUNIT 2264 default KUNIT_ALL_TESTS 2265 help 2266 Enable to turn on cpumask tests, running at boot or module load time. 2267 2268 For more information on KUnit and unit tests in general, please refer 2269 to the KUnit documentation in Documentation/dev-tools/kunit/. 2270 2271 If unsure, say N. 2272 2273config TEST_LIST_SORT 2274 tristate "Linked list sorting test" if !KUNIT_ALL_TESTS 2275 depends on KUNIT 2276 default KUNIT_ALL_TESTS 2277 help 2278 Enable this to turn on 'list_sort()' function test. This test is 2279 executed only once during system boot (so affects only boot time), 2280 or at module load time. 2281 2282 If unsure, say N. 2283 2284config TEST_MIN_HEAP 2285 tristate "Min heap test" 2286 depends on DEBUG_KERNEL || m 2287 help 2288 Enable this to turn on min heap function tests. This test is 2289 executed only once during system boot (so affects only boot time), 2290 or at module load time. 2291 2292 If unsure, say N. 2293 2294config TEST_SORT 2295 tristate "Array-based sort test" if !KUNIT_ALL_TESTS 2296 depends on KUNIT 2297 default KUNIT_ALL_TESTS 2298 help 2299 This option enables the self-test function of 'sort()' at boot, 2300 or at module load time. 2301 2302 If unsure, say N. 2303 2304config TEST_DIV64 2305 tristate "64bit/32bit division and modulo test" 2306 depends on DEBUG_KERNEL || m 2307 help 2308 Enable this to turn on 'do_div()' function test. This test is 2309 executed only once during system boot (so affects only boot time), 2310 or at module load time. 2311 2312 If unsure, say N. 2313 2314config TEST_MULDIV64 2315 tristate "mul_u64_u64_div_u64() test" 2316 depends on DEBUG_KERNEL || m 2317 help 2318 Enable this to turn on 'mul_u64_u64_div_u64()' function test. 2319 This test is executed only once during system boot (so affects 2320 only boot time), or at module load time. 2321 2322 If unsure, say N. 2323 2324config TEST_IOV_ITER 2325 tristate "Test iov_iter operation" if !KUNIT_ALL_TESTS 2326 depends on KUNIT 2327 depends on MMU 2328 default KUNIT_ALL_TESTS 2329 help 2330 Enable this to turn on testing of the operation of the I/O iterator 2331 (iov_iter). This test is executed only once during system boot (so 2332 affects only boot time), or at module load time. 2333 2334 If unsure, say N. 2335 2336config KPROBES_SANITY_TEST 2337 tristate "Kprobes sanity tests" if !KUNIT_ALL_TESTS 2338 depends on DEBUG_KERNEL 2339 depends on KPROBES 2340 depends on KUNIT 2341 select STACKTRACE if ARCH_CORRECT_STACKTRACE_ON_KRETPROBE 2342 default KUNIT_ALL_TESTS 2343 help 2344 This option provides for testing basic kprobes functionality on 2345 boot. Samples of kprobe and kretprobe are inserted and 2346 verified for functionality. 2347 2348 Say N if you are unsure. 2349 2350config FPROBE_SANITY_TEST 2351 bool "Self test for fprobe" 2352 depends on DEBUG_KERNEL 2353 depends on FPROBE 2354 depends on KUNIT=y 2355 help 2356 This option will enable testing the fprobe when the system boot. 2357 A series of tests are made to verify that the fprobe is functioning 2358 properly. 2359 2360 Say N if you are unsure. 2361 2362config BACKTRACE_SELF_TEST 2363 tristate "Self test for the backtrace code" 2364 depends on DEBUG_KERNEL 2365 help 2366 This option provides a kernel module that can be used to test 2367 the kernel stack backtrace code. This option is not useful 2368 for distributions or general kernels, but only for kernel 2369 developers working on architecture code. 2370 2371 Note that if you want to also test saved backtraces, you will 2372 have to enable STACKTRACE as well. 2373 2374 Say N if you are unsure. 2375 2376config TEST_REF_TRACKER 2377 tristate "Self test for reference tracker" 2378 depends on DEBUG_KERNEL && STACKTRACE_SUPPORT 2379 select REF_TRACKER 2380 help 2381 This option provides a kernel module performing tests 2382 using reference tracker infrastructure. 2383 2384 Say N if you are unsure. 2385 2386config RBTREE_TEST 2387 tristate "Red-Black tree test" 2388 depends on DEBUG_KERNEL 2389 help 2390 A benchmark measuring the performance of the rbtree library. 2391 Also includes rbtree invariant checks. 2392 2393config REED_SOLOMON_TEST 2394 tristate "Reed-Solomon library test" 2395 depends on DEBUG_KERNEL || m 2396 select REED_SOLOMON 2397 select REED_SOLOMON_ENC16 2398 select REED_SOLOMON_DEC16 2399 help 2400 This option enables the self-test function of rslib at boot, 2401 or at module load time. 2402 2403 If unsure, say N. 2404 2405config INTERVAL_TREE_TEST 2406 tristate "Interval tree test" 2407 depends on DEBUG_KERNEL 2408 select INTERVAL_TREE 2409 help 2410 A benchmark measuring the performance of the interval tree library 2411 2412config PERCPU_TEST 2413 tristate "Per cpu operations test" 2414 depends on m && DEBUG_KERNEL 2415 help 2416 Enable this option to build test module which validates per-cpu 2417 operations. 2418 2419 If unsure, say N. 2420 2421config ATOMIC64_SELFTEST 2422 tristate "Perform an atomic64_t self-test" 2423 help 2424 Enable this option to test the atomic64_t functions at boot or 2425 at module load time. 2426 2427 If unsure, say N. 2428 2429config ASYNC_RAID6_TEST 2430 tristate "Self test for hardware accelerated raid6 recovery" 2431 depends on ASYNC_RAID6_RECOV 2432 select ASYNC_MEMCPY 2433 help 2434 This is a one-shot self test that permutes through the 2435 recovery of all the possible two disk failure scenarios for a 2436 N-disk array. Recovery is performed with the asynchronous 2437 raid6 recovery routines, and will optionally use an offload 2438 engine if one is available. 2439 2440 If unsure, say N. 2441 2442config TEST_HEXDUMP 2443 tristate "Test functions located in the hexdump module at runtime" 2444 2445config PRINTF_KUNIT_TEST 2446 tristate "KUnit test printf() family of functions at runtime" if !KUNIT_ALL_TESTS 2447 depends on KUNIT 2448 default KUNIT_ALL_TESTS 2449 help 2450 Enable this option to test the printf functions at runtime. 2451 2452 If unsure, say N. 2453 2454config SCANF_KUNIT_TEST 2455 tristate "KUnit test scanf() family of functions at runtime" if !KUNIT_ALL_TESTS 2456 depends on KUNIT 2457 default KUNIT_ALL_TESTS 2458 help 2459 Enable this option to test the scanf functions at runtime. 2460 2461 If unsure, say N. 2462 2463config STRING_KUNIT_TEST 2464 tristate "KUnit test string functions at runtime" if !KUNIT_ALL_TESTS 2465 depends on KUNIT 2466 default KUNIT_ALL_TESTS 2467 2468config STRING_HELPERS_KUNIT_TEST 2469 tristate "KUnit test string helpers at runtime" if !KUNIT_ALL_TESTS 2470 depends on KUNIT 2471 default KUNIT_ALL_TESTS 2472 2473config TEST_KSTRTOX 2474 tristate "Test kstrto*() family of functions at runtime" 2475 2476config TEST_BITMAP 2477 tristate "Test bitmap_*() family of functions at runtime" 2478 help 2479 Enable this option to test the bitmap functions at boot. 2480 2481 If unsure, say N. 2482 2483config TEST_UUID 2484 tristate "Test functions located in the uuid module at runtime" 2485 2486config TEST_XARRAY 2487 tristate "Test the XArray code at runtime" 2488 2489config TEST_MAPLE_TREE 2490 tristate "Test the Maple Tree code at runtime or module load" 2491 help 2492 Enable this option to test the maple tree code functions at boot, or 2493 when the module is loaded. Enable "Debug Maple Trees" will enable 2494 more verbose output on failures. 2495 2496 If unsure, say N. 2497 2498config TEST_RHASHTABLE 2499 tristate "Perform selftest on resizable hash table" 2500 help 2501 Enable this option to test the rhashtable functions at boot. 2502 2503 If unsure, say N. 2504 2505config TEST_IDA 2506 tristate "Perform selftest on IDA functions" 2507 2508config TEST_MISC_MINOR 2509 tristate "miscdevice KUnit test" if !KUNIT_ALL_TESTS 2510 depends on KUNIT 2511 default KUNIT_ALL_TESTS 2512 help 2513 Kunit test for miscdevice API, specially its behavior in respect to 2514 static and dynamic minor numbers. 2515 2516 KUnit tests run during boot and output the results to the debug log 2517 in TAP format (https://testanything.org/). Only useful for kernel devs 2518 running the KUnit test harness, and not intended for inclusion into a 2519 production build. 2520 2521 For more information on KUnit and unit tests in general please refer 2522 to the KUnit documentation in Documentation/dev-tools/kunit/. 2523 2524 If unsure, say N. 2525 2526config TEST_PARMAN 2527 tristate "Perform selftest on priority array manager" 2528 depends on PARMAN 2529 help 2530 Enable this option to test priority array manager on boot 2531 (or module load). 2532 2533 If unsure, say N. 2534 2535config TEST_IRQ_TIMINGS 2536 bool "IRQ timings selftest" 2537 depends on IRQ_TIMINGS 2538 help 2539 Enable this option to test the irq timings code on boot. 2540 2541 If unsure, say N. 2542 2543config TEST_LKM 2544 tristate "Test module loading with 'hello world' module" 2545 depends on m 2546 help 2547 This builds the "test_module" module that emits "Hello, world" 2548 on printk when loaded. It is designed to be used for basic 2549 evaluation of the module loading subsystem (for example when 2550 validating module verification). It lacks any extra dependencies, 2551 and will not normally be loaded by the system unless explicitly 2552 requested by name. 2553 2554 If unsure, say N. 2555 2556config TEST_BITOPS 2557 tristate "Test module for compilation of bitops operations" 2558 help 2559 This builds the "test_bitops" module that is much like the 2560 TEST_LKM module except that it does a basic exercise of the 2561 set/clear_bit macros and get_count_order/long to make sure there are 2562 no compiler warnings from C=1 sparse checker or -Wextra 2563 compilations. It has no dependencies and doesn't run or load unless 2564 explicitly requested by name. for example: modprobe test_bitops. 2565 2566 If unsure, say N. 2567 2568config TEST_VMALLOC 2569 tristate "Test module for stress/performance analysis of vmalloc allocator" 2570 default n 2571 depends on MMU 2572 help 2573 This builds the "test_vmalloc" module that should be used for 2574 stress and performance analysis. So, any new change for vmalloc 2575 subsystem can be evaluated from performance and stability point 2576 of view. 2577 2578 If unsure, say N. 2579 2580config TEST_BPF 2581 tristate "Test BPF filter functionality" 2582 depends on m && NET 2583 help 2584 This builds the "test_bpf" module that runs various test vectors 2585 against the BPF interpreter or BPF JIT compiler depending on the 2586 current setting. This is in particular useful for BPF JIT compiler 2587 development, but also to run regression tests against changes in 2588 the interpreter code. It also enables test stubs for eBPF maps and 2589 verifier used by user space verifier testsuite. 2590 2591 If unsure, say N. 2592 2593config FIND_BIT_BENCHMARK 2594 tristate "Test find_bit functions" 2595 help 2596 This builds the "test_find_bit" module that measure find_*_bit() 2597 functions performance. 2598 2599 If unsure, say N. 2600 2601config TEST_FIRMWARE 2602 tristate "Test firmware loading via userspace interface" 2603 depends on FW_LOADER 2604 help 2605 This builds the "test_firmware" module that creates a userspace 2606 interface for testing firmware loading. This can be used to 2607 control the triggering of firmware loading without needing an 2608 actual firmware-using device. The contents can be rechecked by 2609 userspace. 2610 2611 If unsure, say N. 2612 2613config TEST_SYSCTL 2614 tristate "sysctl test driver" 2615 depends on PROC_SYSCTL 2616 help 2617 This builds the "test_sysctl" module. This driver enables to test the 2618 proc sysctl interfaces available to drivers safely without affecting 2619 production knobs which might alter system functionality. 2620 2621 If unsure, say N. 2622 2623config BITFIELD_KUNIT 2624 tristate "KUnit test bitfield functions at runtime" if !KUNIT_ALL_TESTS 2625 depends on KUNIT 2626 default KUNIT_ALL_TESTS 2627 help 2628 Enable this option to test the bitfield functions at boot. 2629 2630 KUnit tests run during boot and output the results to the debug log 2631 in TAP format (http://testanything.org/). Only useful for kernel devs 2632 running the KUnit test harness, and not intended for inclusion into a 2633 production build. 2634 2635 For more information on KUnit and unit tests in general please refer 2636 to the KUnit documentation in Documentation/dev-tools/kunit/. 2637 2638 If unsure, say N. 2639 2640config CHECKSUM_KUNIT 2641 tristate "KUnit test checksum functions at runtime" if !KUNIT_ALL_TESTS 2642 depends on KUNIT 2643 default KUNIT_ALL_TESTS 2644 help 2645 Enable this option to test the checksum functions at boot. 2646 2647 KUnit tests run during boot and output the results to the debug log 2648 in TAP format (http://testanything.org/). Only useful for kernel devs 2649 running the KUnit test harness, and not intended for inclusion into a 2650 production build. 2651 2652 For more information on KUnit and unit tests in general please refer 2653 to the KUnit documentation in Documentation/dev-tools/kunit/. 2654 2655 If unsure, say N. 2656 2657config UTIL_MACROS_KUNIT 2658 tristate "KUnit test util_macros.h functions at runtime" if !KUNIT_ALL_TESTS 2659 depends on KUNIT 2660 default KUNIT_ALL_TESTS 2661 help 2662 Enable this option to test the util_macros.h function at boot. 2663 2664 KUnit tests run during boot and output the results to the debug log 2665 in TAP format (http://testanything.org/). Only useful for kernel devs 2666 running the KUnit test harness, and not intended for inclusion into a 2667 production build. 2668 2669 For more information on KUnit and unit tests in general please refer 2670 to the KUnit documentation in Documentation/dev-tools/kunit/. 2671 2672 If unsure, say N. 2673 2674config HASH_KUNIT_TEST 2675 tristate "KUnit Test for integer hash functions" if !KUNIT_ALL_TESTS 2676 depends on KUNIT 2677 default KUNIT_ALL_TESTS 2678 help 2679 Enable this option to test the kernel's string (<linux/stringhash.h>), and 2680 integer (<linux/hash.h>) hash functions on boot. 2681 2682 KUnit tests run during boot and output the results to the debug log 2683 in TAP format (https://testanything.org/). Only useful for kernel devs 2684 running the KUnit test harness, and not intended for inclusion into a 2685 production build. 2686 2687 For more information on KUnit and unit tests in general please refer 2688 to the KUnit documentation in Documentation/dev-tools/kunit/. 2689 2690 This is intended to help people writing architecture-specific 2691 optimized versions. If unsure, say N. 2692 2693config RESOURCE_KUNIT_TEST 2694 tristate "KUnit test for resource API" if !KUNIT_ALL_TESTS 2695 depends on KUNIT 2696 default KUNIT_ALL_TESTS 2697 select GET_FREE_REGION 2698 help 2699 This builds the resource API unit test. 2700 Tests the logic of API provided by resource.c and ioport.h. 2701 For more information on KUnit and unit tests in general please refer 2702 to the KUnit documentation in Documentation/dev-tools/kunit/. 2703 2704 If unsure, say N. 2705 2706config SYSCTL_KUNIT_TEST 2707 tristate "KUnit test for sysctl" if !KUNIT_ALL_TESTS 2708 depends on KUNIT 2709 default KUNIT_ALL_TESTS 2710 help 2711 This builds the proc sysctl unit test, which runs on boot. 2712 Tests the API contract and implementation correctness of sysctl. 2713 For more information on KUnit and unit tests in general please refer 2714 to the KUnit documentation in Documentation/dev-tools/kunit/. 2715 2716 If unsure, say N. 2717 2718config KFIFO_KUNIT_TEST 2719 tristate "KUnit Test for the generic kernel FIFO implementation" if !KUNIT_ALL_TESTS 2720 depends on KUNIT 2721 default KUNIT_ALL_TESTS 2722 help 2723 This builds the generic FIFO implementation KUnit test suite. 2724 It tests that the API and basic functionality of the kfifo type 2725 and associated macros. 2726 2727 For more information on KUnit and unit tests in general please refer 2728 to the KUnit documentation in Documentation/dev-tools/kunit/. 2729 2730 If unsure, say N. 2731 2732config LIST_KUNIT_TEST 2733 tristate "KUnit Test for Kernel Linked-list structures" if !KUNIT_ALL_TESTS 2734 depends on KUNIT 2735 default KUNIT_ALL_TESTS 2736 help 2737 This builds the linked list KUnit test suite. 2738 It tests that the API and basic functionality of the list_head type 2739 and associated macros. 2740 2741 KUnit tests run during boot and output the results to the debug log 2742 in TAP format (https://testanything.org/). Only useful for kernel devs 2743 running the KUnit test harness, and not intended for inclusion into a 2744 production build. 2745 2746 For more information on KUnit and unit tests in general please refer 2747 to the KUnit documentation in Documentation/dev-tools/kunit/. 2748 2749 If unsure, say N. 2750 2751config HASHTABLE_KUNIT_TEST 2752 tristate "KUnit Test for Kernel Hashtable structures" if !KUNIT_ALL_TESTS 2753 depends on KUNIT 2754 default KUNIT_ALL_TESTS 2755 help 2756 This builds the hashtable KUnit test suite. 2757 It tests the basic functionality of the API defined in 2758 include/linux/hashtable.h. For more information on KUnit and 2759 unit tests in general please refer to the KUnit documentation 2760 in Documentation/dev-tools/kunit/. 2761 2762 If unsure, say N. 2763 2764config LINEAR_RANGES_TEST 2765 tristate "KUnit test for linear_ranges" 2766 depends on KUNIT 2767 select LINEAR_RANGES 2768 help 2769 This builds the linear_ranges unit test, which runs on boot. 2770 Tests the linear_ranges logic correctness. 2771 For more information on KUnit and unit tests in general please refer 2772 to the KUnit documentation in Documentation/dev-tools/kunit/. 2773 2774 If unsure, say N. 2775 2776config CMDLINE_KUNIT_TEST 2777 tristate "KUnit test for cmdline API" if !KUNIT_ALL_TESTS 2778 depends on KUNIT 2779 default KUNIT_ALL_TESTS 2780 help 2781 This builds the cmdline API unit test. 2782 Tests the logic of API provided by cmdline.c. 2783 For more information on KUnit and unit tests in general please refer 2784 to the KUnit documentation in Documentation/dev-tools/kunit/. 2785 2786 If unsure, say N. 2787 2788config BITS_TEST 2789 tristate "KUnit test for bits.h" if !KUNIT_ALL_TESTS 2790 depends on KUNIT 2791 default KUNIT_ALL_TESTS 2792 help 2793 This builds the bits unit test. 2794 Tests the logic of macros defined in bits.h. 2795 For more information on KUnit and unit tests in general please refer 2796 to the KUnit documentation in Documentation/dev-tools/kunit/. 2797 2798 If unsure, say N. 2799 2800config SLUB_KUNIT_TEST 2801 tristate "KUnit test for SLUB cache error detection" if !KUNIT_ALL_TESTS 2802 depends on SLUB_DEBUG && KUNIT 2803 default KUNIT_ALL_TESTS 2804 help 2805 This builds SLUB allocator unit test. 2806 Tests SLUB cache debugging functionality. 2807 For more information on KUnit and unit tests in general please refer 2808 to the KUnit documentation in Documentation/dev-tools/kunit/. 2809 2810 If unsure, say N. 2811 2812config RATIONAL_KUNIT_TEST 2813 tristate "KUnit test for rational.c" if !KUNIT_ALL_TESTS 2814 depends on KUNIT && RATIONAL 2815 default KUNIT_ALL_TESTS 2816 help 2817 This builds the rational math unit test. 2818 For more information on KUnit and unit tests in general please refer 2819 to the KUnit documentation in Documentation/dev-tools/kunit/. 2820 2821 If unsure, say N. 2822 2823config MEMCPY_KUNIT_TEST 2824 tristate "Test memcpy(), memmove(), and memset() functions at runtime" if !KUNIT_ALL_TESTS 2825 depends on KUNIT 2826 default KUNIT_ALL_TESTS 2827 help 2828 Builds unit tests for memcpy(), memmove(), and memset() functions. 2829 For more information on KUnit and unit tests in general please refer 2830 to the KUnit documentation in Documentation/dev-tools/kunit/. 2831 2832 If unsure, say N. 2833 2834config IS_SIGNED_TYPE_KUNIT_TEST 2835 tristate "Test is_signed_type() macro" if !KUNIT_ALL_TESTS 2836 depends on KUNIT 2837 default KUNIT_ALL_TESTS 2838 help 2839 Builds unit tests for the is_signed_type() macro. 2840 2841 For more information on KUnit and unit tests in general please refer 2842 to the KUnit documentation in Documentation/dev-tools/kunit/. 2843 2844 If unsure, say N. 2845 2846config OVERFLOW_KUNIT_TEST 2847 tristate "Test check_*_overflow() functions at runtime" if !KUNIT_ALL_TESTS 2848 depends on KUNIT 2849 default KUNIT_ALL_TESTS 2850 help 2851 Builds unit tests for the check_*_overflow(), size_*(), allocation, and 2852 related functions. 2853 2854 For more information on KUnit and unit tests in general please refer 2855 to the KUnit documentation in Documentation/dev-tools/kunit/. 2856 2857 If unsure, say N. 2858 2859config RANDSTRUCT_KUNIT_TEST 2860 tristate "Test randstruct structure layout randomization at runtime" if !KUNIT_ALL_TESTS 2861 depends on KUNIT 2862 default KUNIT_ALL_TESTS 2863 help 2864 Builds unit tests for the checking CONFIG_RANDSTRUCT=y, which 2865 randomizes structure layouts. 2866 2867config STACKINIT_KUNIT_TEST 2868 tristate "Test level of stack variable initialization" if !KUNIT_ALL_TESTS 2869 depends on KUNIT 2870 default KUNIT_ALL_TESTS 2871 help 2872 Test if the kernel is zero-initializing stack variables and 2873 padding. Coverage is controlled by compiler flags, 2874 CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_ALL_ZERO. 2875 2876config FORTIFY_KUNIT_TEST 2877 tristate "Test fortified str*() and mem*() function internals at runtime" if !KUNIT_ALL_TESTS 2878 depends on KUNIT 2879 default KUNIT_ALL_TESTS 2880 help 2881 Builds unit tests for checking internals of FORTIFY_SOURCE as used 2882 by the str*() and mem*() family of functions. For testing runtime 2883 traps of FORTIFY_SOURCE, see LKDTM's "FORTIFY_*" tests. 2884 2885config LONGEST_SYM_KUNIT_TEST 2886 tristate "Test the longest symbol possible" if !KUNIT_ALL_TESTS 2887 depends on KUNIT && KPROBES 2888 default KUNIT_ALL_TESTS 2889 help 2890 Tests the longest symbol possible 2891 2892 If unsure, say N. 2893 2894config HW_BREAKPOINT_KUNIT_TEST 2895 bool "Test hw_breakpoint constraints accounting" if !KUNIT_ALL_TESTS 2896 depends on HAVE_HW_BREAKPOINT 2897 depends on KUNIT=y 2898 default KUNIT_ALL_TESTS 2899 help 2900 Tests for hw_breakpoint constraints accounting. 2901 2902 If unsure, say N. 2903 2904config CRC_KUNIT_TEST 2905 tristate "KUnit tests for CRC functions" if !KUNIT_ALL_TESTS 2906 depends on KUNIT 2907 default KUNIT_ALL_TESTS 2908 select CRC7 2909 select CRC16 2910 select CRC_T10DIF 2911 select CRC32 2912 select CRC64 2913 help 2914 Unit tests for the CRC library functions. 2915 2916 This is intended to help people writing architecture-specific 2917 optimized versions. If unsure, say N. 2918 2919config CRC_BENCHMARK 2920 bool "Benchmark for the CRC functions" 2921 depends on CRC_KUNIT_TEST 2922 help 2923 Include benchmarks in the KUnit test suite for the CRC functions. 2924 2925config SIPHASH_KUNIT_TEST 2926 tristate "Perform selftest on siphash functions" if !KUNIT_ALL_TESTS 2927 depends on KUNIT 2928 default KUNIT_ALL_TESTS 2929 help 2930 Enable this option to test the kernel's siphash (<linux/siphash.h>) hash 2931 functions on boot (or module load). 2932 2933 This is intended to help people writing architecture-specific 2934 optimized versions. If unsure, say N. 2935 2936config USERCOPY_KUNIT_TEST 2937 tristate "KUnit Test for user/kernel boundary protections" 2938 depends on KUNIT 2939 default KUNIT_ALL_TESTS 2940 help 2941 This builds the "usercopy_kunit" module that runs sanity checks 2942 on the copy_to/from_user infrastructure, making sure basic 2943 user/kernel boundary testing is working. 2944 2945config BLACKHOLE_DEV_KUNIT_TEST 2946 tristate "Test blackhole netdev functionality" if !KUNIT_ALL_TESTS 2947 depends on NET 2948 depends on KUNIT 2949 default KUNIT_ALL_TESTS 2950 help 2951 This builds the "blackhole_dev_kunit" module that validates the 2952 data path through this blackhole netdev. 2953 2954 If unsure, say N. 2955 2956config TEST_UDELAY 2957 tristate "udelay test driver" 2958 help 2959 This builds the "udelay_test" module that helps to make sure 2960 that udelay() is working properly. 2961 2962 If unsure, say N. 2963 2964config TEST_STATIC_KEYS 2965 tristate "Test static keys" 2966 depends on m 2967 help 2968 Test the static key interfaces. 2969 2970 If unsure, say N. 2971 2972config TEST_DYNAMIC_DEBUG 2973 tristate "Test DYNAMIC_DEBUG" 2974 depends on DYNAMIC_DEBUG 2975 help 2976 This module registers a tracer callback to count enabled 2977 pr_debugs in a 'do_debugging' function, then alters their 2978 enablements, calls the function, and compares counts. 2979 2980 If unsure, say N. 2981 2982config TEST_KMOD 2983 tristate "kmod stress tester" 2984 depends on m 2985 select TEST_LKM 2986 help 2987 Test the kernel's module loading mechanism: kmod. kmod implements 2988 support to load modules using the Linux kernel's usermode helper. 2989 This test provides a series of tests against kmod. 2990 2991 Although technically you can either build test_kmod as a module or 2992 into the kernel we disallow building it into the kernel since 2993 it stress tests request_module() and this will very likely cause 2994 some issues by taking over precious threads available from other 2995 module load requests, ultimately this could be fatal. 2996 2997 To run tests run: 2998 2999 tools/testing/selftests/kmod/kmod.sh --help 3000 3001 If unsure, say N. 3002 3003config TEST_RUNTIME 3004 bool 3005 3006config TEST_RUNTIME_MODULE 3007 bool 3008 3009config TEST_KALLSYMS 3010 tristate "module kallsyms find_symbol() test" 3011 depends on m 3012 select TEST_RUNTIME 3013 select TEST_RUNTIME_MODULE 3014 select TEST_KALLSYMS_A 3015 select TEST_KALLSYMS_B 3016 select TEST_KALLSYMS_C 3017 select TEST_KALLSYMS_D 3018 help 3019 This allows us to stress test find_symbol() through the kallsyms 3020 used to place symbols on the kernel ELF kallsyms and modules kallsyms 3021 where we place kernel symbols such as exported symbols. 3022 3023 We have four test modules: 3024 3025 A: has KALLSYSMS_NUMSYMS exported symbols 3026 B: uses one of A's symbols 3027 C: adds KALLSYMS_SCALE_FACTOR * KALLSYSMS_NUMSYMS exported 3028 D: adds 2 * the symbols than C 3029 3030 We stress test find_symbol() through two means: 3031 3032 1) Upon load of B it will trigger simplify_symbols() to look for the 3033 one symbol it uses from the module A with tons of symbols. This is an 3034 indirect way for us to have B call resolve_symbol_wait() upon module 3035 load. This will eventually call find_symbol() which will eventually 3036 try to find the symbols used with find_exported_symbol_in_section(). 3037 find_exported_symbol_in_section() uses bsearch() so a binary search 3038 for each symbol. Binary search will at worst be O(log(n)) so the 3039 larger TEST_MODULE_KALLSYSMS the worse the search. 3040 3041 2) The selftests should load C first, before B. Upon B's load towards 3042 the end right before we call module B's init routine we get 3043 complete_formation() called on the module. That will first check 3044 for duplicate symbols with the call to verify_exported_symbols(). 3045 That is when we'll force iteration on module C's insane symbol list. 3046 Since it has 10 * KALLSYMS_NUMSYMS it means we can first test 3047 just loading B without C. The amount of time it takes to load C Vs 3048 B can give us an idea of the impact growth of the symbol space and 3049 give us projection. Module A only uses one symbol from B so to allow 3050 this scaling in module C to be proportional, if it used more symbols 3051 then the first test would be doing more and increasing just the 3052 search space would be slightly different. The last module, module D 3053 will just increase the search space by twice the number of symbols in 3054 C so to allow for full projects. 3055 3056 tools/testing/selftests/module/find_symbol.sh 3057 3058 The current defaults will incur a build delay of about 7 minutes 3059 on an x86_64 with only 8 cores. Enable this only if you want to 3060 stress test find_symbol() with thousands of symbols. At the same 3061 time this is also useful to test building modules with thousands of 3062 symbols, and if BTF is enabled this also stress tests adding BTF 3063 information for each module. Currently enabling many more symbols 3064 will segfault the build system. 3065 3066 If unsure, say N. 3067 3068if TEST_KALLSYMS 3069 3070config TEST_KALLSYMS_A 3071 tristate 3072 depends on m 3073 3074config TEST_KALLSYMS_B 3075 tristate 3076 depends on m 3077 3078config TEST_KALLSYMS_C 3079 tristate 3080 depends on m 3081 3082config TEST_KALLSYMS_D 3083 tristate 3084 depends on m 3085 3086choice 3087 prompt "Kallsym test range" 3088 default TEST_KALLSYMS_LARGE 3089 help 3090 Selecting something other than "Fast" will enable tests which slow 3091 down the build and may crash your build. 3092 3093config TEST_KALLSYMS_FAST 3094 bool "Fast builds" 3095 help 3096 You won't really be testing kallsysms, so this just helps fast builds 3097 when allmodconfig is used.. 3098 3099config TEST_KALLSYMS_LARGE 3100 bool "Enable testing kallsyms with large exports" 3101 help 3102 This will enable larger number of symbols. This will slow down 3103 your build considerably. 3104 3105config TEST_KALLSYMS_MAX 3106 bool "Known kallsysms limits" 3107 help 3108 This will enable exports to the point we know we'll start crashing 3109 builds. 3110 3111endchoice 3112 3113config TEST_KALLSYMS_NUMSYMS 3114 int "test kallsyms number of symbols" 3115 range 2 10000 3116 default 2 if TEST_KALLSYMS_FAST 3117 default 100 if TEST_KALLSYMS_LARGE 3118 default 10000 if TEST_KALLSYMS_MAX 3119 help 3120 The number of symbols to create on TEST_KALLSYMS_A, only one of which 3121 module TEST_KALLSYMS_B will use. This also will be used 3122 for how many symbols TEST_KALLSYMS_C will have, scaled up by 3123 TEST_KALLSYMS_SCALE_FACTOR. Note that setting this to 10,000 will 3124 trigger a segfault today, don't use anything close to it unless 3125 you are aware that this should not be used for automated build tests. 3126 3127config TEST_KALLSYMS_SCALE_FACTOR 3128 int "test kallsyms scale factor" 3129 default 8 3130 help 3131 How many more unusued symbols will TEST_KALLSYSMS_C have than 3132 TEST_KALLSYMS_A. If 8, then module C will have 8 * syms 3133 than module A. Then TEST_KALLSYMS_D will have double the amount 3134 of symbols than C so to allow projections. 3135 3136endif # TEST_KALLSYMS 3137 3138config TEST_DEBUG_VIRTUAL 3139 tristate "Test CONFIG_DEBUG_VIRTUAL feature" 3140 depends on DEBUG_VIRTUAL 3141 help 3142 Test the kernel's ability to detect incorrect calls to 3143 virt_to_phys() done against the non-linear part of the 3144 kernel's virtual address map. 3145 3146 If unsure, say N. 3147 3148config TEST_MEMCAT_P 3149 tristate "Test memcat_p() helper function" 3150 help 3151 Test the memcat_p() helper for correctly merging two 3152 pointer arrays together. 3153 3154 If unsure, say N. 3155 3156config TEST_OBJAGG 3157 tristate "Perform selftest on object aggreration manager" 3158 default n 3159 depends on OBJAGG 3160 help 3161 Enable this option to test object aggregation manager on boot 3162 (or module load). 3163 3164config TEST_MEMINIT 3165 tristate "Test heap/page initialization" 3166 help 3167 Test if the kernel is zero-initializing heap and page allocations. 3168 This can be useful to test init_on_alloc and init_on_free features. 3169 3170 If unsure, say N. 3171 3172config TEST_HMM 3173 tristate "Test HMM (Heterogeneous Memory Management)" 3174 depends on TRANSPARENT_HUGEPAGE 3175 depends on DEVICE_PRIVATE 3176 select HMM_MIRROR 3177 select MMU_NOTIFIER 3178 help 3179 This is a pseudo device driver solely for testing HMM. 3180 Say M here if you want to build the HMM test module. 3181 Doing so will allow you to run tools/testing/selftest/vm/hmm-tests. 3182 3183 If unsure, say N. 3184 3185config TEST_FREE_PAGES 3186 tristate "Test freeing pages" 3187 help 3188 Test that a memory leak does not occur due to a race between 3189 freeing a block of pages and a speculative page reference. 3190 Loading this module is safe if your kernel has the bug fixed. 3191 If the bug is not fixed, it will leak gigabytes of memory and 3192 probably OOM your system. 3193 3194config TEST_FPU 3195 tristate "Test floating point operations in kernel space" 3196 depends on ARCH_HAS_KERNEL_FPU_SUPPORT && !KCOV_INSTRUMENT_ALL 3197 help 3198 Enable this option to add /sys/kernel/debug/selftest_helpers/test_fpu 3199 which will trigger a sequence of floating point operations. This is used 3200 for self-testing floating point control register setting in 3201 kernel_fpu_begin(). 3202 3203 If unsure, say N. 3204 3205config TEST_CLOCKSOURCE_WATCHDOG 3206 tristate "Test clocksource watchdog in kernel space" 3207 depends on CLOCKSOURCE_WATCHDOG 3208 help 3209 Enable this option to create a kernel module that will trigger 3210 a test of the clocksource watchdog. This module may be loaded 3211 via modprobe or insmod in which case it will run upon being 3212 loaded, or it may be built in, in which case it will run 3213 shortly after boot. 3214 3215 If unsure, say N. 3216 3217config TEST_OBJPOOL 3218 tristate "Test module for correctness and stress of objpool" 3219 default n 3220 depends on m && DEBUG_KERNEL 3221 help 3222 This builds the "test_objpool" module that should be used for 3223 correctness verification and concurrent testings of objects 3224 allocation and reclamation. 3225 3226 If unsure, say N. 3227 3228config INT_POW_KUNIT_TEST 3229 tristate "Integer exponentiation (int_pow) test" if !KUNIT_ALL_TESTS 3230 depends on KUNIT 3231 default KUNIT_ALL_TESTS 3232 help 3233 This option enables the KUnit test suite for the int_pow function, 3234 which performs integer exponentiation. The test suite is designed to 3235 verify that the implementation of int_pow correctly computes the power 3236 of a given base raised to a given exponent. 3237 3238 Enabling this option will include tests that check various scenarios 3239 and edge cases to ensure the accuracy and reliability of the exponentiation 3240 function. 3241 3242 If unsure, say N 3243 3244config INT_SQRT_KUNIT_TEST 3245 tristate "Integer square root test" if !KUNIT_ALL_TESTS 3246 depends on KUNIT 3247 default KUNIT_ALL_TESTS 3248 help 3249 This option enables the KUnit test suite for the int_sqrt() function, 3250 which performs square root calculation. The test suite checks 3251 various scenarios, including edge cases, to ensure correctness. 3252 3253 Enabling this option will include tests that check various scenarios 3254 and edge cases to ensure the accuracy and reliability of the square root 3255 function. 3256 3257 If unsure, say N 3258 3259config INT_LOG_KUNIT_TEST 3260 tristate "Integer log (int_log) test" if !KUNIT_ALL_TESTS 3261 depends on KUNIT 3262 default KUNIT_ALL_TESTS 3263 help 3264 This option enables the KUnit test suite for the int_log library, which 3265 provides two functions to compute the integer logarithm in base 2 and 3266 base 10, called respectively as intlog2 and intlog10. 3267 3268 If unsure, say N 3269 3270config GCD_KUNIT_TEST 3271 tristate "Greatest common divisor test" if !KUNIT_ALL_TESTS 3272 depends on KUNIT 3273 default KUNIT_ALL_TESTS 3274 help 3275 This option enables the KUnit test suite for the gcd() function, 3276 which computes the greatest common divisor of two numbers. 3277 3278 This test suite verifies the correctness of gcd() across various 3279 scenarios, including edge cases. 3280 3281 If unsure, say N 3282 3283config PRIME_NUMBERS_KUNIT_TEST 3284 tristate "Prime number generator test" if !KUNIT_ALL_TESTS 3285 depends on KUNIT 3286 depends on PRIME_NUMBERS 3287 default KUNIT_ALL_TESTS 3288 help 3289 This option enables the KUnit test suite for the {is,next}_prime_number 3290 functions. 3291 3292 Enabling this option will include tests that compare the prime number 3293 generator functions against a brute force implementation. 3294 3295 If unsure, say N 3296 3297endif # RUNTIME_TESTING_MENU 3298 3299config ARCH_USE_MEMTEST 3300 bool 3301 help 3302 An architecture should select this when it uses early_memtest() 3303 during boot process. 3304 3305config MEMTEST 3306 bool "Memtest" 3307 depends on ARCH_USE_MEMTEST 3308 help 3309 This option adds a kernel parameter 'memtest', which allows memtest 3310 to be set and executed. 3311 memtest=0, mean disabled; -- default 3312 memtest=1, mean do 1 test pattern; 3313 ... 3314 memtest=17, mean do 17 test patterns. 3315 If you are unsure how to answer this question, answer N. 3316 3317 3318 3319config HYPERV_TESTING 3320 bool "Microsoft Hyper-V driver testing" 3321 default n 3322 depends on HYPERV && DEBUG_FS 3323 help 3324 Select this option to enable Hyper-V vmbus testing. 3325 3326endmenu # "Kernel Testing and Coverage" 3327 3328menu "Rust hacking" 3329 3330config RUST_DEBUG_ASSERTIONS 3331 bool "Debug assertions" 3332 depends on RUST 3333 help 3334 Enables rustc's `-Cdebug-assertions` codegen option. 3335 3336 This flag lets you turn `cfg(debug_assertions)` conditional 3337 compilation on or off. This can be used to enable extra debugging 3338 code in development but not in production. For example, it controls 3339 the behavior of the standard library's `debug_assert!` macro. 3340 3341 Note that this will apply to all Rust code, including `core`. 3342 3343 If unsure, say N. 3344 3345config RUST_OVERFLOW_CHECKS 3346 bool "Overflow checks" 3347 default y 3348 depends on RUST 3349 help 3350 Enables rustc's `-Coverflow-checks` codegen option. 3351 3352 This flag allows you to control the behavior of runtime integer 3353 overflow. When overflow-checks are enabled, a Rust panic will occur 3354 on overflow. 3355 3356 Note that this will apply to all Rust code, including `core`. 3357 3358 If unsure, say Y. 3359 3360config RUST_BUILD_ASSERT_ALLOW 3361 bool "Allow unoptimized build-time assertions" 3362 depends on RUST 3363 help 3364 Controls how `build_error!` and `build_assert!` are handled during the build. 3365 3366 If calls to them exist in the binary, it may indicate a violated invariant 3367 or that the optimizer failed to verify the invariant during compilation. 3368 3369 This should not happen, thus by default the build is aborted. However, 3370 as an escape hatch, you can choose Y here to ignore them during build 3371 and let the check be carried at runtime (with `panic!` being called if 3372 the check fails). 3373 3374 If unsure, say N. 3375 3376config RUST_KERNEL_DOCTESTS 3377 bool "Doctests for the `kernel` crate" if !KUNIT_ALL_TESTS 3378 depends on RUST && KUNIT=y 3379 default KUNIT_ALL_TESTS 3380 help 3381 This builds the documentation tests of the `kernel` crate 3382 as KUnit tests. 3383 3384 For more information on KUnit and unit tests in general, 3385 please refer to the KUnit documentation in Documentation/dev-tools/kunit/. 3386 3387 If unsure, say N. 3388 3389endmenu # "Rust" 3390 3391endmenu # Kernel hacking 3392