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