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 21 if KASAN 1622 default 19 1623 help 1624 Try increasing this value if you hit "BUG: MAX_STACK_TRACE_ENTRIES too low!" message. 1625 1626 KASAN significantly increases stack trace consumption because its 1627 slab tracking interacts with lockdep's dependency validation under 1628 PREEMPT_FULL, creating a feedback loop. The higher default when 1629 KASAN is enabled costs ~12MB extra, which is negligible compared to 1630 KASAN's own shadow memory overhead. 1631 1632config LOCKDEP_STACK_TRACE_HASH_BITS 1633 int "Size for STACK_TRACE_HASH_SIZE (as Nth power of 2)" 1634 depends on LOCKDEP && !LOCKDEP_SMALL 1635 range 10 26 1636 default 16 if KASAN 1637 default 14 1638 help 1639 Try increasing this value if you need large STACK_TRACE_HASH_SIZE. 1640 1641config LOCKDEP_CIRCULAR_QUEUE_BITS 1642 int "Size for elements in circular_queue struct (as Nth power of 2)" 1643 depends on LOCKDEP 1644 range 10 26 1645 default 12 1646 help 1647 Try increasing this value if you hit "lockdep bfs error:-1" warning due to __cq_enqueue() failure. 1648 1649config DEBUG_LOCKDEP 1650 bool "Lock dependency engine debugging" 1651 depends on DEBUG_KERNEL && LOCKDEP 1652 select DEBUG_IRQFLAGS 1653 help 1654 If you say Y here, the lock dependency engine will do 1655 additional runtime checks to debug itself, at the price 1656 of more runtime overhead. 1657 1658config DEBUG_ATOMIC_SLEEP 1659 bool "Sleep inside atomic section checking" 1660 select PREEMPT_COUNT 1661 depends on DEBUG_KERNEL 1662 depends on !ARCH_NO_PREEMPT 1663 help 1664 If you say Y here, various routines which may sleep will become very 1665 noisy if they are called inside atomic sections: when a spinlock is 1666 held, inside an rcu read side critical section, inside preempt disabled 1667 sections, inside an interrupt, etc... 1668 1669config DEBUG_LOCKING_API_SELFTESTS 1670 bool "Locking API boot-time self-tests" 1671 depends on DEBUG_KERNEL 1672 help 1673 Say Y here if you want the kernel to run a short self-test during 1674 bootup. The self-test checks whether common types of locking bugs 1675 are detected by debugging mechanisms or not. (if you disable 1676 lock debugging then those bugs won't be detected of course.) 1677 The following locking APIs are covered: spinlocks, rwlocks, 1678 mutexes and rwsems. 1679 1680config LOCK_TORTURE_TEST 1681 tristate "torture tests for locking" 1682 depends on DEBUG_KERNEL 1683 select TORTURE_TEST 1684 help 1685 This option provides a kernel module that runs torture tests 1686 on kernel locking primitives. The kernel module may be built 1687 after the fact on the running kernel to be tested, if desired. 1688 1689 Say Y here if you want kernel locking-primitive torture tests 1690 to be built into the kernel. 1691 Say M if you want these torture tests to build as a module. 1692 Say N if you are unsure. 1693 1694config WW_MUTEX_SELFTEST 1695 tristate "Wait/wound mutex selftests" 1696 help 1697 This option provides a kernel module that runs tests on the 1698 on the struct ww_mutex locking API. 1699 1700 It is recommended to enable DEBUG_WW_MUTEX_SLOWPATH in conjunction 1701 with this test harness. 1702 1703 Say M if you want these self tests to build as a module. 1704 Say N if you are unsure. 1705 1706config SCF_TORTURE_TEST 1707 tristate "torture tests for smp_call_function*()" 1708 depends on DEBUG_KERNEL 1709 select TORTURE_TEST 1710 help 1711 This option provides a kernel module that runs torture tests 1712 on the smp_call_function() family of primitives. The kernel 1713 module may be built after the fact on the running kernel to 1714 be tested, if desired. 1715 1716config CSD_LOCK_WAIT_DEBUG 1717 bool "Debugging for csd_lock_wait(), called from smp_call_function*()" 1718 depends on DEBUG_KERNEL 1719 depends on SMP 1720 depends on 64BIT 1721 default n 1722 help 1723 This option enables debug prints when CPUs are slow to respond 1724 to the smp_call_function*() IPI wrappers. These debug prints 1725 include the IPI handler function currently executing (if any) 1726 and relevant stack traces. 1727 1728config CSD_LOCK_WAIT_DEBUG_DEFAULT 1729 bool "Default csd_lock_wait() debugging on at boot time" 1730 depends on CSD_LOCK_WAIT_DEBUG 1731 depends on 64BIT 1732 default n 1733 help 1734 This option causes the csdlock_debug= kernel boot parameter to 1735 default to 1 (basic debugging) instead of 0 (no debugging). 1736 1737endmenu # lock debugging 1738 1739config TRACE_IRQFLAGS 1740 depends on TRACE_IRQFLAGS_SUPPORT 1741 bool 1742 help 1743 Enables hooks to interrupt enabling and disabling for 1744 either tracing or lock debugging. 1745 1746config TRACE_IRQFLAGS_NMI 1747 def_bool y 1748 depends on TRACE_IRQFLAGS 1749 depends on TRACE_IRQFLAGS_NMI_SUPPORT 1750 1751config NMI_CHECK_CPU 1752 bool "Debugging for CPUs failing to respond to backtrace requests" 1753 depends on DEBUG_KERNEL 1754 depends on X86 1755 default n 1756 help 1757 Enables debug prints when a CPU fails to respond to a given 1758 backtrace NMI. These prints provide some reasons why a CPU 1759 might legitimately be failing to respond, for example, if it 1760 is offline of if ignore_nmis is set. 1761 1762config DEBUG_IRQFLAGS 1763 bool "Debug IRQ flag manipulation" 1764 help 1765 Enables checks for potentially unsafe enabling or disabling of 1766 interrupts, such as calling raw_local_irq_restore() when interrupts 1767 are enabled. 1768 1769config STACKTRACE 1770 bool "Stack backtrace support" 1771 depends on STACKTRACE_SUPPORT 1772 help 1773 This option causes the kernel to create a /proc/pid/stack for 1774 every process, showing its current stack trace. 1775 It is also used by various kernel debugging features that require 1776 stack trace generation. 1777 1778config DEBUG_KOBJECT 1779 bool "kobject debugging" 1780 depends on DEBUG_KERNEL 1781 help 1782 If you say Y here, some extra kobject debugging messages will be sent 1783 to the syslog. 1784 1785config DEBUG_KOBJECT_RELEASE 1786 bool "kobject release debugging" 1787 depends on DEBUG_OBJECTS_TIMERS 1788 help 1789 kobjects are reference counted objects. This means that their 1790 last reference count put is not predictable, and the kobject can 1791 live on past the point at which a driver decides to drop its 1792 initial reference to the kobject gained on allocation. An 1793 example of this would be a struct device which has just been 1794 unregistered. 1795 1796 However, some buggy drivers assume that after such an operation, 1797 the memory backing the kobject can be immediately freed. This 1798 goes completely against the principles of a refcounted object. 1799 1800 If you say Y here, the kernel will delay the release of kobjects 1801 on the last reference count to improve the visibility of this 1802 kind of kobject release bug. 1803 1804config HAVE_DEBUG_BUGVERBOSE 1805 bool 1806 1807menu "Debug kernel data structures" 1808 1809config DEBUG_LIST 1810 bool "Debug linked list manipulation" 1811 depends on DEBUG_KERNEL 1812 select LIST_HARDENED 1813 help 1814 Enable this to turn on extended checks in the linked-list walking 1815 routines. 1816 1817 This option trades better quality error reports for performance, and 1818 is more suitable for kernel debugging. If you care about performance, 1819 you should only enable CONFIG_LIST_HARDENED instead. 1820 1821 If unsure, say N. 1822 1823config DEBUG_PLIST 1824 bool "Debug priority linked list manipulation" 1825 depends on DEBUG_KERNEL 1826 help 1827 Enable this to turn on extended checks in the priority-ordered 1828 linked-list (plist) walking routines. This checks the entire 1829 list multiple times during each manipulation. 1830 1831 If unsure, say N. 1832 1833config DEBUG_SG 1834 bool "Debug SG table operations" 1835 depends on DEBUG_KERNEL 1836 help 1837 Enable this to turn on checks on scatter-gather tables. This can 1838 help find problems with drivers that do not properly initialize 1839 their sg tables. 1840 1841 If unsure, say N. 1842 1843config DEBUG_NOTIFIERS 1844 bool "Debug notifier call chains" 1845 depends on DEBUG_KERNEL 1846 help 1847 Enable this to turn on sanity checking for notifier call chains. 1848 This is most useful for kernel developers to make sure that 1849 modules properly unregister themselves from notifier chains. 1850 This is a relatively cheap check but if you care about maximum 1851 performance, say N. 1852 1853config DEBUG_CLOSURES 1854 bool "Debug closures (bcache async widgits)" 1855 depends on CLOSURES 1856 select DEBUG_FS 1857 help 1858 Keeps all active closures in a linked list and provides a debugfs 1859 interface to list them, which makes it possible to see asynchronous 1860 operations that get stuck. 1861 1862config DEBUG_MAPLE_TREE 1863 bool "Debug maple trees" 1864 depends on DEBUG_KERNEL 1865 help 1866 Enable maple tree debugging information and extra validations. 1867 1868 If unsure, say N. 1869 1870endmenu 1871 1872source "kernel/rcu/Kconfig.debug" 1873 1874config DEBUG_WQ_FORCE_RR_CPU 1875 bool "Force round-robin CPU selection for unbound work items" 1876 depends on DEBUG_KERNEL 1877 default n 1878 help 1879 Workqueue used to implicitly guarantee that work items queued 1880 without explicit CPU specified are put on the local CPU. This 1881 guarantee is no longer true and while local CPU is still 1882 preferred work items may be put on foreign CPUs. Kernel 1883 parameter "workqueue.debug_force_rr_cpu" is added to force 1884 round-robin CPU selection to flush out usages which depend on the 1885 now broken guarantee. This config option enables the debug 1886 feature by default. When enabled, memory and cache locality will 1887 be impacted. 1888 1889config CPU_HOTPLUG_STATE_CONTROL 1890 bool "Enable CPU hotplug state control" 1891 depends on DEBUG_KERNEL 1892 depends on HOTPLUG_CPU 1893 default n 1894 help 1895 Allows to write steps between "offline" and "online" to the CPUs 1896 sysfs target file so states can be stepped granular. This is a debug 1897 option for now as the hotplug machinery cannot be stopped and 1898 restarted at arbitrary points yet. 1899 1900 Say N if your are unsure. 1901 1902config LATENCYTOP 1903 bool "Latency measuring infrastructure" 1904 depends on DEBUG_KERNEL 1905 depends on STACKTRACE_SUPPORT 1906 depends on PROC_FS 1907 depends on FRAME_POINTER || MIPS || PPC || S390 || MICROBLAZE || ARM || ARC || X86 1908 select KALLSYMS 1909 select KALLSYMS_ALL 1910 select STACKTRACE 1911 select SCHEDSTATS 1912 help 1913 Enable this option if you want to use the LatencyTOP tool 1914 to find out which userspace is blocking on what kernel operations. 1915 1916config DEBUG_CGROUP_REF 1917 bool "Disable inlining of cgroup css reference count functions" 1918 depends on DEBUG_KERNEL 1919 depends on CGROUPS 1920 depends on KPROBES 1921 default n 1922 help 1923 Force cgroup css reference count functions to not be inlined so 1924 that they can be kprobed for debugging. 1925 1926source "kernel/trace/Kconfig" 1927 1928config PROVIDE_OHCI1394_DMA_INIT 1929 bool "Remote debugging over FireWire early on boot" 1930 depends on PCI && X86 1931 help 1932 If you want to debug problems which hang or crash the kernel early 1933 on boot and the crashing machine has a FireWire port, you can use 1934 this feature to remotely access the memory of the crashed machine 1935 over FireWire. This employs remote DMA as part of the OHCI1394 1936 specification which is now the standard for FireWire controllers. 1937 1938 With remote DMA, you can monitor the printk buffer remotely using 1939 firescope and access all memory below 4GB using fireproxy from gdb. 1940 Even controlling a kernel debugger is possible using remote DMA. 1941 1942 Usage: 1943 1944 If ohci1394_dma=early is used as boot parameter, it will initialize 1945 all OHCI1394 controllers which are found in the PCI config space. 1946 1947 As all changes to the FireWire bus such as enabling and disabling 1948 devices cause a bus reset and thereby disable remote DMA for all 1949 devices, be sure to have the cable plugged and FireWire enabled on 1950 the debugging host before booting the debug target for debugging. 1951 1952 This code (~1k) is freed after boot. By then, the firewire stack 1953 in charge of the OHCI-1394 controllers should be used instead. 1954 1955 See Documentation/core-api/debugging-via-ohci1394.rst for more information. 1956 1957source "samples/Kconfig" 1958 1959config ARCH_HAS_DEVMEM_IS_ALLOWED 1960 bool 1961 1962config STRICT_DEVMEM 1963 bool "Filter access to /dev/mem" 1964 depends on MMU && DEVMEM 1965 depends on ARCH_HAS_DEVMEM_IS_ALLOWED || GENERIC_LIB_DEVMEM_IS_ALLOWED 1966 default y if PPC || X86 || ARM64 || S390 1967 help 1968 If this option is disabled, you allow userspace (root) access to all 1969 of memory, including kernel and userspace memory. Accidental 1970 access to this is obviously disastrous, but specific access can 1971 be used by people debugging the kernel. Note that with PAT support 1972 enabled, even in this case there are restrictions on /dev/mem 1973 use due to the cache aliasing requirements. 1974 1975 If this option is switched on, and IO_STRICT_DEVMEM=n, the /dev/mem 1976 file only allows userspace access to PCI space and the BIOS code and 1977 data regions. This is sufficient for dosemu and X and all common 1978 users of /dev/mem. 1979 1980 If in doubt, say Y. 1981 1982config IO_STRICT_DEVMEM 1983 bool "Filter I/O access to /dev/mem" 1984 depends on STRICT_DEVMEM 1985 help 1986 If this option is disabled, you allow userspace (root) access to all 1987 io-memory regardless of whether a driver is actively using that 1988 range. Accidental access to this is obviously disastrous, but 1989 specific access can be used by people debugging kernel drivers. 1990 1991 If this option is switched on, the /dev/mem file only allows 1992 userspace access to *idle* io-memory ranges (see /proc/iomem) This 1993 may break traditional users of /dev/mem (dosemu, legacy X, etc...) 1994 if the driver using a given range cannot be disabled. 1995 1996 If in doubt, say Y. 1997 1998menu "$(SRCARCH) Debugging" 1999 2000source "arch/$(SRCARCH)/Kconfig.debug" 2001 2002endmenu 2003 2004menu "Kernel Testing and Coverage" 2005 2006source "lib/kunit/Kconfig" 2007 2008config NOTIFIER_ERROR_INJECTION 2009 tristate "Notifier error injection" 2010 depends on DEBUG_KERNEL 2011 select DEBUG_FS 2012 help 2013 This option provides the ability to inject artificial errors to 2014 specified notifier chain callbacks. It is useful to test the error 2015 handling of notifier call chain failures. 2016 2017 Say N if unsure. 2018 2019config PM_NOTIFIER_ERROR_INJECT 2020 tristate "PM notifier error injection module" 2021 depends on PM && NOTIFIER_ERROR_INJECTION 2022 default m if PM_DEBUG 2023 help 2024 This option provides the ability to inject artificial errors to 2025 PM notifier chain callbacks. It is controlled through debugfs 2026 interface /sys/kernel/debug/notifier-error-inject/pm 2027 2028 If the notifier call chain should be failed with some events 2029 notified, write the error code to "actions/<notifier event>/error". 2030 2031 Example: Inject PM suspend error (-12 = -ENOMEM) 2032 2033 # cd /sys/kernel/debug/notifier-error-inject/pm/ 2034 # echo -12 > actions/PM_SUSPEND_PREPARE/error 2035 # echo mem > /sys/power/state 2036 bash: echo: write error: Cannot allocate memory 2037 2038 To compile this code as a module, choose M here: the module will 2039 be called pm-notifier-error-inject. 2040 2041 If unsure, say N. 2042 2043config OF_RECONFIG_NOTIFIER_ERROR_INJECT 2044 tristate "OF reconfig notifier error injection module" 2045 depends on OF_DYNAMIC && NOTIFIER_ERROR_INJECTION 2046 help 2047 This option provides the ability to inject artificial errors to 2048 OF reconfig notifier chain callbacks. It is controlled 2049 through debugfs interface under 2050 /sys/kernel/debug/notifier-error-inject/OF-reconfig/ 2051 2052 If the notifier call chain should be failed with some events 2053 notified, write the error code to "actions/<notifier event>/error". 2054 2055 To compile this code as a module, choose M here: the module will 2056 be called of-reconfig-notifier-error-inject. 2057 2058 If unsure, say N. 2059 2060config NETDEV_NOTIFIER_ERROR_INJECT 2061 tristate "Netdev notifier error injection module" 2062 depends on NET && NOTIFIER_ERROR_INJECTION 2063 help 2064 This option provides the ability to inject artificial errors to 2065 netdevice notifier chain callbacks. It is controlled through debugfs 2066 interface /sys/kernel/debug/notifier-error-inject/netdev 2067 2068 If the notifier call chain should be failed with some events 2069 notified, write the error code to "actions/<notifier event>/error". 2070 2071 Example: Inject netdevice mtu change error (-22 = -EINVAL) 2072 2073 # cd /sys/kernel/debug/notifier-error-inject/netdev 2074 # echo -22 > actions/NETDEV_CHANGEMTU/error 2075 # ip link set eth0 mtu 1024 2076 RTNETLINK answers: Invalid argument 2077 2078 To compile this code as a module, choose M here: the module will 2079 be called netdev-notifier-error-inject. 2080 2081 If unsure, say N. 2082 2083config FUNCTION_ERROR_INJECTION 2084 bool "Fault-injections of functions" 2085 depends on HAVE_FUNCTION_ERROR_INJECTION && KPROBES 2086 help 2087 Add fault injections into various functions that are annotated with 2088 ALLOW_ERROR_INJECTION() in the kernel. BPF may also modify the return 2089 value of these functions. This is useful to test error paths of code. 2090 2091 If unsure, say N 2092 2093config FAULT_INJECTION 2094 bool "Fault-injection framework" 2095 depends on DEBUG_KERNEL 2096 help 2097 Provide fault-injection framework. 2098 For more details, see Documentation/fault-injection/. 2099 2100config FAILSLAB 2101 bool "Fault-injection capability for kmalloc" 2102 depends on FAULT_INJECTION 2103 help 2104 Provide fault-injection capability for kmalloc. 2105 2106config FAIL_PAGE_ALLOC 2107 bool "Fault-injection capability for alloc_pages()" 2108 depends on FAULT_INJECTION 2109 help 2110 Provide fault-injection capability for alloc_pages(). 2111 2112config FAULT_INJECTION_USERCOPY 2113 bool "Fault injection capability for usercopy functions" 2114 depends on FAULT_INJECTION 2115 help 2116 Provides fault-injection capability to inject failures 2117 in usercopy functions (copy_from_user(), get_user(), ...). 2118 2119config FAIL_MAKE_REQUEST 2120 bool "Fault-injection capability for disk IO" 2121 depends on FAULT_INJECTION && BLOCK 2122 help 2123 Provide fault-injection capability for disk IO. 2124 2125config FAIL_IO_TIMEOUT 2126 bool "Fault-injection capability for faking disk interrupts" 2127 depends on FAULT_INJECTION && BLOCK 2128 help 2129 Provide fault-injection capability on end IO handling. This 2130 will make the block layer "forget" an interrupt as configured, 2131 thus exercising the error handling. 2132 2133 Only works with drivers that use the generic timeout handling, 2134 for others it won't do anything. 2135 2136config FAIL_FUTEX 2137 bool "Fault-injection capability for futexes" 2138 select DEBUG_FS 2139 depends on FAULT_INJECTION && FUTEX 2140 help 2141 Provide fault-injection capability for futexes. 2142 2143config FAULT_INJECTION_DEBUG_FS 2144 bool "Debugfs entries for fault-injection capabilities" 2145 depends on FAULT_INJECTION && SYSFS && DEBUG_FS 2146 help 2147 Enable configuration of fault-injection capabilities via debugfs. 2148 2149config FAIL_FUNCTION 2150 bool "Fault-injection capability for functions" 2151 depends on FAULT_INJECTION_DEBUG_FS && FUNCTION_ERROR_INJECTION 2152 help 2153 Provide function-based fault-injection capability. 2154 This will allow you to override a specific function with a return 2155 with given return value. As a result, function caller will see 2156 an error value and have to handle it. This is useful to test the 2157 error handling in various subsystems. 2158 2159config FAIL_MMC_REQUEST 2160 bool "Fault-injection capability for MMC IO" 2161 depends on FAULT_INJECTION_DEBUG_FS && MMC 2162 help 2163 Provide fault-injection capability for MMC IO. 2164 This will make the mmc core return data errors. This is 2165 useful to test the error handling in the mmc block device 2166 and to test how the mmc host driver handles retries from 2167 the block device. 2168 2169config FAIL_SUNRPC 2170 bool "Fault-injection capability for SunRPC" 2171 depends on FAULT_INJECTION_DEBUG_FS && SUNRPC_DEBUG 2172 help 2173 Provide fault-injection capability for SunRPC and 2174 its consumers. 2175 2176config FAIL_SKB_REALLOC 2177 bool "Fault-injection capability forcing skb to reallocate" 2178 depends on FAULT_INJECTION_DEBUG_FS 2179 help 2180 Provide fault-injection capability that forces the skb to be 2181 reallocated, catching possible invalid pointers to the skb. 2182 2183 For more information, check 2184 Documentation/fault-injection/fault-injection.rst 2185 2186config FAULT_INJECTION_CONFIGFS 2187 bool "Configfs interface for fault-injection capabilities" 2188 depends on FAULT_INJECTION 2189 select CONFIGFS_FS 2190 help 2191 This option allows configfs-based drivers to dynamically configure 2192 fault-injection via configfs. Each parameter for driver-specific 2193 fault-injection can be made visible as a configfs attribute in a 2194 configfs group. 2195 2196 2197config FAULT_INJECTION_STACKTRACE_FILTER 2198 bool "stacktrace filter for fault-injection capabilities" 2199 depends on FAULT_INJECTION 2200 depends on (FAULT_INJECTION_DEBUG_FS || FAULT_INJECTION_CONFIGFS) && STACKTRACE_SUPPORT 2201 select STACKTRACE 2202 depends on FRAME_POINTER || MIPS || PPC || S390 || MICROBLAZE || ARM || ARC || X86 2203 help 2204 Provide stacktrace filter for fault-injection capabilities 2205 2206config ARCH_HAS_KCOV 2207 bool 2208 help 2209 An architecture should select this when it can successfully 2210 build and run with CONFIG_KCOV. This typically requires 2211 disabling instrumentation for some early boot code. 2212 2213config KCOV 2214 bool "Code coverage for fuzzing" 2215 depends on ARCH_HAS_KCOV 2216 depends on !ARCH_WANTS_NO_INSTR || HAVE_NOINSTR_HACK || \ 2217 GCC_VERSION >= 120000 || CC_IS_CLANG 2218 select DEBUG_FS 2219 select OBJTOOL if HAVE_NOINSTR_HACK 2220 help 2221 KCOV exposes kernel code coverage information in a form suitable 2222 for coverage-guided fuzzing (randomized testing). 2223 2224 For more details, see Documentation/dev-tools/kcov.rst. 2225 2226config KCOV_ENABLE_COMPARISONS 2227 bool "Enable comparison operands collection by KCOV" 2228 depends on KCOV 2229 depends on $(cc-option,-fsanitize-coverage=trace-cmp) 2230 help 2231 KCOV also exposes operands of every comparison in the instrumented 2232 code along with operand sizes and PCs of the comparison instructions. 2233 These operands can be used by fuzzing engines to improve the quality 2234 of fuzzing coverage. 2235 2236config KCOV_INSTRUMENT_ALL 2237 bool "Instrument all code by default" 2238 depends on KCOV 2239 default y 2240 help 2241 If you are doing generic system call fuzzing (like e.g. syzkaller), 2242 then you will want to instrument the whole kernel and you should 2243 say y here. If you are doing more targeted fuzzing (like e.g. 2244 filesystem fuzzing with AFL) then you will want to enable coverage 2245 for more specific subsets of files, and should say n here. 2246 2247config KCOV_IRQ_AREA_SIZE 2248 hex "Size of interrupt coverage collection area in words" 2249 depends on KCOV 2250 default 0x40000 2251 help 2252 KCOV uses preallocated per-cpu areas to collect coverage from 2253 soft interrupts. This specifies the size of those areas in the 2254 number of unsigned long words. 2255 2256config KCOV_SELFTEST 2257 bool "Perform short selftests on boot" 2258 depends on KCOV 2259 help 2260 Run short KCOV coverage collection selftests on boot. 2261 On test failure, causes the kernel to panic. Recommended to be 2262 enabled, ensuring critical functionality works as intended. 2263 2264menuconfig RUNTIME_TESTING_MENU 2265 bool "Runtime Testing" 2266 default y 2267 2268if RUNTIME_TESTING_MENU 2269 2270config TEST_DHRY 2271 tristate "Dhrystone benchmark test" 2272 help 2273 Enable this to include the Dhrystone 2.1 benchmark. This test 2274 calculates the number of Dhrystones per second, and the number of 2275 DMIPS (Dhrystone MIPS) obtained when the Dhrystone score is divided 2276 by 1757 (the number of Dhrystones per second obtained on the VAX 2277 11/780, nominally a 1 MIPS machine). 2278 2279 To run the benchmark, it needs to be enabled explicitly, either from 2280 the kernel command line (when built-in), or from userspace (when 2281 built-in or modular). 2282 2283 Run once during kernel boot: 2284 2285 test_dhry.run 2286 2287 Set number of iterations from kernel command line: 2288 2289 test_dhry.iterations=<n> 2290 2291 Set number of iterations from userspace: 2292 2293 echo <n> > /sys/module/test_dhry/parameters/iterations 2294 2295 Trigger manual run from userspace: 2296 2297 echo y > /sys/module/test_dhry/parameters/run 2298 2299 If the number of iterations is <= 0, the test will devise a suitable 2300 number of iterations (test runs for at least 2s) automatically. 2301 This process takes ca. 4s. 2302 2303 If unsure, say N. 2304 2305config LKDTM 2306 tristate "Linux Kernel Dump Test Tool Module" 2307 depends on DEBUG_FS 2308 help 2309 This module enables testing of the different dumping mechanisms by 2310 inducing system failures at predefined crash points. 2311 If you don't need it: say N 2312 Choose M here to compile this code as a module. The module will be 2313 called lkdtm. 2314 2315 Documentation on how to use the module can be found in 2316 Documentation/fault-injection/provoke-crashes.rst 2317 2318config CPUMASK_KUNIT_TEST 2319 tristate "KUnit test for cpumask" if !KUNIT_ALL_TESTS 2320 depends on KUNIT 2321 default KUNIT_ALL_TESTS 2322 help 2323 Enable to turn on cpumask tests, running at boot or module load time. 2324 2325 For more information on KUnit and unit tests in general, please refer 2326 to the KUnit documentation in Documentation/dev-tools/kunit/. 2327 2328 If unsure, say N. 2329 2330config TEST_LIST_SORT 2331 tristate "Linked list sorting test" if !KUNIT_ALL_TESTS 2332 depends on KUNIT 2333 default KUNIT_ALL_TESTS 2334 help 2335 Enable this to turn on 'list_sort()' function test. This test is 2336 executed only once during system boot (so affects only boot time), 2337 or at module load time. 2338 2339 If unsure, say N. 2340 2341config TEST_SORT 2342 tristate "Array-based sort test" if !KUNIT_ALL_TESTS 2343 depends on KUNIT 2344 default KUNIT_ALL_TESTS 2345 help 2346 This option enables the self-test function of 'sort()' at boot, 2347 or at module load time. 2348 2349 If unsure, say N. 2350 2351config TEST_DIV64 2352 tristate "64bit/32bit division and modulo test" 2353 depends on DEBUG_KERNEL || m 2354 help 2355 Enable this to turn on 'do_div()' function test. This test is 2356 executed only once during system boot (so affects only boot time), 2357 or at module load time. 2358 2359 If unsure, say N. 2360 2361config TEST_MULDIV64 2362 tristate "mul_u64_u64_div_u64() test" 2363 depends on DEBUG_KERNEL || m 2364 help 2365 Enable this to turn on 'mul_u64_u64_div_u64()' function test. 2366 This test is executed only once during system boot (so affects 2367 only boot time), or at module load time. 2368 2369 If unsure, say N. 2370 2371config TEST_IOV_ITER 2372 tristate "Test iov_iter operation" if !KUNIT_ALL_TESTS 2373 depends on KUNIT 2374 depends on MMU 2375 default KUNIT_ALL_TESTS 2376 help 2377 Enable this to turn on testing of the operation of the I/O iterator 2378 (iov_iter). This test is executed only once during system boot (so 2379 affects only boot time), or at module load time. 2380 2381 If unsure, say N. 2382 2383config KPROBES_SANITY_TEST 2384 tristate "Kprobes sanity tests" if !KUNIT_ALL_TESTS 2385 depends on DEBUG_KERNEL 2386 depends on KPROBES 2387 depends on KUNIT 2388 select STACKTRACE if ARCH_CORRECT_STACKTRACE_ON_KRETPROBE 2389 default KUNIT_ALL_TESTS 2390 help 2391 This option provides for testing basic kprobes functionality on 2392 boot. Samples of kprobe and kretprobe are inserted and 2393 verified for functionality. 2394 2395 Say N if you are unsure. 2396 2397config FPROBE_SANITY_TEST 2398 bool "Self test for fprobe" 2399 depends on DEBUG_KERNEL 2400 depends on FPROBE 2401 depends on KUNIT=y 2402 help 2403 This option will enable testing the fprobe when the system boot. 2404 A series of tests are made to verify that the fprobe is functioning 2405 properly. 2406 2407 Say N if you are unsure. 2408 2409config BACKTRACE_SELF_TEST 2410 tristate "Self test for the backtrace code" 2411 depends on DEBUG_KERNEL 2412 help 2413 This option provides a kernel module that can be used to test 2414 the kernel stack backtrace code. This option is not useful 2415 for distributions or general kernels, but only for kernel 2416 developers working on architecture code. 2417 2418 Note that if you want to also test saved backtraces, you will 2419 have to enable STACKTRACE as well. 2420 2421 Say N if you are unsure. 2422 2423config TEST_REF_TRACKER 2424 tristate "Self test for reference tracker" 2425 depends on DEBUG_KERNEL && STACKTRACE_SUPPORT 2426 select REF_TRACKER 2427 help 2428 This option provides a kernel module performing tests 2429 using reference tracker infrastructure. 2430 2431 Say N if you are unsure. 2432 2433config RBTREE_TEST 2434 tristate "Red-Black tree test" 2435 depends on DEBUG_KERNEL 2436 help 2437 A benchmark measuring the performance of the rbtree library. 2438 Also includes rbtree invariant checks. 2439 2440config REED_SOLOMON_TEST 2441 tristate "Reed-Solomon library test" 2442 depends on DEBUG_KERNEL || m 2443 select REED_SOLOMON 2444 select REED_SOLOMON_ENC16 2445 select REED_SOLOMON_DEC16 2446 help 2447 This option enables the self-test function of rslib at boot, 2448 or at module load time. 2449 2450 If unsure, say N. 2451 2452config INTERVAL_TREE_TEST 2453 tristate "Interval tree test" 2454 depends on DEBUG_KERNEL 2455 select INTERVAL_TREE 2456 help 2457 A benchmark measuring the performance of the interval tree library 2458 2459config PERCPU_TEST 2460 tristate "Per cpu operations test" 2461 depends on m && DEBUG_KERNEL 2462 help 2463 Enable this option to build test module which validates per-cpu 2464 operations. 2465 2466 If unsure, say N. 2467 2468config ATOMIC64_SELFTEST 2469 tristate "Perform an atomic64_t self-test" 2470 help 2471 Enable this option to test the atomic64_t functions at boot or 2472 at module load time. 2473 2474 If unsure, say N. 2475 2476config ASYNC_RAID6_TEST 2477 tristate "Self test for hardware accelerated raid6 recovery" 2478 depends on ASYNC_RAID6_RECOV 2479 select ASYNC_MEMCPY 2480 help 2481 This is a one-shot self test that permutes through the 2482 recovery of all the possible two disk failure scenarios for a 2483 N-disk array. Recovery is performed with the asynchronous 2484 raid6 recovery routines, and will optionally use an offload 2485 engine if one is available. 2486 2487 If unsure, say N. 2488 2489config TEST_HEXDUMP 2490 tristate "Test functions located in the hexdump module at runtime" 2491 2492config PRINTF_KUNIT_TEST 2493 tristate "KUnit test printf() family of functions at runtime" if !KUNIT_ALL_TESTS 2494 depends on KUNIT 2495 default KUNIT_ALL_TESTS 2496 help 2497 Enable this option to test the printf functions at runtime. 2498 2499 If unsure, say N. 2500 2501config SCANF_KUNIT_TEST 2502 tristate "KUnit test scanf() family of functions at runtime" if !KUNIT_ALL_TESTS 2503 depends on KUNIT 2504 default KUNIT_ALL_TESTS 2505 help 2506 Enable this option to test the scanf functions at runtime. 2507 2508 If unsure, say N. 2509 2510config SEQ_BUF_KUNIT_TEST 2511 tristate "KUnit test for seq_buf" if !KUNIT_ALL_TESTS 2512 depends on KUNIT 2513 default KUNIT_ALL_TESTS 2514 help 2515 This builds unit tests for the seq_buf library. 2516 2517 If unsure, say N. 2518 2519config STRING_KUNIT_TEST 2520 tristate "KUnit test string functions at runtime" if !KUNIT_ALL_TESTS 2521 depends on KUNIT 2522 default KUNIT_ALL_TESTS 2523 2524config STRING_HELPERS_KUNIT_TEST 2525 tristate "KUnit test string helpers at runtime" if !KUNIT_ALL_TESTS 2526 depends on KUNIT 2527 default KUNIT_ALL_TESTS 2528 2529config FFS_KUNIT_TEST 2530 tristate "KUnit test ffs-family functions at runtime" if !KUNIT_ALL_TESTS 2531 depends on KUNIT 2532 default KUNIT_ALL_TESTS 2533 help 2534 This builds KUnit tests for ffs-family bit manipulation functions 2535 including ffs(), __ffs(), fls(), __fls(), fls64(), and __ffs64(). 2536 2537 These tests validate mathematical correctness, edge case handling, 2538 and cross-architecture consistency of bit scanning functions. 2539 2540 For more information on KUnit and unit tests in general, 2541 please refer to Documentation/dev-tools/kunit/. 2542 2543config TEST_KSTRTOX 2544 tristate "Test kstrto*() family of functions at runtime" 2545 2546config TEST_BITMAP 2547 tristate "Test bitmap_*() family of functions at runtime" 2548 help 2549 Enable this option to test the bitmap functions at boot. 2550 2551 If unsure, say N. 2552 2553config TEST_XARRAY 2554 tristate "Test the XArray code at runtime" 2555 2556config TEST_MAPLE_TREE 2557 tristate "Test the Maple Tree code at runtime or module load" 2558 help 2559 Enable this option to test the maple tree code functions at boot, or 2560 when the module is loaded. Enable "Debug Maple Trees" will enable 2561 more verbose output on failures. 2562 2563 If unsure, say N. 2564 2565config TEST_RHASHTABLE 2566 tristate "Perform selftest on resizable hash table" 2567 help 2568 Enable this option to test the rhashtable functions at boot. 2569 2570 If unsure, say N. 2571 2572config TEST_IDA 2573 tristate "Perform selftest on IDA functions" 2574 2575config TEST_MISC_MINOR 2576 bool "miscdevice KUnit test" if !KUNIT_ALL_TESTS 2577 depends on KUNIT=y 2578 default KUNIT_ALL_TESTS 2579 help 2580 Kunit test for miscdevice API, specially its behavior in respect to 2581 static and dynamic minor numbers. 2582 2583 KUnit tests run during boot and output the results to the debug log 2584 in TAP format (https://testanything.org/). Only useful for kernel devs 2585 running the KUnit test harness, and not intended for inclusion into a 2586 production build. 2587 2588 For more information on KUnit and unit tests in general please refer 2589 to the KUnit documentation in Documentation/dev-tools/kunit/. 2590 2591 If unsure, say N. 2592 2593config TEST_PARMAN 2594 tristate "Perform selftest on priority array manager" 2595 depends on PARMAN 2596 help 2597 Enable this option to test priority array manager on boot 2598 (or module load). 2599 2600 If unsure, say N. 2601 2602config TEST_LKM 2603 tristate "Test module loading with 'hello world' module" 2604 depends on m 2605 help 2606 This builds the "test_module" module that emits "Hello, world" 2607 on printk when loaded. It is designed to be used for basic 2608 evaluation of the module loading subsystem (for example when 2609 validating module verification). It lacks any extra dependencies, 2610 and will not normally be loaded by the system unless explicitly 2611 requested by name. 2612 2613 If unsure, say N. 2614 2615config TEST_BITOPS 2616 tristate "Test module for compilation of bitops operations" 2617 help 2618 This builds the "test_bitops" module that is much like the 2619 TEST_LKM module except that it does a basic exercise of the 2620 set/clear_bit macros and get_count_order/long to make sure there are 2621 no compiler warnings from C=1 sparse checker or -Wextra 2622 compilations. It has no dependencies and doesn't run or load unless 2623 explicitly requested by name. for example: modprobe test_bitops. 2624 2625 If unsure, say N. 2626 2627config TEST_VMALLOC 2628 tristate "Test module for stress/performance analysis of vmalloc allocator" 2629 default n 2630 depends on MMU 2631 help 2632 This builds the "test_vmalloc" module that should be used for 2633 stress and performance analysis. So, any new change for vmalloc 2634 subsystem can be evaluated from performance and stability point 2635 of view. 2636 2637 If unsure, say N. 2638 2639config TEST_BPF 2640 tristate "Test BPF filter functionality" 2641 depends on m && NET 2642 help 2643 This builds the "test_bpf" module that runs various test vectors 2644 against the BPF interpreter or BPF JIT compiler depending on the 2645 current setting. This is in particular useful for BPF JIT compiler 2646 development, but also to run regression tests against changes in 2647 the interpreter code. It also enables test stubs for eBPF maps and 2648 verifier used by user space verifier testsuite. 2649 2650 If unsure, say N. 2651 2652config FIND_BIT_BENCHMARK 2653 tristate "Test find_bit functions" 2654 help 2655 This builds the "test_find_bit" module that measure find_*_bit() 2656 functions performance. 2657 2658 If unsure, say N. 2659 2660config FIND_BIT_BENCHMARK_RUST 2661 tristate "Test find_bit functions in Rust" 2662 depends on RUST 2663 help 2664 This builds the "find_bit_benchmark_rust" module. It is a micro 2665 benchmark that measures the performance of Rust functions that 2666 correspond to the find_*_bit() operations in C. It follows the 2667 FIND_BIT_BENCHMARK closely but will in general not yield same 2668 numbers due to extra bounds checks and overhead of foreign 2669 function calls. 2670 2671 If unsure, say N. 2672 2673config TEST_FIRMWARE 2674 tristate "Test firmware loading via userspace interface" 2675 depends on FW_LOADER 2676 help 2677 This builds the "test_firmware" module that creates a userspace 2678 interface for testing firmware loading. This can be used to 2679 control the triggering of firmware loading without needing an 2680 actual firmware-using device. The contents can be rechecked by 2681 userspace. 2682 2683 If unsure, say N. 2684 2685config TEST_SYSCTL 2686 tristate "sysctl test driver" 2687 depends on PROC_SYSCTL 2688 help 2689 This builds the "test_sysctl" module. This driver enables to test the 2690 proc sysctl interfaces available to drivers safely without affecting 2691 production knobs which might alter system functionality. 2692 2693 If unsure, say N. 2694 2695config BITOPS_KUNIT 2696 tristate "KUnit test for bitops" if !KUNIT_ALL_TESTS 2697 depends on KUNIT 2698 default KUNIT_ALL_TESTS 2699 help 2700 This option enables the KUnit test for the bitops library 2701 which provides functions for bit operations. 2702 2703 Note that this is derived from the original test_bitops module. 2704 For micro-benchmarks and compiler warning checks, enable TEST_BITOPS. 2705 2706 If unsure, say N. 2707 2708config BITFIELD_KUNIT 2709 tristate "KUnit test bitfield functions at runtime" if !KUNIT_ALL_TESTS 2710 depends on KUNIT 2711 default KUNIT_ALL_TESTS 2712 help 2713 Enable this option to test the bitfield functions at boot. 2714 2715 KUnit tests run during boot and output the results to the debug log 2716 in TAP format (http://testanything.org/). Only useful for kernel devs 2717 running the KUnit test harness, and not intended for inclusion into a 2718 production build. 2719 2720 For more information on KUnit and unit tests in general please refer 2721 to the KUnit documentation in Documentation/dev-tools/kunit/. 2722 2723 If unsure, say N. 2724 2725config CHECKSUM_KUNIT 2726 tristate "KUnit test checksum functions at runtime" if !KUNIT_ALL_TESTS 2727 depends on KUNIT 2728 default KUNIT_ALL_TESTS 2729 help 2730 Enable this option to test the checksum functions at boot. 2731 2732 KUnit tests run during boot and output the results to the debug log 2733 in TAP format (http://testanything.org/). Only useful for kernel devs 2734 running the KUnit test harness, and not intended for inclusion into a 2735 production build. 2736 2737 For more information on KUnit and unit tests in general please refer 2738 to the KUnit documentation in Documentation/dev-tools/kunit/. 2739 2740 If unsure, say N. 2741 2742config UTIL_MACROS_KUNIT 2743 tristate "KUnit test util_macros.h functions at runtime" if !KUNIT_ALL_TESTS 2744 depends on KUNIT 2745 default KUNIT_ALL_TESTS 2746 help 2747 Enable this option to test the util_macros.h function at boot. 2748 2749 KUnit tests run during boot and output the results to the debug log 2750 in TAP format (http://testanything.org/). Only useful for kernel devs 2751 running the KUnit test harness, and not intended for inclusion into a 2752 production build. 2753 2754 For more information on KUnit and unit tests in general please refer 2755 to the KUnit documentation in Documentation/dev-tools/kunit/. 2756 2757 If unsure, say N. 2758 2759config HASH_KUNIT_TEST 2760 tristate "KUnit Test for integer hash functions" if !KUNIT_ALL_TESTS 2761 depends on KUNIT 2762 default KUNIT_ALL_TESTS 2763 help 2764 Enable this option to test the kernel's string (<linux/stringhash.h>), and 2765 integer (<linux/hash.h>) hash functions on boot. 2766 2767 KUnit tests run during boot and output the results to the debug log 2768 in TAP format (https://testanything.org/). Only useful for kernel devs 2769 running the KUnit test harness, and not intended for inclusion into a 2770 production build. 2771 2772 For more information on KUnit and unit tests in general please refer 2773 to the KUnit documentation in Documentation/dev-tools/kunit/. 2774 2775 This is intended to help people writing architecture-specific 2776 optimized versions. If unsure, say N. 2777 2778config RESOURCE_KUNIT_TEST 2779 tristate "KUnit test for resource API" if !KUNIT_ALL_TESTS 2780 depends on KUNIT 2781 default KUNIT_ALL_TESTS 2782 select GET_FREE_REGION 2783 help 2784 This builds the resource API unit test. 2785 Tests the logic of API provided by resource.c and ioport.h. 2786 For more information on KUnit and unit tests in general please refer 2787 to the KUnit documentation in Documentation/dev-tools/kunit/. 2788 2789 If unsure, say N. 2790 2791config SYSCTL_KUNIT_TEST 2792 tristate "KUnit test for sysctl" if !KUNIT_ALL_TESTS 2793 depends on KUNIT 2794 default KUNIT_ALL_TESTS 2795 help 2796 This builds the proc sysctl unit test, which runs on boot. 2797 Tests the API contract and implementation correctness of sysctl. 2798 For more information on KUnit and unit tests in general please refer 2799 to the KUnit documentation in Documentation/dev-tools/kunit/. 2800 2801 If unsure, say N. 2802 2803config KFIFO_KUNIT_TEST 2804 tristate "KUnit Test for the generic kernel FIFO implementation" if !KUNIT_ALL_TESTS 2805 depends on KUNIT 2806 default KUNIT_ALL_TESTS 2807 help 2808 This builds the generic FIFO implementation KUnit test suite. 2809 It tests that the API and basic functionality of the kfifo type 2810 and associated macros. 2811 2812 For more information on KUnit and unit tests in general please refer 2813 to the KUnit documentation in Documentation/dev-tools/kunit/. 2814 2815 If unsure, say N. 2816 2817config LIST_KUNIT_TEST 2818 tristate "KUnit Test for Kernel Linked-list structures" if !KUNIT_ALL_TESTS 2819 depends on KUNIT 2820 default KUNIT_ALL_TESTS 2821 help 2822 This builds the linked list KUnit test suite. 2823 It tests that the API and basic functionality of the list_head type 2824 and associated macros. 2825 2826 KUnit tests run during boot and output the results to the debug log 2827 in TAP format (https://testanything.org/). Only useful for kernel devs 2828 running the KUnit test harness, and not intended for inclusion into a 2829 production build. 2830 2831 For more information on KUnit and unit tests in general please refer 2832 to the KUnit documentation in Documentation/dev-tools/kunit/. 2833 2834 If unsure, say N. 2835 2836config LIST_PRIVATE_KUNIT_TEST 2837 tristate "KUnit Test for Kernel Private Linked-list structures" if !KUNIT_ALL_TESTS 2838 depends on KUNIT 2839 default KUNIT_ALL_TESTS 2840 help 2841 This builds the KUnit test for the private linked-list primitives 2842 defined in include/linux/list_private.h. 2843 2844 These primitives allow manipulation of list_head members that are 2845 marked as private and require special accessors (ACCESS_PRIVATE) 2846 to strip qualifiers or handle encapsulation. 2847 2848 If unsure, say N. 2849 2850config HASHTABLE_KUNIT_TEST 2851 tristate "KUnit Test for Kernel Hashtable structures" if !KUNIT_ALL_TESTS 2852 depends on KUNIT 2853 default KUNIT_ALL_TESTS 2854 help 2855 This builds the hashtable KUnit test suite. 2856 It tests the basic functionality of the API defined in 2857 include/linux/hashtable.h. For more information on KUnit and 2858 unit tests in general please refer to the KUnit documentation 2859 in Documentation/dev-tools/kunit/. 2860 2861 If unsure, say N. 2862 2863config LINEAR_RANGES_TEST 2864 tristate "KUnit test for linear_ranges" 2865 depends on KUNIT 2866 select LINEAR_RANGES 2867 help 2868 This builds the linear_ranges unit test, which runs on boot. 2869 Tests the linear_ranges logic correctness. 2870 For more information on KUnit and unit tests in general please refer 2871 to the KUnit documentation in Documentation/dev-tools/kunit/. 2872 2873 If unsure, say N. 2874 2875config CONTEXT_ANALYSIS_TEST 2876 bool "Compiler context-analysis warnings test" 2877 depends on EXPERT 2878 help 2879 This builds the test for compiler-based context analysis. The test 2880 does not add executable code to the kernel, but is meant to test that 2881 common patterns supported by the analysis do not result in false 2882 positive warnings. 2883 2884 When adding support for new context locks, it is strongly recommended 2885 to add supported patterns to this test. 2886 2887 If unsure, say N. 2888 2889config LIVEUPDATE_TEST 2890 bool "Live Update Kernel Test" 2891 default n 2892 depends on LIVEUPDATE 2893 help 2894 Enable a built-in kernel test module for the Live Update 2895 Orchestrator. 2896 2897 This module validates the File-Lifecycle-Bound subsystem by 2898 registering a set of mock FLB objects with any real file handlers 2899 that support live update (such as the memfd handler). 2900 2901 When live update operations are performed, this test module will 2902 output messages to the kernel log (dmesg), confirming that its 2903 registration and various callback functions (preserve, retrieve, 2904 finish, etc.) are being invoked correctly. 2905 2906 This is a debugging and regression testing tool for developers 2907 working on the Live Update subsystem. It should not be enabled in 2908 production kernels. 2909 2910 If unsure, say N 2911 2912config CMDLINE_KUNIT_TEST 2913 tristate "KUnit test for cmdline API" if !KUNIT_ALL_TESTS 2914 depends on KUNIT 2915 default KUNIT_ALL_TESTS 2916 help 2917 This builds the cmdline API unit test. 2918 Tests the logic of API provided by cmdline.c. 2919 For more information on KUnit and unit tests in general please refer 2920 to the KUnit documentation in Documentation/dev-tools/kunit/. 2921 2922 If unsure, say N. 2923 2924config BASE64_KUNIT 2925 tristate "KUnit test for base64 decoding and encoding" if !KUNIT_ALL_TESTS 2926 depends on KUNIT 2927 default KUNIT_ALL_TESTS 2928 help 2929 This builds the base64 unit tests. 2930 2931 The tests cover the encoding and decoding logic of Base64 functions 2932 in the kernel. 2933 In addition to correctness checks, simple performance benchmarks 2934 for both encoding and decoding are also included. 2935 2936 For more information on KUnit and unit tests in general please refer 2937 to the KUnit documentation in Documentation/dev-tools/kunit/. 2938 2939 If unsure, say N. 2940 2941config BITS_TEST 2942 tristate "KUnit test for bit functions and macros" if !KUNIT_ALL_TESTS 2943 depends on KUNIT 2944 default KUNIT_ALL_TESTS 2945 help 2946 This builds the bits unit test. 2947 Tests the logic of macros defined in bits.h. 2948 For more information on KUnit and unit tests in general please refer 2949 to the KUnit documentation in Documentation/dev-tools/kunit/. 2950 2951 If unsure, say N. 2952 2953config SLUB_KUNIT_TEST 2954 tristate "KUnit test for SLUB cache error detection" if !KUNIT_ALL_TESTS 2955 depends on SLUB_DEBUG && KUNIT 2956 default KUNIT_ALL_TESTS 2957 help 2958 This builds SLUB allocator unit test. 2959 Tests SLUB cache debugging functionality. 2960 For more information on KUnit and unit tests in general please refer 2961 to the KUnit documentation in Documentation/dev-tools/kunit/. 2962 2963 If unsure, say N. 2964 2965config RATIONAL_KUNIT_TEST 2966 tristate "KUnit test for rational.c" if !KUNIT_ALL_TESTS 2967 depends on KUNIT && RATIONAL 2968 default KUNIT_ALL_TESTS 2969 help 2970 This builds the rational math unit test. 2971 For more information on KUnit and unit tests in general please refer 2972 to the KUnit documentation in Documentation/dev-tools/kunit/. 2973 2974 If unsure, say N. 2975 2976config MEMCPY_KUNIT_TEST 2977 tristate "Test memcpy(), memmove(), and memset() functions at runtime" if !KUNIT_ALL_TESTS 2978 depends on KUNIT 2979 default KUNIT_ALL_TESTS 2980 help 2981 Builds unit tests for memcpy(), memmove(), and memset() functions. 2982 For more information on KUnit and unit tests in general please refer 2983 to the KUnit documentation in Documentation/dev-tools/kunit/. 2984 2985 If unsure, say N. 2986 2987config MIN_HEAP_KUNIT_TEST 2988 tristate "Min heap test" if !KUNIT_ALL_TESTS 2989 depends on KUNIT 2990 default KUNIT_ALL_TESTS 2991 help 2992 This option enables the KUnit test suite for the min heap library 2993 which provides functions for creating and managing min heaps. 2994 The test suite checks the functionality of the min heap library. 2995 2996 If unsure, say N 2997 2998config IS_SIGNED_TYPE_KUNIT_TEST 2999 tristate "Test is_signed_type() macro" if !KUNIT_ALL_TESTS 3000 depends on KUNIT 3001 default KUNIT_ALL_TESTS 3002 help 3003 Builds unit tests for the is_signed_type() macro. 3004 3005 For more information on KUnit and unit tests in general please refer 3006 to the KUnit documentation in Documentation/dev-tools/kunit/. 3007 3008 If unsure, say N. 3009 3010config OVERFLOW_KUNIT_TEST 3011 tristate "Test check_*_overflow() functions at runtime" if !KUNIT_ALL_TESTS 3012 depends on KUNIT 3013 default KUNIT_ALL_TESTS 3014 help 3015 Builds unit tests for the check_*_overflow(), size_*(), allocation, and 3016 related functions. 3017 3018 For more information on KUnit and unit tests in general please refer 3019 to the KUnit documentation in Documentation/dev-tools/kunit/. 3020 3021 If unsure, say N. 3022 3023config RANDSTRUCT_KUNIT_TEST 3024 tristate "Test randstruct structure layout randomization at runtime" if !KUNIT_ALL_TESTS 3025 depends on KUNIT 3026 default KUNIT_ALL_TESTS 3027 help 3028 Builds unit tests for the checking CONFIG_RANDSTRUCT=y, which 3029 randomizes structure layouts. 3030 3031config STACKINIT_KUNIT_TEST 3032 tristate "Test level of stack variable initialization" if !KUNIT_ALL_TESTS 3033 depends on KUNIT 3034 default KUNIT_ALL_TESTS 3035 help 3036 Test if the kernel is zero-initializing stack variables and 3037 padding. Coverage is controlled by compiler flags, 3038 CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_ALL_ZERO. 3039 3040config FORTIFY_KUNIT_TEST 3041 tristate "Test fortified str*() and mem*() function internals at runtime" if !KUNIT_ALL_TESTS 3042 depends on KUNIT 3043 default KUNIT_ALL_TESTS 3044 help 3045 Builds unit tests for checking internals of FORTIFY_SOURCE as used 3046 by the str*() and mem*() family of functions. For testing runtime 3047 traps of FORTIFY_SOURCE, see LKDTM's "FORTIFY_*" tests. 3048 3049config LONGEST_SYM_KUNIT_TEST 3050 tristate "Test the longest symbol possible" if !KUNIT_ALL_TESTS 3051 depends on KUNIT && KPROBES 3052 depends on !PREFIX_SYMBOLS && !CFI && !GCOV_KERNEL 3053 default KUNIT_ALL_TESTS 3054 help 3055 Tests the longest symbol possible 3056 3057 If unsure, say N. 3058 3059config HW_BREAKPOINT_KUNIT_TEST 3060 bool "Test hw_breakpoint constraints accounting" if !KUNIT_ALL_TESTS 3061 depends on HAVE_HW_BREAKPOINT 3062 depends on KUNIT=y 3063 default KUNIT_ALL_TESTS 3064 help 3065 Tests for hw_breakpoint constraints accounting. 3066 3067 If unsure, say N. 3068 3069source "lib/crypto/tests/Kconfig" 3070 3071config SIPHASH_KUNIT_TEST 3072 tristate "Perform selftest on siphash functions" if !KUNIT_ALL_TESTS 3073 depends on KUNIT 3074 default KUNIT_ALL_TESTS 3075 help 3076 Enable this option to test the kernel's siphash (<linux/siphash.h>) hash 3077 functions on boot (or module load). 3078 3079 This is intended to help people writing architecture-specific 3080 optimized versions. If unsure, say N. 3081 3082config USERCOPY_KUNIT_TEST 3083 tristate "KUnit Test for user/kernel boundary protections" 3084 depends on KUNIT 3085 default KUNIT_ALL_TESTS 3086 help 3087 This builds the "usercopy_kunit" module that runs sanity checks 3088 on the copy_to/from_user infrastructure, making sure basic 3089 user/kernel boundary testing is working. 3090 3091config BLACKHOLE_DEV_KUNIT_TEST 3092 tristate "Test blackhole netdev functionality" if !KUNIT_ALL_TESTS 3093 depends on NET 3094 depends on KUNIT 3095 default KUNIT_ALL_TESTS 3096 help 3097 This builds the "blackhole_dev_kunit" module that validates the 3098 data path through this blackhole netdev. 3099 3100 If unsure, say N. 3101 3102config TEST_UDELAY 3103 tristate "udelay test driver" 3104 help 3105 This builds the "udelay_test" module that helps to make sure 3106 that udelay() is working properly. 3107 3108 If unsure, say N. 3109 3110config TEST_STATIC_KEYS 3111 tristate "Test static keys" 3112 depends on m 3113 help 3114 Test the static key interfaces. 3115 3116 If unsure, say N. 3117 3118config TEST_DYNAMIC_DEBUG 3119 tristate "Test DYNAMIC_DEBUG" 3120 depends on DYNAMIC_DEBUG 3121 help 3122 This module registers a tracer callback to count enabled 3123 pr_debugs in a 'do_debugging' function, then alters their 3124 enablements, calls the function, and compares counts. 3125 3126 If unsure, say N. 3127 3128config TEST_KMOD 3129 tristate "kmod stress tester" 3130 depends on m 3131 select TEST_LKM 3132 help 3133 Test the kernel's module loading mechanism: kmod. kmod implements 3134 support to load modules using the Linux kernel's usermode helper. 3135 This test provides a series of tests against kmod. 3136 3137 Although technically you can either build test_kmod as a module or 3138 into the kernel we disallow building it into the kernel since 3139 it stress tests request_module() and this will very likely cause 3140 some issues by taking over precious threads available from other 3141 module load requests, ultimately this could be fatal. 3142 3143 To run tests run: 3144 3145 tools/testing/selftests/kmod/kmod.sh --help 3146 3147 If unsure, say N. 3148 3149config TEST_RUNTIME 3150 bool 3151 3152config TEST_RUNTIME_MODULE 3153 bool 3154 3155config TEST_KALLSYMS 3156 tristate "module kallsyms find_symbol() test" 3157 depends on m 3158 select TEST_RUNTIME 3159 select TEST_RUNTIME_MODULE 3160 select TEST_KALLSYMS_A 3161 select TEST_KALLSYMS_B 3162 select TEST_KALLSYMS_C 3163 select TEST_KALLSYMS_D 3164 help 3165 This allows us to stress test find_symbol() through the kallsyms 3166 used to place symbols on the kernel ELF kallsyms and modules kallsyms 3167 where we place kernel symbols such as exported symbols. 3168 3169 We have four test modules: 3170 3171 A: has KALLSYSMS_NUMSYMS exported symbols 3172 B: uses one of A's symbols 3173 C: adds KALLSYMS_SCALE_FACTOR * KALLSYSMS_NUMSYMS exported 3174 D: adds 2 * the symbols than C 3175 3176 We stress test find_symbol() through two means: 3177 3178 1) Upon load of B it will trigger simplify_symbols() to look for the 3179 one symbol it uses from the module A with tons of symbols. This is an 3180 indirect way for us to have B call resolve_symbol_wait() upon module 3181 load. This will eventually call find_symbol() which will eventually 3182 try to find the symbols used with find_exported_symbol_in_section(). 3183 find_exported_symbol_in_section() uses bsearch() so a binary search 3184 for each symbol. Binary search will at worst be O(log(n)) so the 3185 larger TEST_MODULE_KALLSYSMS the worse the search. 3186 3187 2) The selftests should load C first, before B. Upon B's load towards 3188 the end right before we call module B's init routine we get 3189 complete_formation() called on the module. That will first check 3190 for duplicate symbols with the call to verify_exported_symbols(). 3191 That is when we'll force iteration on module C's insane symbol list. 3192 Since it has 10 * KALLSYMS_NUMSYMS it means we can first test 3193 just loading B without C. The amount of time it takes to load C Vs 3194 B can give us an idea of the impact growth of the symbol space and 3195 give us projection. Module A only uses one symbol from B so to allow 3196 this scaling in module C to be proportional, if it used more symbols 3197 then the first test would be doing more and increasing just the 3198 search space would be slightly different. The last module, module D 3199 will just increase the search space by twice the number of symbols in 3200 C so to allow for full projects. 3201 3202 tools/testing/selftests/module/find_symbol.sh 3203 3204 The current defaults will incur a build delay of about 7 minutes 3205 on an x86_64 with only 8 cores. Enable this only if you want to 3206 stress test find_symbol() with thousands of symbols. At the same 3207 time this is also useful to test building modules with thousands of 3208 symbols, and if BTF is enabled this also stress tests adding BTF 3209 information for each module. Currently enabling many more symbols 3210 will segfault the build system. 3211 3212 If unsure, say N. 3213 3214if TEST_KALLSYMS 3215 3216config TEST_KALLSYMS_A 3217 tristate 3218 depends on m 3219 3220config TEST_KALLSYMS_B 3221 tristate 3222 depends on m 3223 3224config TEST_KALLSYMS_C 3225 tristate 3226 depends on m 3227 3228config TEST_KALLSYMS_D 3229 tristate 3230 depends on m 3231 3232choice 3233 prompt "Kallsym test range" 3234 default TEST_KALLSYMS_LARGE 3235 help 3236 Selecting something other than "Fast" will enable tests which slow 3237 down the build and may crash your build. 3238 3239config TEST_KALLSYMS_FAST 3240 bool "Fast builds" 3241 help 3242 You won't really be testing kallsysms, so this just helps fast builds 3243 when allmodconfig is used.. 3244 3245config TEST_KALLSYMS_LARGE 3246 bool "Enable testing kallsyms with large exports" 3247 help 3248 This will enable larger number of symbols. This will slow down 3249 your build considerably. 3250 3251config TEST_KALLSYMS_MAX 3252 bool "Known kallsysms limits" 3253 help 3254 This will enable exports to the point we know we'll start crashing 3255 builds. 3256 3257endchoice 3258 3259config TEST_KALLSYMS_NUMSYMS 3260 int "test kallsyms number of symbols" 3261 range 2 10000 3262 default 2 if TEST_KALLSYMS_FAST 3263 default 100 if TEST_KALLSYMS_LARGE 3264 default 10000 if TEST_KALLSYMS_MAX 3265 help 3266 The number of symbols to create on TEST_KALLSYMS_A, only one of which 3267 module TEST_KALLSYMS_B will use. This also will be used 3268 for how many symbols TEST_KALLSYMS_C will have, scaled up by 3269 TEST_KALLSYMS_SCALE_FACTOR. Note that setting this to 10,000 will 3270 trigger a segfault today, don't use anything close to it unless 3271 you are aware that this should not be used for automated build tests. 3272 3273config TEST_KALLSYMS_SCALE_FACTOR 3274 int "test kallsyms scale factor" 3275 default 8 3276 help 3277 How many more unusued symbols will TEST_KALLSYSMS_C have than 3278 TEST_KALLSYMS_A. If 8, then module C will have 8 * syms 3279 than module A. Then TEST_KALLSYMS_D will have double the amount 3280 of symbols than C so to allow projections. 3281 3282endif # TEST_KALLSYMS 3283 3284config TEST_DEBUG_VIRTUAL 3285 tristate "Test CONFIG_DEBUG_VIRTUAL feature" 3286 depends on DEBUG_VIRTUAL 3287 help 3288 Test the kernel's ability to detect incorrect calls to 3289 virt_to_phys() done against the non-linear part of the 3290 kernel's virtual address map. 3291 3292 If unsure, say N. 3293 3294config TEST_MEMCAT_P 3295 tristate "Test memcat_p() helper function" 3296 help 3297 Test the memcat_p() helper for correctly merging two 3298 pointer arrays together. 3299 3300 If unsure, say N. 3301 3302config TEST_OBJAGG 3303 tristate "Perform selftest on object aggreration manager" 3304 default n 3305 depends on OBJAGG 3306 help 3307 Enable this option to test object aggregation manager on boot 3308 (or module load). 3309 3310config TEST_MEMINIT 3311 tristate "Test heap/page initialization" 3312 help 3313 Test if the kernel is zero-initializing heap and page allocations. 3314 This can be useful to test init_on_alloc and init_on_free features. 3315 3316 If unsure, say N. 3317 3318config TEST_HMM 3319 tristate "Test HMM (Heterogeneous Memory Management)" 3320 depends on TRANSPARENT_HUGEPAGE 3321 depends on DEVICE_PRIVATE 3322 select HMM_MIRROR 3323 select MMU_NOTIFIER 3324 help 3325 This is a pseudo device driver solely for testing HMM. 3326 Say M here if you want to build the HMM test module. 3327 Doing so will allow you to run tools/testing/selftest/vm/hmm-tests. 3328 3329 If unsure, say N. 3330 3331config TEST_FREE_PAGES 3332 tristate "Test freeing pages" 3333 help 3334 Test that a memory leak does not occur due to a race between 3335 freeing a block of pages and a speculative page reference. 3336 Loading this module is safe if your kernel has the bug fixed. 3337 If the bug is not fixed, it will leak gigabytes of memory and 3338 probably OOM your system. 3339 3340config TEST_FPU 3341 tristate "Test floating point operations in kernel space" 3342 depends on ARCH_HAS_KERNEL_FPU_SUPPORT && !KCOV_INSTRUMENT_ALL 3343 help 3344 Enable this option to add /sys/kernel/debug/selftest_helpers/test_fpu 3345 which will trigger a sequence of floating point operations. This is used 3346 for self-testing floating point control register setting in 3347 kernel_fpu_begin(). 3348 3349 If unsure, say N. 3350 3351config TEST_CLOCKSOURCE_WATCHDOG 3352 tristate "Test clocksource watchdog in kernel space" 3353 depends on CLOCKSOURCE_WATCHDOG 3354 help 3355 Enable this option to create a kernel module that will trigger 3356 a test of the clocksource watchdog. This module may be loaded 3357 via modprobe or insmod in which case it will run upon being 3358 loaded, or it may be built in, in which case it will run 3359 shortly after boot. 3360 3361 If unsure, say N. 3362 3363config TEST_OBJPOOL 3364 tristate "Test module for correctness and stress of objpool" 3365 default n 3366 depends on m && DEBUG_KERNEL 3367 help 3368 This builds the "test_objpool" module that should be used for 3369 correctness verification and concurrent testings of objects 3370 allocation and reclamation. 3371 3372 If unsure, say N. 3373 3374config TEST_KEXEC_HANDOVER 3375 bool "Test for Kexec HandOver" 3376 default n 3377 depends on KEXEC_HANDOVER 3378 help 3379 This option enables test for Kexec HandOver (KHO). 3380 The test consists of two parts: saving kernel data before kexec and 3381 restoring the data after kexec and verifying that it was properly 3382 handed over. This test module creates and saves data on the boot of 3383 the first kernel and restores and verifies the data on the boot of 3384 kexec'ed kernel. 3385 3386 For detailed documentation about KHO, see Documentation/core-api/kho. 3387 3388 To run the test run: 3389 3390 tools/testing/selftests/kho/vmtest.sh -h 3391 3392 If unsure, say N. 3393 3394config RATELIMIT_KUNIT_TEST 3395 tristate "KUnit Test for correctness and stress of ratelimit" if !KUNIT_ALL_TESTS 3396 depends on KUNIT 3397 default KUNIT_ALL_TESTS 3398 help 3399 This builds the "test_ratelimit" module that should be used 3400 for correctness verification and concurrent testings of rate 3401 limiting. 3402 3403 If unsure, say N. 3404 3405config UUID_KUNIT_TEST 3406 tristate "KUnit test for UUID" if !KUNIT_ALL_TESTS 3407 depends on KUNIT 3408 default KUNIT_ALL_TESTS 3409 help 3410 This option enables the KUnit test suite for the uuid library, 3411 which provides functions for generating and parsing UUID and GUID. 3412 The test suite checks parsing of UUID and GUID strings. 3413 3414 If unsure, say N. 3415 3416config INT_POW_KUNIT_TEST 3417 tristate "Integer exponentiation (int_pow) test" if !KUNIT_ALL_TESTS 3418 depends on KUNIT 3419 default KUNIT_ALL_TESTS 3420 help 3421 This option enables the KUnit test suite for the int_pow function, 3422 which performs integer exponentiation. The test suite is designed to 3423 verify that the implementation of int_pow correctly computes the power 3424 of a given base raised to a given exponent. 3425 3426 Enabling this option will include tests that check various scenarios 3427 and edge cases to ensure the accuracy and reliability of the exponentiation 3428 function. 3429 3430 If unsure, say N 3431 3432config INT_SQRT_KUNIT_TEST 3433 tristate "Integer square root test" if !KUNIT_ALL_TESTS 3434 depends on KUNIT 3435 default KUNIT_ALL_TESTS 3436 help 3437 This option enables the KUnit test suite for the int_sqrt() function, 3438 which performs square root calculation. The test suite checks 3439 various scenarios, including edge cases, to ensure correctness. 3440 3441 Enabling this option will include tests that check various scenarios 3442 and edge cases to ensure the accuracy and reliability of the square root 3443 function. 3444 3445 If unsure, say N 3446 3447config INT_LOG_KUNIT_TEST 3448 tristate "Integer log (int_log) test" if !KUNIT_ALL_TESTS 3449 depends on KUNIT 3450 default KUNIT_ALL_TESTS 3451 help 3452 This option enables the KUnit test suite for the int_log library, which 3453 provides two functions to compute the integer logarithm in base 2 and 3454 base 10, called respectively as intlog2 and intlog10. 3455 3456 If unsure, say N 3457 3458config GCD_KUNIT_TEST 3459 tristate "Greatest common divisor test" if !KUNIT_ALL_TESTS 3460 depends on KUNIT 3461 default KUNIT_ALL_TESTS 3462 help 3463 This option enables the KUnit test suite for the gcd() function, 3464 which computes the greatest common divisor of two numbers. 3465 3466 This test suite verifies the correctness of gcd() across various 3467 scenarios, including edge cases. 3468 3469 If unsure, say N 3470 3471config PRIME_NUMBERS_KUNIT_TEST 3472 tristate "Prime number generator test" if !KUNIT_ALL_TESTS 3473 depends on KUNIT 3474 depends on PRIME_NUMBERS 3475 default KUNIT_ALL_TESTS 3476 help 3477 This option enables the KUnit test suite for the {is,next}_prime_number 3478 functions. 3479 3480 Enabling this option will include tests that compare the prime number 3481 generator functions against a brute force implementation. 3482 3483 If unsure, say N 3484 3485config GLOB_KUNIT_TEST 3486 tristate "Glob matching test" if !KUNIT_ALL_TESTS 3487 depends on GLOB 3488 depends on KUNIT 3489 default KUNIT_ALL_TESTS 3490 help 3491 Enable this option to test the glob functions at runtime. 3492 3493 This test suite verifies the correctness of glob_match() across various 3494 scenarios, including edge cases. 3495 3496 If unsure, say N 3497 3498endif # RUNTIME_TESTING_MENU 3499 3500config ARCH_USE_MEMTEST 3501 bool 3502 help 3503 An architecture should select this when it uses early_memtest() 3504 during boot process. 3505 3506config MEMTEST 3507 bool "Memtest" 3508 depends on ARCH_USE_MEMTEST 3509 help 3510 This option adds a kernel parameter 'memtest', which allows memtest 3511 to be set and executed. 3512 memtest=0, mean disabled; -- default 3513 memtest=1, mean do 1 test pattern; 3514 ... 3515 memtest=17, mean do 17 test patterns. 3516 If you are unsure how to answer this question, answer N. 3517 3518 3519 3520config HYPERV_TESTING 3521 bool "Microsoft Hyper-V driver testing" 3522 default n 3523 depends on HYPERV && DEBUG_FS 3524 help 3525 Select this option to enable Hyper-V vmbus testing. 3526 3527endmenu # "Kernel Testing and Coverage" 3528 3529menu "Rust hacking" 3530 3531config RUST_DEBUG_ASSERTIONS 3532 bool "Debug assertions" 3533 depends on RUST 3534 help 3535 Enables rustc's `-Cdebug-assertions` codegen option. 3536 3537 This flag lets you turn `cfg(debug_assertions)` conditional 3538 compilation on or off. This can be used to enable extra debugging 3539 code in development but not in production. For example, it controls 3540 the behavior of the standard library's `debug_assert!` macro. 3541 3542 Note that this will apply to all Rust code, including `core`. 3543 3544 If unsure, say N. 3545 3546config RUST_OVERFLOW_CHECKS 3547 bool "Overflow checks" 3548 default y 3549 depends on RUST 3550 help 3551 Enables rustc's `-Coverflow-checks` codegen option. 3552 3553 This flag allows you to control the behavior of runtime integer 3554 overflow. When overflow-checks are enabled, a Rust panic will occur 3555 on overflow. 3556 3557 Note that this will apply to all Rust code, including `core`. 3558 3559 If unsure, say Y. 3560 3561config RUST_BUILD_ASSERT_ALLOW 3562 bool "Allow unoptimized build-time assertions" 3563 depends on RUST 3564 help 3565 Controls how `build_error!` and `build_assert!` are handled during the build. 3566 3567 If calls to them exist in the binary, it may indicate a violated invariant 3568 or that the optimizer failed to verify the invariant during compilation. 3569 3570 This should not happen, thus by default the build is aborted. However, 3571 as an escape hatch, you can choose Y here to ignore them during build 3572 and let the check be carried at runtime (with `panic!` being called if 3573 the check fails). 3574 3575 If unsure, say N. 3576 3577config RUST_KERNEL_DOCTESTS 3578 bool "Doctests for the `kernel` crate" if !KUNIT_ALL_TESTS 3579 depends on RUST && KUNIT=y 3580 default KUNIT_ALL_TESTS 3581 help 3582 This builds the documentation tests of the `kernel` crate 3583 as KUnit tests. 3584 3585 For more information on KUnit and unit tests in general, 3586 please refer to the KUnit documentation in Documentation/dev-tools/kunit/. 3587 3588 If unsure, say N. 3589 3590config RUST_INLINE_HELPERS 3591 bool "Inline C helpers into Rust code (EXPERIMENTAL)" 3592 depends on RUST && RUSTC_CLANG_LLVM_COMPATIBLE 3593 depends on EXPERT 3594 depends on ARM64 || X86_64 3595 depends on !UML 3596 help 3597 Inlines C helpers into Rust code using Link Time Optimization. 3598 3599 If this option is enabled, C helper functions declared in 3600 rust/helpers/ are inlined into Rust code, which is helpful for 3601 performance of Rust code. This requires a matching LLVM version for 3602 Clang and rustc. 3603 3604 If you are sure that you're using Clang and rustc with matching LLVM 3605 versions, say Y. Otherwise say N. 3606 3607endmenu # "Rust" 3608 3609endmenu # Kernel hacking 3610