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