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