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