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 STRING_KUNIT_BENCH 2522 bool "Benchmark string functions at runtime" 2523 depends on STRING_KUNIT_TEST 2524 help 2525 Enable performance measurement for string functions. 2526 2527 This measures the execution efficiency of string functions 2528 during the KUnit test run. 2529 2530 If unsure, say N. 2531 2532config FFS_KUNIT_TEST 2533 tristate "KUnit test ffs-family functions at runtime" if !KUNIT_ALL_TESTS 2534 depends on KUNIT 2535 default KUNIT_ALL_TESTS 2536 help 2537 This builds KUnit tests for ffs-family bit manipulation functions 2538 including ffs(), __ffs(), fls(), __fls(), fls64(), and __ffs64(). 2539 2540 These tests validate mathematical correctness, edge case handling, 2541 and cross-architecture consistency of bit scanning functions. 2542 2543 For more information on KUnit and unit tests in general, 2544 please refer to Documentation/dev-tools/kunit/. 2545 2546config TEST_KSTRTOX 2547 tristate "Test kstrto*() family of functions at runtime" 2548 2549config TEST_BITMAP 2550 tristate "Test bitmap_*() family of functions at runtime" 2551 help 2552 Enable this option to test the bitmap functions at boot. 2553 2554 If unsure, say N. 2555 2556config TEST_XARRAY 2557 tristate "Test the XArray code at runtime" 2558 2559config TEST_MAPLE_TREE 2560 tristate "Test the Maple Tree code at runtime or module load" 2561 help 2562 Enable this option to test the maple tree code functions at boot, or 2563 when the module is loaded. Enable "Debug Maple Trees" will enable 2564 more verbose output on failures. 2565 2566 If unsure, say N. 2567 2568config TEST_RHASHTABLE 2569 tristate "Perform selftest on resizable hash table" 2570 help 2571 Enable this option to test the rhashtable functions at boot. 2572 2573 If unsure, say N. 2574 2575config TEST_IDA 2576 tristate "Perform selftest on IDA functions" 2577 2578config TEST_MISC_MINOR 2579 bool "miscdevice KUnit test" if !KUNIT_ALL_TESTS 2580 depends on KUNIT=y 2581 default KUNIT_ALL_TESTS 2582 help 2583 Kunit test for miscdevice API, specially its behavior in respect to 2584 static and dynamic minor numbers. 2585 2586 KUnit tests run during boot and output the results to the debug log 2587 in TAP format (https://testanything.org/). Only useful for kernel devs 2588 running the KUnit test harness, and not intended for inclusion into a 2589 production build. 2590 2591 For more information on KUnit and unit tests in general please refer 2592 to the KUnit documentation in Documentation/dev-tools/kunit/. 2593 2594 If unsure, say N. 2595 2596config TEST_PARMAN 2597 tristate "Perform selftest on priority array manager" 2598 depends on PARMAN 2599 help 2600 Enable this option to test priority array manager on boot 2601 (or module load). 2602 2603 If unsure, say N. 2604 2605config TEST_LKM 2606 tristate "Test module loading with 'hello world' module" 2607 depends on m 2608 help 2609 This builds the "test_module" module that emits "Hello, world" 2610 on printk when loaded. It is designed to be used for basic 2611 evaluation of the module loading subsystem (for example when 2612 validating module verification). It lacks any extra dependencies, 2613 and will not normally be loaded by the system unless explicitly 2614 requested by name. 2615 2616 If unsure, say N. 2617 2618config TEST_BITOPS 2619 tristate "Test module for compilation of bitops operations" 2620 help 2621 This builds the "test_bitops" module that is much like the 2622 TEST_LKM module except that it does a basic exercise of the 2623 set/clear_bit macros and get_count_order/long to make sure there are 2624 no compiler warnings from C=1 sparse checker or -Wextra 2625 compilations. It has no dependencies and doesn't run or load unless 2626 explicitly requested by name. for example: modprobe test_bitops. 2627 2628 If unsure, say N. 2629 2630config TEST_VMALLOC 2631 tristate "Test module for stress/performance analysis of vmalloc allocator" 2632 default n 2633 depends on MMU 2634 help 2635 This builds the "test_vmalloc" module that should be used for 2636 stress and performance analysis. So, any new change for vmalloc 2637 subsystem can be evaluated from performance and stability point 2638 of view. 2639 2640 If unsure, say N. 2641 2642config TEST_BPF 2643 tristate "Test BPF filter functionality" 2644 depends on m && NET 2645 help 2646 This builds the "test_bpf" module that runs various test vectors 2647 against the BPF interpreter or BPF JIT compiler depending on the 2648 current setting. This is in particular useful for BPF JIT compiler 2649 development, but also to run regression tests against changes in 2650 the interpreter code. It also enables test stubs for eBPF maps and 2651 verifier used by user space verifier testsuite. 2652 2653 If unsure, say N. 2654 2655config FIND_BIT_BENCHMARK 2656 tristate "Test find_bit functions" 2657 help 2658 This builds the "test_find_bit" module that measure find_*_bit() 2659 functions performance. 2660 2661 If unsure, say N. 2662 2663config FIND_BIT_BENCHMARK_RUST 2664 tristate "Test find_bit functions in Rust" 2665 depends on RUST 2666 help 2667 This builds the "find_bit_benchmark_rust" module. It is a micro 2668 benchmark that measures the performance of Rust functions that 2669 correspond to the find_*_bit() operations in C. It follows the 2670 FIND_BIT_BENCHMARK closely but will in general not yield same 2671 numbers due to extra bounds checks and overhead of foreign 2672 function calls. 2673 2674 If unsure, say N. 2675 2676config TEST_FIRMWARE 2677 tristate "Test firmware loading via userspace interface" 2678 depends on FW_LOADER 2679 help 2680 This builds the "test_firmware" module that creates a userspace 2681 interface for testing firmware loading. This can be used to 2682 control the triggering of firmware loading without needing an 2683 actual firmware-using device. The contents can be rechecked by 2684 userspace. 2685 2686 If unsure, say N. 2687 2688config TEST_SYSCTL 2689 tristate "sysctl test driver" 2690 depends on PROC_SYSCTL 2691 help 2692 This builds the "test_sysctl" module. This driver enables to test the 2693 proc sysctl interfaces available to drivers safely without affecting 2694 production knobs which might alter system functionality. 2695 2696 If unsure, say N. 2697 2698config BITOPS_KUNIT 2699 tristate "KUnit test for bitops" if !KUNIT_ALL_TESTS 2700 depends on KUNIT 2701 default KUNIT_ALL_TESTS 2702 help 2703 This option enables the KUnit test for the bitops library 2704 which provides functions for bit operations. 2705 2706 Note that this is derived from the original test_bitops module. 2707 For micro-benchmarks and compiler warning checks, enable TEST_BITOPS. 2708 2709 If unsure, say N. 2710 2711config BITFIELD_KUNIT 2712 tristate "KUnit test bitfield functions at runtime" if !KUNIT_ALL_TESTS 2713 depends on KUNIT 2714 default KUNIT_ALL_TESTS 2715 help 2716 Enable this option to test the bitfield functions at boot. 2717 2718 KUnit tests run during boot and output the results to the debug log 2719 in TAP format (http://testanything.org/). Only useful for kernel devs 2720 running the KUnit test harness, and not intended for inclusion into a 2721 production build. 2722 2723 For more information on KUnit and unit tests in general please refer 2724 to the KUnit documentation in Documentation/dev-tools/kunit/. 2725 2726 If unsure, say N. 2727 2728config CHECKSUM_KUNIT 2729 tristate "KUnit test checksum functions at runtime" if !KUNIT_ALL_TESTS 2730 depends on KUNIT 2731 default KUNIT_ALL_TESTS 2732 help 2733 Enable this option to test the checksum functions at boot. 2734 2735 KUnit tests run during boot and output the results to the debug log 2736 in TAP format (http://testanything.org/). Only useful for kernel devs 2737 running the KUnit test harness, and not intended for inclusion into a 2738 production build. 2739 2740 For more information on KUnit and unit tests in general please refer 2741 to the KUnit documentation in Documentation/dev-tools/kunit/. 2742 2743 If unsure, say N. 2744 2745config UTIL_MACROS_KUNIT 2746 tristate "KUnit test util_macros.h functions at runtime" if !KUNIT_ALL_TESTS 2747 depends on KUNIT 2748 default KUNIT_ALL_TESTS 2749 help 2750 Enable this option to test the util_macros.h function at boot. 2751 2752 KUnit tests run during boot and output the results to the debug log 2753 in TAP format (http://testanything.org/). Only useful for kernel devs 2754 running the KUnit test harness, and not intended for inclusion into a 2755 production build. 2756 2757 For more information on KUnit and unit tests in general please refer 2758 to the KUnit documentation in Documentation/dev-tools/kunit/. 2759 2760 If unsure, say N. 2761 2762config HASH_KUNIT_TEST 2763 tristate "KUnit Test for integer hash functions" if !KUNIT_ALL_TESTS 2764 depends on KUNIT 2765 default KUNIT_ALL_TESTS 2766 help 2767 Enable this option to test the kernel's string (<linux/stringhash.h>), and 2768 integer (<linux/hash.h>) hash functions on boot. 2769 2770 KUnit tests run during boot and output the results to the debug log 2771 in TAP format (https://testanything.org/). Only useful for kernel devs 2772 running the KUnit test harness, and not intended for inclusion into a 2773 production build. 2774 2775 For more information on KUnit and unit tests in general please refer 2776 to the KUnit documentation in Documentation/dev-tools/kunit/. 2777 2778 This is intended to help people writing architecture-specific 2779 optimized versions. If unsure, say N. 2780 2781config RESOURCE_KUNIT_TEST 2782 tristate "KUnit test for resource API" if !KUNIT_ALL_TESTS 2783 depends on KUNIT 2784 default KUNIT_ALL_TESTS 2785 select GET_FREE_REGION 2786 help 2787 This builds the resource API unit test. 2788 Tests the logic of API provided by resource.c and ioport.h. 2789 For more information on KUnit and unit tests in general please refer 2790 to the KUnit documentation in Documentation/dev-tools/kunit/. 2791 2792 If unsure, say N. 2793 2794config SYSCTL_KUNIT_TEST 2795 tristate "KUnit test for sysctl" if !KUNIT_ALL_TESTS 2796 depends on KUNIT 2797 default KUNIT_ALL_TESTS 2798 help 2799 This builds the proc sysctl unit test, which runs on boot. 2800 Tests the API contract and implementation correctness of sysctl. 2801 For more information on KUnit and unit tests in general please refer 2802 to the KUnit documentation in Documentation/dev-tools/kunit/. 2803 2804 If unsure, say N. 2805 2806config KFIFO_KUNIT_TEST 2807 tristate "KUnit Test for the generic kernel FIFO implementation" if !KUNIT_ALL_TESTS 2808 depends on KUNIT 2809 default KUNIT_ALL_TESTS 2810 help 2811 This builds the generic FIFO implementation KUnit test suite. 2812 It tests that the API and basic functionality of the kfifo type 2813 and associated macros. 2814 2815 For more information on KUnit and unit tests in general please refer 2816 to the KUnit documentation in Documentation/dev-tools/kunit/. 2817 2818 If unsure, say N. 2819 2820config LIST_KUNIT_TEST 2821 tristate "KUnit Test for Kernel Linked-list structures" if !KUNIT_ALL_TESTS 2822 depends on KUNIT 2823 default KUNIT_ALL_TESTS 2824 help 2825 This builds the linked list KUnit test suite. 2826 It tests that the API and basic functionality of the list_head type 2827 and associated macros. 2828 2829 KUnit tests run during boot and output the results to the debug log 2830 in TAP format (https://testanything.org/). Only useful for kernel devs 2831 running the KUnit test harness, and not intended for inclusion into a 2832 production build. 2833 2834 For more information on KUnit and unit tests in general please refer 2835 to the KUnit documentation in Documentation/dev-tools/kunit/. 2836 2837 If unsure, say N. 2838 2839config LIST_PRIVATE_KUNIT_TEST 2840 tristate "KUnit Test for Kernel Private Linked-list structures" if !KUNIT_ALL_TESTS 2841 depends on KUNIT 2842 default KUNIT_ALL_TESTS 2843 help 2844 This builds the KUnit test for the private linked-list primitives 2845 defined in include/linux/list_private.h. 2846 2847 These primitives allow manipulation of list_head members that are 2848 marked as private and require special accessors (ACCESS_PRIVATE) 2849 to strip qualifiers or handle encapsulation. 2850 2851 If unsure, say N. 2852 2853config HASHTABLE_KUNIT_TEST 2854 tristate "KUnit Test for Kernel Hashtable structures" if !KUNIT_ALL_TESTS 2855 depends on KUNIT 2856 default KUNIT_ALL_TESTS 2857 help 2858 This builds the hashtable KUnit test suite. 2859 It tests the basic functionality of the API defined in 2860 include/linux/hashtable.h. For more information on KUnit and 2861 unit tests in general please refer to the KUnit documentation 2862 in Documentation/dev-tools/kunit/. 2863 2864 If unsure, say N. 2865 2866config LINEAR_RANGES_TEST 2867 tristate "KUnit test for linear_ranges" 2868 depends on KUNIT 2869 select LINEAR_RANGES 2870 help 2871 This builds the linear_ranges unit test, which runs on boot. 2872 Tests the linear_ranges logic correctness. 2873 For more information on KUnit and unit tests in general please refer 2874 to the KUnit documentation in Documentation/dev-tools/kunit/. 2875 2876 If unsure, say N. 2877 2878config CONTEXT_ANALYSIS_TEST 2879 bool "Compiler context-analysis warnings test" 2880 depends on EXPERT 2881 help 2882 This builds the test for compiler-based context analysis. The test 2883 does not add executable code to the kernel, but is meant to test that 2884 common patterns supported by the analysis do not result in false 2885 positive warnings. 2886 2887 When adding support for new context locks, it is strongly recommended 2888 to add supported patterns to this test. 2889 2890 If unsure, say N. 2891 2892config LIVEUPDATE_TEST 2893 bool "Live Update Kernel Test" 2894 default n 2895 depends on LIVEUPDATE 2896 help 2897 Enable a built-in kernel test module for the Live Update 2898 Orchestrator. 2899 2900 This module validates the File-Lifecycle-Bound subsystem by 2901 registering a set of mock FLB objects with any real file handlers 2902 that support live update (such as the memfd handler). 2903 2904 When live update operations are performed, this test module will 2905 output messages to the kernel log (dmesg), confirming that its 2906 registration and various callback functions (preserve, retrieve, 2907 finish, etc.) are being invoked correctly. 2908 2909 This is a debugging and regression testing tool for developers 2910 working on the Live Update subsystem. It should not be enabled in 2911 production kernels. 2912 2913 If unsure, say N 2914 2915config CMDLINE_KUNIT_TEST 2916 tristate "KUnit test for cmdline API" if !KUNIT_ALL_TESTS 2917 depends on KUNIT 2918 default KUNIT_ALL_TESTS 2919 help 2920 This builds the cmdline API unit test. 2921 Tests the logic of API provided by cmdline.c. 2922 For more information on KUnit and unit tests in general please refer 2923 to the KUnit documentation in Documentation/dev-tools/kunit/. 2924 2925 If unsure, say N. 2926 2927config BASE64_KUNIT 2928 tristate "KUnit test for base64 decoding and encoding" if !KUNIT_ALL_TESTS 2929 depends on KUNIT 2930 default KUNIT_ALL_TESTS 2931 help 2932 This builds the base64 unit tests. 2933 2934 The tests cover the encoding and decoding logic of Base64 functions 2935 in the kernel. 2936 In addition to correctness checks, simple performance benchmarks 2937 for both encoding and decoding are also included. 2938 2939 For more information on KUnit and unit tests in general please refer 2940 to the KUnit documentation in Documentation/dev-tools/kunit/. 2941 2942 If unsure, say N. 2943 2944config BITS_TEST 2945 tristate "KUnit test for bit functions and macros" if !KUNIT_ALL_TESTS 2946 depends on KUNIT 2947 default KUNIT_ALL_TESTS 2948 help 2949 This builds the bits unit test. 2950 Tests the logic of macros defined in bits.h. 2951 For more information on KUnit and unit tests in general please refer 2952 to the KUnit documentation in Documentation/dev-tools/kunit/. 2953 2954 If unsure, say N. 2955 2956config SLUB_KUNIT_TEST 2957 tristate "KUnit test for SLUB cache error detection" if !KUNIT_ALL_TESTS 2958 depends on SLUB_DEBUG && KUNIT 2959 default KUNIT_ALL_TESTS 2960 help 2961 This builds SLUB allocator unit test. 2962 Tests SLUB cache debugging functionality. 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 RATIONAL_KUNIT_TEST 2969 tristate "KUnit test for rational.c" if !KUNIT_ALL_TESTS 2970 depends on KUNIT && RATIONAL 2971 default KUNIT_ALL_TESTS 2972 help 2973 This builds the rational math unit test. 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 MEMCPY_KUNIT_TEST 2980 tristate "Test memcpy(), memmove(), and memset() functions at runtime" if !KUNIT_ALL_TESTS 2981 depends on KUNIT 2982 default KUNIT_ALL_TESTS 2983 help 2984 Builds unit tests for memcpy(), memmove(), and memset() functions. 2985 For more information on KUnit and unit tests in general please refer 2986 to the KUnit documentation in Documentation/dev-tools/kunit/. 2987 2988 If unsure, say N. 2989 2990config MIN_HEAP_KUNIT_TEST 2991 tristate "Min heap test" if !KUNIT_ALL_TESTS 2992 depends on KUNIT 2993 default KUNIT_ALL_TESTS 2994 help 2995 This option enables the KUnit test suite for the min heap library 2996 which provides functions for creating and managing min heaps. 2997 The test suite checks the functionality of the min heap library. 2998 2999 If unsure, say N 3000 3001config IS_SIGNED_TYPE_KUNIT_TEST 3002 tristate "Test is_signed_type() macro" if !KUNIT_ALL_TESTS 3003 depends on KUNIT 3004 default KUNIT_ALL_TESTS 3005 help 3006 Builds unit tests for the is_signed_type() macro. 3007 3008 For more information on KUnit and unit tests in general please refer 3009 to the KUnit documentation in Documentation/dev-tools/kunit/. 3010 3011 If unsure, say N. 3012 3013config OVERFLOW_KUNIT_TEST 3014 tristate "Test check_*_overflow() functions at runtime" if !KUNIT_ALL_TESTS 3015 depends on KUNIT 3016 default KUNIT_ALL_TESTS 3017 help 3018 Builds unit tests for the check_*_overflow(), size_*(), allocation, and 3019 related functions. 3020 3021 For more information on KUnit and unit tests in general please refer 3022 to the KUnit documentation in Documentation/dev-tools/kunit/. 3023 3024 If unsure, say N. 3025 3026config RANDSTRUCT_KUNIT_TEST 3027 tristate "Test randstruct structure layout randomization at runtime" if !KUNIT_ALL_TESTS 3028 depends on KUNIT 3029 default KUNIT_ALL_TESTS 3030 help 3031 Builds unit tests for the checking CONFIG_RANDSTRUCT=y, which 3032 randomizes structure layouts. 3033 3034config STACKINIT_KUNIT_TEST 3035 tristate "Test level of stack variable initialization" if !KUNIT_ALL_TESTS 3036 depends on KUNIT 3037 default KUNIT_ALL_TESTS 3038 help 3039 Test if the kernel is zero-initializing stack variables and 3040 padding. Coverage is controlled by compiler flags, 3041 CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_ALL_ZERO. 3042 3043config FORTIFY_KUNIT_TEST 3044 tristate "Test fortified str*() and mem*() function internals at runtime" if !KUNIT_ALL_TESTS 3045 depends on KUNIT 3046 default KUNIT_ALL_TESTS 3047 help 3048 Builds unit tests for checking internals of FORTIFY_SOURCE as used 3049 by the str*() and mem*() family of functions. For testing runtime 3050 traps of FORTIFY_SOURCE, see LKDTM's "FORTIFY_*" tests. 3051 3052config LONGEST_SYM_KUNIT_TEST 3053 tristate "Test the longest symbol possible" if !KUNIT_ALL_TESTS 3054 depends on KUNIT && KPROBES 3055 depends on !PREFIX_SYMBOLS && !CFI && !GCOV_KERNEL 3056 default KUNIT_ALL_TESTS 3057 help 3058 Tests the longest symbol possible 3059 3060 If unsure, say N. 3061 3062config HW_BREAKPOINT_KUNIT_TEST 3063 bool "Test hw_breakpoint constraints accounting" if !KUNIT_ALL_TESTS 3064 depends on HAVE_HW_BREAKPOINT 3065 depends on KUNIT=y 3066 default KUNIT_ALL_TESTS 3067 help 3068 Tests for hw_breakpoint constraints accounting. 3069 3070 If unsure, say N. 3071 3072config SIPHASH_KUNIT_TEST 3073 tristate "Perform selftest on siphash functions" if !KUNIT_ALL_TESTS 3074 depends on KUNIT 3075 default KUNIT_ALL_TESTS 3076 help 3077 Enable this option to test the kernel's siphash (<linux/siphash.h>) hash 3078 functions on boot (or module load). 3079 3080 This is intended to help people writing architecture-specific 3081 optimized versions. If unsure, say N. 3082 3083config USERCOPY_KUNIT_TEST 3084 tristate "KUnit Test for user/kernel boundary protections" 3085 depends on KUNIT 3086 default KUNIT_ALL_TESTS 3087 help 3088 This builds the "usercopy_kunit" module that runs sanity checks 3089 on the copy_to/from_user infrastructure, making sure basic 3090 user/kernel boundary testing is working. 3091 3092config BLACKHOLE_DEV_KUNIT_TEST 3093 tristate "Test blackhole netdev functionality" if !KUNIT_ALL_TESTS 3094 depends on NET 3095 depends on KUNIT 3096 default KUNIT_ALL_TESTS 3097 help 3098 This builds the "blackhole_dev_kunit" module that validates the 3099 data path through this blackhole netdev. 3100 3101 If unsure, say N. 3102 3103config TEST_UDELAY 3104 tristate "udelay test driver" 3105 help 3106 This builds the "udelay_test" module that helps to make sure 3107 that udelay() is working properly. 3108 3109 If unsure, say N. 3110 3111config TEST_STATIC_KEYS 3112 tristate "Test static keys" 3113 depends on m 3114 help 3115 Test the static key interfaces. 3116 3117 If unsure, say N. 3118 3119config TEST_DYNAMIC_DEBUG 3120 tristate "Test DYNAMIC_DEBUG" 3121 depends on DYNAMIC_DEBUG 3122 help 3123 This module registers a tracer callback to count enabled 3124 pr_debugs in a 'do_debugging' function, then alters their 3125 enablements, calls the function, and compares counts. 3126 3127 If unsure, say N. 3128 3129config TEST_KMOD 3130 tristate "kmod stress tester" 3131 depends on m 3132 select TEST_LKM 3133 help 3134 Test the kernel's module loading mechanism: kmod. kmod implements 3135 support to load modules using the Linux kernel's usermode helper. 3136 This test provides a series of tests against kmod. 3137 3138 Although technically you can either build test_kmod as a module or 3139 into the kernel we disallow building it into the kernel since 3140 it stress tests request_module() and this will very likely cause 3141 some issues by taking over precious threads available from other 3142 module load requests, ultimately this could be fatal. 3143 3144 To run tests run: 3145 3146 tools/testing/selftests/kmod/kmod.sh --help 3147 3148 If unsure, say N. 3149 3150config TEST_RUNTIME 3151 bool 3152 3153config TEST_RUNTIME_MODULE 3154 bool 3155 3156config TEST_KALLSYMS 3157 tristate "module kallsyms find_symbol() test" 3158 depends on m 3159 select TEST_RUNTIME 3160 select TEST_RUNTIME_MODULE 3161 select TEST_KALLSYMS_A 3162 select TEST_KALLSYMS_B 3163 select TEST_KALLSYMS_C 3164 select TEST_KALLSYMS_D 3165 help 3166 This allows us to stress test find_symbol() through the kallsyms 3167 used to place symbols on the kernel ELF kallsyms and modules kallsyms 3168 where we place kernel symbols such as exported symbols. 3169 3170 We have four test modules: 3171 3172 A: has KALLSYSMS_NUMSYMS exported symbols 3173 B: uses one of A's symbols 3174 C: adds KALLSYMS_SCALE_FACTOR * KALLSYSMS_NUMSYMS exported 3175 D: adds 2 * the symbols than C 3176 3177 We stress test find_symbol() through two means: 3178 3179 1) Upon load of B it will trigger simplify_symbols() to look for the 3180 one symbol it uses from the module A with tons of symbols. This is an 3181 indirect way for us to have B call resolve_symbol_wait() upon module 3182 load. This will eventually call find_symbol() which will eventually 3183 try to find the symbols used with find_exported_symbol_in_section(). 3184 find_exported_symbol_in_section() uses bsearch() so a binary search 3185 for each symbol. Binary search will at worst be O(log(n)) so the 3186 larger TEST_MODULE_KALLSYSMS the worse the search. 3187 3188 2) The selftests should load C first, before B. Upon B's load towards 3189 the end right before we call module B's init routine we get 3190 complete_formation() called on the module. That will first check 3191 for duplicate symbols with the call to verify_exported_symbols(). 3192 That is when we'll force iteration on module C's insane symbol list. 3193 Since it has 10 * KALLSYMS_NUMSYMS it means we can first test 3194 just loading B without C. The amount of time it takes to load C Vs 3195 B can give us an idea of the impact growth of the symbol space and 3196 give us projection. Module A only uses one symbol from B so to allow 3197 this scaling in module C to be proportional, if it used more symbols 3198 then the first test would be doing more and increasing just the 3199 search space would be slightly different. The last module, module D 3200 will just increase the search space by twice the number of symbols in 3201 C so to allow for full projects. 3202 3203 tools/testing/selftests/module/find_symbol.sh 3204 3205 The current defaults will incur a build delay of about 7 minutes 3206 on an x86_64 with only 8 cores. Enable this only if you want to 3207 stress test find_symbol() with thousands of symbols. At the same 3208 time this is also useful to test building modules with thousands of 3209 symbols, and if BTF is enabled this also stress tests adding BTF 3210 information for each module. Currently enabling many more symbols 3211 will segfault the build system. 3212 3213 If unsure, say N. 3214 3215if TEST_KALLSYMS 3216 3217config TEST_KALLSYMS_A 3218 tristate 3219 depends on m 3220 3221config TEST_KALLSYMS_B 3222 tristate 3223 depends on m 3224 3225config TEST_KALLSYMS_C 3226 tristate 3227 depends on m 3228 3229config TEST_KALLSYMS_D 3230 tristate 3231 depends on m 3232 3233choice 3234 prompt "Kallsym test range" 3235 default TEST_KALLSYMS_LARGE 3236 help 3237 Selecting something other than "Fast" will enable tests which slow 3238 down the build and may crash your build. 3239 3240config TEST_KALLSYMS_FAST 3241 bool "Fast builds" 3242 help 3243 You won't really be testing kallsysms, so this just helps fast builds 3244 when allmodconfig is used.. 3245 3246config TEST_KALLSYMS_LARGE 3247 bool "Enable testing kallsyms with large exports" 3248 help 3249 This will enable larger number of symbols. This will slow down 3250 your build considerably. 3251 3252config TEST_KALLSYMS_MAX 3253 bool "Known kallsysms limits" 3254 help 3255 This will enable exports to the point we know we'll start crashing 3256 builds. 3257 3258endchoice 3259 3260config TEST_KALLSYMS_NUMSYMS 3261 int "test kallsyms number of symbols" 3262 range 2 10000 3263 default 2 if TEST_KALLSYMS_FAST 3264 default 100 if TEST_KALLSYMS_LARGE 3265 default 10000 if TEST_KALLSYMS_MAX 3266 help 3267 The number of symbols to create on TEST_KALLSYMS_A, only one of which 3268 module TEST_KALLSYMS_B will use. This also will be used 3269 for how many symbols TEST_KALLSYMS_C will have, scaled up by 3270 TEST_KALLSYMS_SCALE_FACTOR. Note that setting this to 10,000 will 3271 trigger a segfault today, don't use anything close to it unless 3272 you are aware that this should not be used for automated build tests. 3273 3274config TEST_KALLSYMS_SCALE_FACTOR 3275 int "test kallsyms scale factor" 3276 default 8 3277 help 3278 How many more unusued symbols will TEST_KALLSYSMS_C have than 3279 TEST_KALLSYMS_A. If 8, then module C will have 8 * syms 3280 than module A. Then TEST_KALLSYMS_D will have double the amount 3281 of symbols than C so to allow projections. 3282 3283endif # TEST_KALLSYMS 3284 3285config TEST_DEBUG_VIRTUAL 3286 tristate "Test CONFIG_DEBUG_VIRTUAL feature" 3287 depends on DEBUG_VIRTUAL 3288 help 3289 Test the kernel's ability to detect incorrect calls to 3290 virt_to_phys() done against the non-linear part of the 3291 kernel's virtual address map. 3292 3293 If unsure, say N. 3294 3295config TEST_MEMCAT_P 3296 tristate "Test memcat_p() helper function" 3297 help 3298 Test the memcat_p() helper for correctly merging two 3299 pointer arrays together. 3300 3301 If unsure, say N. 3302 3303config TEST_OBJAGG 3304 tristate "Perform selftest on object aggreration manager" 3305 default n 3306 depends on OBJAGG 3307 help 3308 Enable this option to test object aggregation manager on boot 3309 (or module load). 3310 3311config TEST_MEMINIT 3312 tristate "Test heap/page initialization" 3313 help 3314 Test if the kernel is zero-initializing heap and page allocations. 3315 This can be useful to test init_on_alloc and init_on_free features. 3316 3317 If unsure, say N. 3318 3319config TEST_HMM 3320 tristate "Test HMM (Heterogeneous Memory Management)" 3321 depends on TRANSPARENT_HUGEPAGE 3322 depends on DEVICE_PRIVATE 3323 select HMM_MIRROR 3324 select MMU_NOTIFIER 3325 help 3326 This is a pseudo device driver solely for testing HMM. 3327 Say M here if you want to build the HMM test module. 3328 Doing so will allow you to run tools/testing/selftest/vm/hmm-tests. 3329 3330 If unsure, say N. 3331 3332config TEST_FREE_PAGES 3333 tristate "Test freeing pages" 3334 help 3335 Test that a memory leak does not occur due to a race between 3336 freeing a block of pages and a speculative page reference. 3337 Loading this module is safe if your kernel has the bug fixed. 3338 If the bug is not fixed, it will leak gigabytes of memory and 3339 probably OOM your system. 3340 3341config TEST_FPU 3342 tristate "Test floating point operations in kernel space" 3343 depends on ARCH_HAS_KERNEL_FPU_SUPPORT && !KCOV_INSTRUMENT_ALL 3344 help 3345 Enable this option to add /sys/kernel/debug/selftest_helpers/test_fpu 3346 which will trigger a sequence of floating point operations. This is used 3347 for self-testing floating point control register setting in 3348 kernel_fpu_begin(). 3349 3350 If unsure, say N. 3351 3352config TEST_CLOCKSOURCE_WATCHDOG 3353 tristate "Test clocksource watchdog in kernel space" 3354 depends on CLOCKSOURCE_WATCHDOG 3355 help 3356 Enable this option to create a kernel module that will trigger 3357 a test of the clocksource watchdog. This module may be loaded 3358 via modprobe or insmod in which case it will run upon being 3359 loaded, or it may be built in, in which case it will run 3360 shortly after boot. 3361 3362 If unsure, say N. 3363 3364config TEST_OBJPOOL 3365 tristate "Test module for correctness and stress of objpool" 3366 default n 3367 depends on m && DEBUG_KERNEL 3368 help 3369 This builds the "test_objpool" module that should be used for 3370 correctness verification and concurrent testings of objects 3371 allocation and reclamation. 3372 3373 If unsure, say N. 3374 3375config TEST_KEXEC_HANDOVER 3376 bool "Test for Kexec HandOver" 3377 default n 3378 depends on KEXEC_HANDOVER 3379 help 3380 This option enables test for Kexec HandOver (KHO). 3381 The test consists of two parts: saving kernel data before kexec and 3382 restoring the data after kexec and verifying that it was properly 3383 handed over. This test module creates and saves data on the boot of 3384 the first kernel and restores and verifies the data on the boot of 3385 kexec'ed kernel. 3386 3387 For detailed documentation about KHO, see Documentation/core-api/kho. 3388 3389 To run the test run: 3390 3391 tools/testing/selftests/kho/vmtest.sh -h 3392 3393 If unsure, say N. 3394 3395config RATELIMIT_KUNIT_TEST 3396 tristate "KUnit Test for correctness and stress of ratelimit" if !KUNIT_ALL_TESTS 3397 depends on KUNIT 3398 default KUNIT_ALL_TESTS 3399 help 3400 This builds the "test_ratelimit" module that should be used 3401 for correctness verification and concurrent testings of rate 3402 limiting. 3403 3404 If unsure, say N. 3405 3406config UUID_KUNIT_TEST 3407 tristate "KUnit test for UUID" 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 uuid library, 3412 which provides functions for generating and parsing UUID and GUID. 3413 The test suite checks parsing of UUID and GUID strings. 3414 3415 If unsure, say N. 3416 3417config INT_POW_KUNIT_TEST 3418 tristate "Integer exponentiation (int_pow) test" if !KUNIT_ALL_TESTS 3419 depends on KUNIT 3420 default KUNIT_ALL_TESTS 3421 help 3422 This option enables the KUnit test suite for the int_pow function, 3423 which performs integer exponentiation. The test suite is designed to 3424 verify that the implementation of int_pow correctly computes the power 3425 of a given base raised to a given exponent. 3426 3427 Enabling this option will include tests that check various scenarios 3428 and edge cases to ensure the accuracy and reliability of the exponentiation 3429 function. 3430 3431 If unsure, say N 3432 3433config INT_SQRT_KUNIT_TEST 3434 tristate "Integer square root test" if !KUNIT_ALL_TESTS 3435 depends on KUNIT 3436 default KUNIT_ALL_TESTS 3437 help 3438 This option enables the KUnit test suite for the int_sqrt() function, 3439 which performs square root calculation. The test suite checks 3440 various scenarios, including edge cases, to ensure correctness. 3441 3442 Enabling this option will include tests that check various scenarios 3443 and edge cases to ensure the accuracy and reliability of the square root 3444 function. 3445 3446 If unsure, say N 3447 3448config INT_LOG_KUNIT_TEST 3449 tristate "Integer log (int_log) 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 int_log library, which 3454 provides two functions to compute the integer logarithm in base 2 and 3455 base 10, called respectively as intlog2 and intlog10. 3456 3457 If unsure, say N 3458 3459config GCD_KUNIT_TEST 3460 tristate "Greatest common divisor test" if !KUNIT_ALL_TESTS 3461 depends on KUNIT 3462 default KUNIT_ALL_TESTS 3463 help 3464 This option enables the KUnit test suite for the gcd() function, 3465 which computes the greatest common divisor of two numbers. 3466 3467 This test suite verifies the correctness of gcd() across various 3468 scenarios, including edge cases. 3469 3470 If unsure, say N 3471 3472config PRIME_NUMBERS_KUNIT_TEST 3473 tristate "Prime number generator test" if !KUNIT_ALL_TESTS 3474 depends on KUNIT 3475 depends on PRIME_NUMBERS 3476 default KUNIT_ALL_TESTS 3477 help 3478 This option enables the KUnit test suite for the {is,next}_prime_number 3479 functions. 3480 3481 Enabling this option will include tests that compare the prime number 3482 generator functions against a brute force implementation. 3483 3484 If unsure, say N 3485 3486config GLOB_KUNIT_TEST 3487 tristate "Glob matching test" if !KUNIT_ALL_TESTS 3488 depends on GLOB 3489 depends on KUNIT 3490 default KUNIT_ALL_TESTS 3491 help 3492 Enable this option to test the glob functions at runtime. 3493 3494 This test suite verifies the correctness of glob_match() across various 3495 scenarios, including edge cases. 3496 3497 If unsure, say N 3498 3499endif # RUNTIME_TESTING_MENU 3500 3501config ARCH_USE_MEMTEST 3502 bool 3503 help 3504 An architecture should select this when it uses early_memtest() 3505 during boot process. 3506 3507config MEMTEST 3508 bool "Memtest" 3509 depends on ARCH_USE_MEMTEST 3510 help 3511 This option adds a kernel parameter 'memtest', which allows memtest 3512 to be set and executed. 3513 memtest=0, mean disabled; -- default 3514 memtest=1, mean do 1 test pattern; 3515 ... 3516 memtest=17, mean do 17 test patterns. 3517 If you are unsure how to answer this question, answer N. 3518 3519 3520 3521config HYPERV_TESTING 3522 bool "Microsoft Hyper-V driver testing" 3523 default n 3524 depends on HYPERV && DEBUG_FS 3525 help 3526 Select this option to enable Hyper-V vmbus testing. 3527 3528endmenu # "Kernel Testing and Coverage" 3529 3530menu "Rust hacking" 3531 3532config RUST_DEBUG_ASSERTIONS 3533 bool "Debug assertions" 3534 depends on RUST 3535 help 3536 Enables rustc's `-Cdebug-assertions` codegen option. 3537 3538 This flag lets you turn `cfg(debug_assertions)` conditional 3539 compilation on or off. This can be used to enable extra debugging 3540 code in development but not in production. For example, it controls 3541 the behavior of the standard library's `debug_assert!` macro. 3542 3543 Note that this will apply to all Rust code, including `core`. 3544 3545 If unsure, say N. 3546 3547config RUST_OVERFLOW_CHECKS 3548 bool "Overflow checks" 3549 default y 3550 depends on RUST 3551 help 3552 Enables rustc's `-Coverflow-checks` codegen option. 3553 3554 This flag allows you to control the behavior of runtime integer 3555 overflow. When overflow-checks are enabled, a Rust panic will occur 3556 on overflow. 3557 3558 Note that this will apply to all Rust code, including `core`. 3559 3560 If unsure, say Y. 3561 3562config RUST_BUILD_ASSERT_ALLOW 3563 bool "Allow unoptimized build-time assertions" 3564 depends on RUST 3565 help 3566 Controls how `build_error!` and `build_assert!` are handled during the build. 3567 3568 If calls to them exist in the binary, it may indicate a violated invariant 3569 or that the optimizer failed to verify the invariant during compilation. 3570 3571 This should not happen, thus by default the build is aborted. However, 3572 as an escape hatch, you can choose Y here to ignore them during build 3573 and let the check be carried at runtime (with `panic!` being called if 3574 the check fails). 3575 3576 If unsure, say N. 3577 3578config RUST_KERNEL_DOCTESTS 3579 bool "Doctests for the `kernel` crate" if !KUNIT_ALL_TESTS 3580 depends on RUST && KUNIT=y 3581 default KUNIT_ALL_TESTS 3582 help 3583 This builds the documentation tests of the `kernel` crate 3584 as KUnit tests. 3585 3586 For more information on KUnit and unit tests in general, 3587 please refer to the KUnit documentation in Documentation/dev-tools/kunit/. 3588 3589 If unsure, say N. 3590 3591endmenu # "Rust" 3592 3593endmenu # Kernel hacking 3594