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