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