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