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