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