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