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