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 STACKTRACE_BUILD_ID 39 bool "Show build ID information in stacktraces" 40 depends on PRINTK 41 help 42 Selecting this option adds build ID information for symbols in 43 stacktraces printed with the printk format '%p[SR]b'. 44 45 This option is intended for distros where debuginfo is not easily 46 accessible but can be downloaded given the build ID of the vmlinux or 47 kernel module where the function is located. 48 49config CONSOLE_LOGLEVEL_DEFAULT 50 int "Default console loglevel (1-15)" 51 range 1 15 52 default "7" 53 help 54 Default loglevel to determine what will be printed on the console. 55 56 Setting a default here is equivalent to passing in loglevel=<x> in 57 the kernel bootargs. loglevel=<x> continues to override whatever 58 value is specified here as well. 59 60 Note: This does not affect the log level of un-prefixed printk() 61 usage in the kernel. That is controlled by the MESSAGE_LOGLEVEL_DEFAULT 62 option. 63 64config CONSOLE_LOGLEVEL_QUIET 65 int "quiet console loglevel (1-15)" 66 range 1 15 67 default "4" 68 help 69 loglevel to use when "quiet" is passed on the kernel commandline. 70 71 When "quiet" is passed on the kernel commandline this loglevel 72 will be used as the loglevel. IOW passing "quiet" will be the 73 equivalent of passing "loglevel=<CONSOLE_LOGLEVEL_QUIET>" 74 75config MESSAGE_LOGLEVEL_DEFAULT 76 int "Default message log level (1-7)" 77 range 1 7 78 default "4" 79 help 80 Default log level for printk statements with no specified priority. 81 82 This was hard-coded to KERN_WARNING since at least 2.6.10 but folks 83 that are auditing their logs closely may want to set it to a lower 84 priority. 85 86 Note: This does not affect what message level gets printed on the console 87 by default. To change that, use loglevel=<x> in the kernel bootargs, 88 or pick a different CONSOLE_LOGLEVEL_DEFAULT configuration value. 89 90config BOOT_PRINTK_DELAY 91 bool "Delay each boot printk message by N milliseconds" 92 depends on DEBUG_KERNEL && PRINTK && GENERIC_CALIBRATE_DELAY 93 help 94 This build option allows you to read kernel boot messages 95 by inserting a short delay after each one. The delay is 96 specified in milliseconds on the kernel command line, 97 using "boot_delay=N". 98 99 It is likely that you would also need to use "lpj=M" to preset 100 the "loops per jiffie" value. 101 See a previous boot log for the "lpj" value to use for your 102 system, and then set "lpj=M" before setting "boot_delay=N". 103 NOTE: Using this option may adversely affect SMP systems. 104 I.e., processors other than the first one may not boot up. 105 BOOT_PRINTK_DELAY also may cause LOCKUP_DETECTOR to detect 106 what it believes to be lockup conditions. 107 108config DYNAMIC_DEBUG 109 bool "Enable dynamic printk() support" 110 default n 111 depends on PRINTK 112 depends on (DEBUG_FS || PROC_FS) 113 select DYNAMIC_DEBUG_CORE 114 help 115 116 Compiles debug level messages into the kernel, which would not 117 otherwise be available at runtime. These messages can then be 118 enabled/disabled based on various levels of scope - per source file, 119 function, module, format string, and line number. This mechanism 120 implicitly compiles in all pr_debug() and dev_dbg() calls, which 121 enlarges the kernel text size by about 2%. 122 123 If a source file is compiled with DEBUG flag set, any 124 pr_debug() calls in it are enabled by default, but can be 125 disabled at runtime as below. Note that DEBUG flag is 126 turned on by many CONFIG_*DEBUG* options. 127 128 Usage: 129 130 Dynamic debugging is controlled via the 'dynamic_debug/control' file, 131 which is contained in the 'debugfs' filesystem or procfs. 132 Thus, the debugfs or procfs filesystem must first be mounted before 133 making use of this feature. 134 We refer the control file as: <debugfs>/dynamic_debug/control. This 135 file contains a list of the debug statements that can be enabled. The 136 format for each line of the file is: 137 138 filename:lineno [module]function flags format 139 140 filename : source file of the debug statement 141 lineno : line number of the debug statement 142 module : module that contains the debug statement 143 function : function that contains the debug statement 144 flags : '=p' means the line is turned 'on' for printing 145 format : the format used for the debug statement 146 147 From a live system: 148 149 nullarbor:~ # cat <debugfs>/dynamic_debug/control 150 # filename:lineno [module]function flags format 151 fs/aio.c:222 [aio]__put_ioctx =_ "__put_ioctx:\040freeing\040%p\012" 152 fs/aio.c:248 [aio]ioctx_alloc =_ "ENOMEM:\040nr_events\040too\040high\012" 153 fs/aio.c:1770 [aio]sys_io_cancel =_ "calling\040cancel\012" 154 155 Example usage: 156 157 // enable the message at line 1603 of file svcsock.c 158 nullarbor:~ # echo -n 'file svcsock.c line 1603 +p' > 159 <debugfs>/dynamic_debug/control 160 161 // enable all the messages in file svcsock.c 162 nullarbor:~ # echo -n 'file svcsock.c +p' > 163 <debugfs>/dynamic_debug/control 164 165 // enable all the messages in the NFS server module 166 nullarbor:~ # echo -n 'module nfsd +p' > 167 <debugfs>/dynamic_debug/control 168 169 // enable all 12 messages in the function svc_process() 170 nullarbor:~ # echo -n 'func svc_process +p' > 171 <debugfs>/dynamic_debug/control 172 173 // disable all 12 messages in the function svc_process() 174 nullarbor:~ # echo -n 'func svc_process -p' > 175 <debugfs>/dynamic_debug/control 176 177 See Documentation/admin-guide/dynamic-debug-howto.rst for additional 178 information. 179 180config DYNAMIC_DEBUG_CORE 181 bool "Enable core function of dynamic debug support" 182 depends on PRINTK 183 depends on (DEBUG_FS || PROC_FS) 184 help 185 Enable core functional support of dynamic debug. It is useful 186 when you want to tie dynamic debug to your kernel modules with 187 DYNAMIC_DEBUG_MODULE defined for each of them, especially for 188 the case of embedded system where the kernel image size is 189 sensitive for people. 190 191config SYMBOLIC_ERRNAME 192 bool "Support symbolic error names in printf" 193 default y if PRINTK 194 help 195 If you say Y here, the kernel's printf implementation will 196 be able to print symbolic error names such as ENOSPC instead 197 of the number 28. It makes the kernel image slightly larger 198 (about 3KB), but can make the kernel logs easier to read. 199 200config DEBUG_BUGVERBOSE 201 bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT 202 depends on BUG && (GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE) 203 default y 204 help 205 Say Y here to make BUG() panics output the file name and line number 206 of the BUG call as well as the EIP and oops trace. This aids 207 debugging but costs about 70-100K of memory. 208 209endmenu # "printk and dmesg options" 210 211config DEBUG_KERNEL 212 bool "Kernel debugging" 213 help 214 Say Y here if you are developing drivers or trying to debug and 215 identify kernel problems. 216 217config DEBUG_MISC 218 bool "Miscellaneous debug code" 219 default DEBUG_KERNEL 220 depends on DEBUG_KERNEL 221 help 222 Say Y here if you need to enable miscellaneous debug code that should 223 be under a more specific debug option but isn't. 224 225menu "Compile-time checks and compiler options" 226 227config DEBUG_INFO 228 bool 229 help 230 A kernel debug info option other than "None" has been selected 231 in the "Debug information" choice below, indicating that debug 232 information will be generated for build targets. 233 234# Clang is known to generate .{s,u}leb128 with symbol deltas with DWARF5, which 235# some targets may not support: https://sourceware.org/bugzilla/show_bug.cgi?id=27215 236config AS_HAS_NON_CONST_LEB128 237 def_bool $(as-instr,.uleb128 .Lexpr_end4 - .Lexpr_start3\n.Lexpr_start3:\n.Lexpr_end4:) 238 239choice 240 prompt "Debug information" 241 depends on DEBUG_KERNEL 242 help 243 Selecting something other than "None" results in a kernel image 244 that will include debugging info resulting in a larger kernel image. 245 This adds debug symbols to the kernel and modules (gcc -g), and 246 is needed if you intend to use kernel crashdump or binary object 247 tools like crash, kgdb, LKCD, gdb, etc on the kernel. 248 249 Choose which version of DWARF debug info to emit. If unsure, 250 select "Toolchain default". 251 252config DEBUG_INFO_NONE 253 bool "Disable debug information" 254 help 255 Do not build the kernel with debugging information, which will 256 result in a faster and smaller build. 257 258config DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT 259 bool "Rely on the toolchain's implicit default DWARF version" 260 select DEBUG_INFO 261 depends on !CC_IS_CLANG || AS_IS_LLVM || CLANG_VERSION < 140000 || (AS_IS_GNU && AS_VERSION >= 23502 && AS_HAS_NON_CONST_LEB128) 262 help 263 The implicit default version of DWARF debug info produced by a 264 toolchain changes over time. 265 266 This can break consumers of the debug info that haven't upgraded to 267 support newer revisions, and prevent testing newer versions, but 268 those should be less common scenarios. 269 270config DEBUG_INFO_DWARF4 271 bool "Generate DWARF Version 4 debuginfo" 272 select DEBUG_INFO 273 depends on !CC_IS_CLANG || AS_IS_LLVM || (AS_IS_GNU && AS_VERSION >= 23502) 274 help 275 Generate DWARF v4 debug info. This requires gcc 4.5+, binutils 2.35.2 276 if using clang without clang's integrated assembler, and gdb 7.0+. 277 278 If you have consumers of DWARF debug info that are not ready for 279 newer revisions of DWARF, you may wish to choose this or have your 280 config select this. 281 282config DEBUG_INFO_DWARF5 283 bool "Generate DWARF Version 5 debuginfo" 284 select DEBUG_INFO 285 depends on !ARCH_HAS_BROKEN_DWARF5 286 depends on !CC_IS_CLANG || AS_IS_LLVM || (AS_IS_GNU && AS_VERSION >= 23502 && AS_HAS_NON_CONST_LEB128) 287 help 288 Generate DWARF v5 debug info. Requires binutils 2.35.2, gcc 5.0+ (gcc 289 5.0+ accepts the -gdwarf-5 flag but only had partial support for some 290 draft features until 7.0), and gdb 8.0+. 291 292 Changes to the structure of debug info in Version 5 allow for around 293 15-18% savings in resulting image and debug info section sizes as 294 compared to DWARF Version 4. DWARF Version 5 standardizes previous 295 extensions such as accelerators for symbol indexing and the format 296 for fission (.dwo/.dwp) files. Users may not want to select this 297 config if they rely on tooling that has not yet been updated to 298 support DWARF Version 5. 299 300endchoice # "Debug information" 301 302if DEBUG_INFO 303 304config DEBUG_INFO_REDUCED 305 bool "Reduce debugging information" 306 help 307 If you say Y here gcc is instructed to generate less debugging 308 information for structure types. This means that tools that 309 need full debugging information (like kgdb or systemtap) won't 310 be happy. But if you merely need debugging information to 311 resolve line numbers there is no loss. Advantage is that 312 build directory object sizes shrink dramatically over a full 313 DEBUG_INFO build and compile times are reduced too. 314 Only works with newer gcc versions. 315 316choice 317 prompt "Compressed Debug information" 318 help 319 Compress the resulting debug info. Results in smaller debug info sections, 320 but requires that consumers are able to decompress the results. 321 322 If unsure, choose DEBUG_INFO_COMPRESSED_NONE. 323 324config DEBUG_INFO_COMPRESSED_NONE 325 bool "Don't compress debug information" 326 help 327 Don't compress debug info sections. 328 329config DEBUG_INFO_COMPRESSED_ZLIB 330 bool "Compress debugging information with zlib" 331 depends on $(cc-option,-gz=zlib) 332 depends on $(ld-option,--compress-debug-sections=zlib) 333 help 334 Compress the debug information using zlib. Requires GCC 5.0+ or Clang 335 5.0+, binutils 2.26+, and zlib. 336 337 Users of dpkg-deb via scripts/package/builddeb may find an increase in 338 size of their debug .deb packages with this config set, due to the 339 debug info being compressed with zlib, then the object files being 340 recompressed with a different compression scheme. But this is still 341 preferable to setting $KDEB_COMPRESS to "none" which would be even 342 larger. 343 344config DEBUG_INFO_COMPRESSED_ZSTD 345 bool "Compress debugging information with zstd" 346 depends on $(cc-option,-gz=zstd) 347 depends on $(ld-option,--compress-debug-sections=zstd) 348 help 349 Compress the debug information using zstd. This may provide better 350 compression than zlib, for about the same time costs, but requires newer 351 toolchain support. Requires GCC 13.0+ or Clang 16.0+, binutils 2.40+, and 352 zstd. 353 354endchoice # "Compressed Debug information" 355 356config DEBUG_INFO_SPLIT 357 bool "Produce split debuginfo in .dwo files" 358 depends on $(cc-option,-gsplit-dwarf) 359 # RISC-V linker relaxation + -gsplit-dwarf has issues with LLVM and GCC 360 # prior to 12.x: 361 # https://github.com/llvm/llvm-project/issues/56642 362 # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99090 363 depends on !RISCV || GCC_VERSION >= 120000 364 help 365 Generate debug info into separate .dwo files. This significantly 366 reduces the build directory size for builds with DEBUG_INFO, 367 because it stores the information only once on disk in .dwo 368 files instead of multiple times in object files and executables. 369 In addition the debug information is also compressed. 370 371 Requires recent gcc (4.7+) and recent gdb/binutils. 372 Any tool that packages or reads debug information would need 373 to know about the .dwo files and include them. 374 Incompatible with older versions of ccache. 375 376config DEBUG_INFO_BTF 377 bool "Generate BTF typeinfo" 378 depends on !DEBUG_INFO_SPLIT && !DEBUG_INFO_REDUCED 379 depends on !GCC_PLUGIN_RANDSTRUCT || COMPILE_TEST 380 depends on BPF_SYSCALL 381 depends on !DEBUG_INFO_DWARF5 || PAHOLE_VERSION >= 121 382 help 383 Generate deduplicated BTF type information from DWARF debug info. 384 Turning this on expects presence of pahole tool, which will convert 385 DWARF type info into equivalent deduplicated BTF type info. 386 387config PAHOLE_HAS_SPLIT_BTF 388 def_bool PAHOLE_VERSION >= 119 389 390config PAHOLE_HAS_BTF_TAG 391 def_bool PAHOLE_VERSION >= 123 392 depends on CC_IS_CLANG 393 help 394 Decide whether pahole emits btf_tag attributes (btf_type_tag and 395 btf_decl_tag) or not. Currently only clang compiler implements 396 these attributes, so make the config depend on CC_IS_CLANG. 397 398config PAHOLE_HAS_LANG_EXCLUDE 399 def_bool PAHOLE_VERSION >= 124 400 help 401 Support for the --lang_exclude flag which makes pahole exclude 402 compilation units from the supplied language. Used in Kbuild to 403 omit Rust CUs which are not supported in version 1.24 of pahole, 404 otherwise it would emit malformed kernel and module binaries when 405 using DEBUG_INFO_BTF_MODULES. 406 407config DEBUG_INFO_BTF_MODULES 408 def_bool y 409 depends on DEBUG_INFO_BTF && MODULES && PAHOLE_HAS_SPLIT_BTF 410 help 411 Generate compact split BTF type information for kernel modules. 412 413config MODULE_ALLOW_BTF_MISMATCH 414 bool "Allow loading modules with non-matching BTF type info" 415 depends on DEBUG_INFO_BTF_MODULES 416 help 417 For modules whose split BTF does not match vmlinux, load without 418 BTF rather than refusing to load. The default behavior with 419 module BTF enabled is to reject modules with such mismatches; 420 this option will still load module BTF where possible but ignore 421 it when a mismatch is found. 422 423config GDB_SCRIPTS 424 bool "Provide GDB scripts for kernel debugging" 425 help 426 This creates the required links to GDB helper scripts in the 427 build directory. If you load vmlinux into gdb, the helper 428 scripts will be automatically imported by gdb as well, and 429 additional functions are available to analyze a Linux kernel 430 instance. See Documentation/dev-tools/gdb-kernel-debugging.rst 431 for further details. 432 433endif # DEBUG_INFO 434 435config FRAME_WARN 436 int "Warn for stack frames larger than" 437 range 0 8192 438 default 0 if KMSAN 439 default 2048 if GCC_PLUGIN_LATENT_ENTROPY 440 default 2048 if PARISC 441 default 1536 if (!64BIT && XTENSA) 442 default 1280 if KASAN && !64BIT 443 default 1024 if !64BIT 444 default 2048 if 64BIT 445 help 446 Tell the compiler to warn at build time for stack frames larger than this. 447 Setting this too low will cause a lot of warnings. 448 Setting it to 0 disables the warning. 449 450config STRIP_ASM_SYMS 451 bool "Strip assembler-generated symbols during link" 452 default n 453 help 454 Strip internal assembler-generated symbols during a link (symbols 455 that look like '.Lxxx') so they don't pollute the output of 456 get_wchan() and suchlike. 457 458config READABLE_ASM 459 bool "Generate readable assembler code" 460 depends on DEBUG_KERNEL 461 depends on CC_IS_GCC 462 help 463 Disable some compiler optimizations that tend to generate human unreadable 464 assembler output. This may make the kernel slightly slower, but it helps 465 to keep kernel developers who have to stare a lot at assembler listings 466 sane. 467 468config HEADERS_INSTALL 469 bool "Install uapi headers to usr/include" 470 depends on !UML 471 help 472 This option will install uapi headers (headers exported to user-space) 473 into the usr/include directory for use during the kernel build. 474 This is unneeded for building the kernel itself, but needed for some 475 user-space program samples. It is also needed by some features such 476 as uapi header sanity checks. 477 478config DEBUG_SECTION_MISMATCH 479 bool "Enable full Section mismatch analysis" 480 depends on CC_IS_GCC 481 help 482 The section mismatch analysis checks if there are illegal 483 references from one section to another section. 484 During linktime or runtime, some sections are dropped; 485 any use of code/data previously in these sections would 486 most likely result in an oops. 487 In the code, functions and variables are annotated with 488 __init,, etc. (see the full list in include/linux/init.h), 489 which results in the code/data being placed in specific sections. 490 The section mismatch analysis is always performed after a full 491 kernel build, and enabling this option causes the following 492 additional step to occur: 493 - Add the option -fno-inline-functions-called-once to gcc commands. 494 When inlining a function annotated with __init in a non-init 495 function, we would lose the section information and thus 496 the analysis would not catch the illegal reference. 497 This option tells gcc to inline less (but it does result in 498 a larger kernel). 499 500config SECTION_MISMATCH_WARN_ONLY 501 bool "Make section mismatch errors non-fatal" 502 default y 503 help 504 If you say N here, the build process will fail if there are any 505 section mismatch, instead of just throwing warnings. 506 507 If unsure, say Y. 508 509config DEBUG_FORCE_FUNCTION_ALIGN_64B 510 bool "Force all function address 64B aligned" 511 depends on EXPERT && (X86_64 || ARM64 || PPC32 || PPC64 || ARC || RISCV || S390) 512 select FUNCTION_ALIGNMENT_64B 513 help 514 There are cases that a commit from one domain changes the function 515 address alignment of other domains, and cause magic performance 516 bump (regression or improvement). Enable this option will help to 517 verify if the bump is caused by function alignment changes, while 518 it will slightly increase the kernel size and affect icache usage. 519 520 It is mainly for debug and performance tuning use. 521 522# 523# Select this config option from the architecture Kconfig, if it 524# is preferred to always offer frame pointers as a config 525# option on the architecture (regardless of KERNEL_DEBUG): 526# 527config ARCH_WANT_FRAME_POINTERS 528 bool 529 530config FRAME_POINTER 531 bool "Compile the kernel with frame pointers" 532 depends on DEBUG_KERNEL && (M68K || UML || SUPERH) || ARCH_WANT_FRAME_POINTERS 533 default y if (DEBUG_INFO && UML) || ARCH_WANT_FRAME_POINTERS 534 help 535 If you say Y here the resulting kernel image will be slightly 536 larger and slower, but it gives very useful debugging information 537 in case of kernel bugs. (precise oopses/stacktraces/warnings) 538 539config OBJTOOL 540 bool 541 542config STACK_VALIDATION 543 bool "Compile-time stack metadata validation" 544 depends on HAVE_STACK_VALIDATION && UNWINDER_FRAME_POINTER 545 select OBJTOOL 546 default n 547 help 548 Validate frame pointer rules at compile-time. This helps ensure that 549 runtime stack traces are more reliable. 550 551 For more information, see 552 tools/objtool/Documentation/objtool.txt. 553 554config NOINSTR_VALIDATION 555 bool 556 depends on HAVE_NOINSTR_VALIDATION && DEBUG_ENTRY 557 select OBJTOOL 558 default y 559 560config VMLINUX_MAP 561 bool "Generate vmlinux.map file when linking" 562 depends on EXPERT 563 help 564 Selecting this option will pass "-Map=vmlinux.map" to ld 565 when linking vmlinux. That file can be useful for verifying 566 and debugging magic section games, and for seeing which 567 pieces of code get eliminated with 568 CONFIG_LD_DEAD_CODE_DATA_ELIMINATION. 569 570config DEBUG_FORCE_WEAK_PER_CPU 571 bool "Force weak per-cpu definitions" 572 depends on DEBUG_KERNEL 573 help 574 s390 and alpha require percpu variables in modules to be 575 defined weak to work around addressing range issue which 576 puts the following two restrictions on percpu variable 577 definitions. 578 579 1. percpu symbols must be unique whether static or not 580 2. percpu variables can't be defined inside a function 581 582 To ensure that generic code follows the above rules, this 583 option forces all percpu variables to be defined as weak. 584 585endmenu # "Compiler options" 586 587menu "Generic Kernel Debugging Instruments" 588 589config MAGIC_SYSRQ 590 bool "Magic SysRq key" 591 depends on !UML 592 help 593 If you say Y here, you will have some control over the system even 594 if the system crashes for example during kernel debugging (e.g., you 595 will be able to flush the buffer cache to disk, reboot the system 596 immediately or dump some status information). This is accomplished 597 by pressing various keys while holding SysRq (Alt+PrintScreen). It 598 also works on a serial console (on PC hardware at least), if you 599 send a BREAK and then within 5 seconds a command keypress. The 600 keys are documented in <file:Documentation/admin-guide/sysrq.rst>. 601 Don't say Y unless you really know what this hack does. 602 603config MAGIC_SYSRQ_DEFAULT_ENABLE 604 hex "Enable magic SysRq key functions by default" 605 depends on MAGIC_SYSRQ 606 default 0x1 607 help 608 Specifies which SysRq key functions are enabled by default. 609 This may be set to 1 or 0 to enable or disable them all, or 610 to a bitmask as described in Documentation/admin-guide/sysrq.rst. 611 612config MAGIC_SYSRQ_SERIAL 613 bool "Enable magic SysRq key over serial" 614 depends on MAGIC_SYSRQ 615 default y 616 help 617 Many embedded boards have a disconnected TTL level serial which can 618 generate some garbage that can lead to spurious false sysrq detects. 619 This option allows you to decide whether you want to enable the 620 magic SysRq key. 621 622config MAGIC_SYSRQ_SERIAL_SEQUENCE 623 string "Char sequence that enables magic SysRq over serial" 624 depends on MAGIC_SYSRQ_SERIAL 625 default "" 626 help 627 Specifies a sequence of characters that can follow BREAK to enable 628 SysRq on a serial console. 629 630 If unsure, leave an empty string and the option will not be enabled. 631 632config DEBUG_FS 633 bool "Debug Filesystem" 634 help 635 debugfs is a virtual file system that kernel developers use to put 636 debugging files into. Enable this option to be able to read and 637 write to these files. 638 639 For detailed documentation on the debugfs API, see 640 Documentation/filesystems/. 641 642 If unsure, say N. 643 644choice 645 prompt "Debugfs default access" 646 depends on DEBUG_FS 647 default DEBUG_FS_ALLOW_ALL 648 help 649 This selects the default access restrictions for debugfs. 650 It can be overridden with kernel command line option 651 debugfs=[on,no-mount,off]. The restrictions apply for API access 652 and filesystem registration. 653 654config DEBUG_FS_ALLOW_ALL 655 bool "Access normal" 656 help 657 No restrictions apply. Both API and filesystem registration 658 is on. This is the normal default operation. 659 660config DEBUG_FS_DISALLOW_MOUNT 661 bool "Do not register debugfs as filesystem" 662 help 663 The API is open but filesystem is not loaded. Clients can still do 664 their work and read with debug tools that do not need 665 debugfs filesystem. 666 667config DEBUG_FS_ALLOW_NONE 668 bool "No access" 669 help 670 Access is off. Clients get -PERM when trying to create nodes in 671 debugfs tree and debugfs is not registered as a filesystem. 672 Client can then back-off or continue without debugfs access. 673 674endchoice 675 676source "lib/Kconfig.kgdb" 677source "lib/Kconfig.ubsan" 678source "lib/Kconfig.kcsan" 679 680endmenu 681 682menu "Networking Debugging" 683 684source "net/Kconfig.debug" 685 686endmenu # "Networking Debugging" 687 688menu "Memory Debugging" 689 690source "mm/Kconfig.debug" 691 692config DEBUG_OBJECTS 693 bool "Debug object operations" 694 depends on DEBUG_KERNEL 695 help 696 If you say Y here, additional code will be inserted into the 697 kernel to track the life time of various objects and validate 698 the operations on those objects. 699 700config DEBUG_OBJECTS_SELFTEST 701 bool "Debug objects selftest" 702 depends on DEBUG_OBJECTS 703 help 704 This enables the selftest of the object debug code. 705 706config DEBUG_OBJECTS_FREE 707 bool "Debug objects in freed memory" 708 depends on DEBUG_OBJECTS 709 help 710 This enables checks whether a k/v free operation frees an area 711 which contains an object which has not been deactivated 712 properly. This can make kmalloc/kfree-intensive workloads 713 much slower. 714 715config DEBUG_OBJECTS_TIMERS 716 bool "Debug timer objects" 717 depends on DEBUG_OBJECTS 718 help 719 If you say Y here, additional code will be inserted into the 720 timer routines to track the life time of timer objects and 721 validate the timer operations. 722 723config DEBUG_OBJECTS_WORK 724 bool "Debug work objects" 725 depends on DEBUG_OBJECTS 726 help 727 If you say Y here, additional code will be inserted into the 728 work queue routines to track the life time of work objects and 729 validate the work operations. 730 731config DEBUG_OBJECTS_RCU_HEAD 732 bool "Debug RCU callbacks objects" 733 depends on DEBUG_OBJECTS 734 help 735 Enable this to turn on debugging of RCU list heads (call_rcu() usage). 736 737config DEBUG_OBJECTS_PERCPU_COUNTER 738 bool "Debug percpu counter objects" 739 depends on DEBUG_OBJECTS 740 help 741 If you say Y here, additional code will be inserted into the 742 percpu counter routines to track the life time of percpu counter 743 objects and validate the percpu counter operations. 744 745config DEBUG_OBJECTS_ENABLE_DEFAULT 746 int "debug_objects bootup default value (0-1)" 747 range 0 1 748 default "1" 749 depends on DEBUG_OBJECTS 750 help 751 Debug objects boot parameter default value 752 753config SHRINKER_DEBUG 754 bool "Enable shrinker debugging support" 755 depends on DEBUG_FS 756 help 757 Say Y to enable the shrinker debugfs interface which provides 758 visibility into the kernel memory shrinkers subsystem. 759 Disable it to avoid an extra memory footprint. 760 761config DEBUG_STACK_USAGE 762 bool "Stack utilization instrumentation" 763 depends on DEBUG_KERNEL 764 help 765 Enables the display of the minimum amount of free stack which each 766 task has ever had available in the sysrq-T and sysrq-P debug output. 767 768 This option will slow down process creation somewhat. 769 770config SCHED_STACK_END_CHECK 771 bool "Detect stack corruption on calls to schedule()" 772 depends on DEBUG_KERNEL 773 default n 774 help 775 This option checks for a stack overrun on calls to schedule(). 776 If the stack end location is found to be over written always panic as 777 the content of the corrupted region can no longer be trusted. 778 This is to ensure no erroneous behaviour occurs which could result in 779 data corruption or a sporadic crash at a later stage once the region 780 is examined. The runtime overhead introduced is minimal. 781 782config ARCH_HAS_DEBUG_VM_PGTABLE 783 bool 784 help 785 An architecture should select this when it can successfully 786 build and run DEBUG_VM_PGTABLE. 787 788config DEBUG_VM_IRQSOFF 789 def_bool DEBUG_VM && !PREEMPT_RT 790 791config DEBUG_VM 792 bool "Debug VM" 793 depends on DEBUG_KERNEL 794 help 795 Enable this to turn on extended checks in the virtual-memory system 796 that may impact performance. 797 798 If unsure, say N. 799 800config DEBUG_VM_SHOOT_LAZIES 801 bool "Debug MMU_LAZY_TLB_SHOOTDOWN implementation" 802 depends on DEBUG_VM 803 depends on MMU_LAZY_TLB_SHOOTDOWN 804 help 805 Enable additional IPIs that ensure lazy tlb mm references are removed 806 before the mm is freed. 807 808 If unsure, say N. 809 810config DEBUG_VM_MAPLE_TREE 811 bool "Debug VM maple trees" 812 depends on DEBUG_VM 813 select DEBUG_MAPLE_TREE 814 help 815 Enable VM maple tree debugging information and extra validations. 816 817 If unsure, say N. 818 819config DEBUG_VM_RB 820 bool "Debug VM red-black trees" 821 depends on DEBUG_VM 822 help 823 Enable VM red-black tree debugging information and extra validations. 824 825 If unsure, say N. 826 827config DEBUG_VM_PGFLAGS 828 bool "Debug page-flags operations" 829 depends on DEBUG_VM 830 help 831 Enables extra validation on page flags operations. 832 833 If unsure, say N. 834 835config DEBUG_VM_PGTABLE 836 bool "Debug arch page table for semantics compliance" 837 depends on MMU 838 depends on ARCH_HAS_DEBUG_VM_PGTABLE 839 default y if DEBUG_VM 840 help 841 This option provides a debug method which can be used to test 842 architecture page table helper functions on various platforms in 843 verifying if they comply with expected generic MM semantics. This 844 will help architecture code in making sure that any changes or 845 new additions of these helpers still conform to expected 846 semantics of the generic MM. Platforms will have to opt in for 847 this through ARCH_HAS_DEBUG_VM_PGTABLE. 848 849 If unsure, say N. 850 851config ARCH_HAS_DEBUG_VIRTUAL 852 bool 853 854config DEBUG_VIRTUAL 855 bool "Debug VM translations" 856 depends on DEBUG_KERNEL && ARCH_HAS_DEBUG_VIRTUAL 857 help 858 Enable some costly sanity checks in virtual to page code. This can 859 catch mistakes with virt_to_page() and friends. 860 861 If unsure, say N. 862 863config DEBUG_NOMMU_REGIONS 864 bool "Debug the global anon/private NOMMU mapping region tree" 865 depends on DEBUG_KERNEL && !MMU 866 help 867 This option causes the global tree of anonymous and private mapping 868 regions to be regularly checked for invalid topology. 869 870config DEBUG_MEMORY_INIT 871 bool "Debug memory initialisation" if EXPERT 872 default !EXPERT 873 help 874 Enable this for additional checks during memory initialisation. 875 The sanity checks verify aspects of the VM such as the memory model 876 and other information provided by the architecture. Verbose 877 information will be printed at KERN_DEBUG loglevel depending 878 on the mminit_loglevel= command-line option. 879 880 If unsure, say Y 881 882config MEMORY_NOTIFIER_ERROR_INJECT 883 tristate "Memory hotplug notifier error injection module" 884 depends on MEMORY_HOTPLUG && NOTIFIER_ERROR_INJECTION 885 help 886 This option provides the ability to inject artificial errors to 887 memory hotplug notifier chain callbacks. It is controlled through 888 debugfs interface under /sys/kernel/debug/notifier-error-inject/memory 889 890 If the notifier call chain should be failed with some events 891 notified, write the error code to "actions/<notifier event>/error". 892 893 Example: Inject memory hotplug offline error (-12 == -ENOMEM) 894 895 # cd /sys/kernel/debug/notifier-error-inject/memory 896 # echo -12 > actions/MEM_GOING_OFFLINE/error 897 # echo offline > /sys/devices/system/memory/memoryXXX/state 898 bash: echo: write error: Cannot allocate memory 899 900 To compile this code as a module, choose M here: the module will 901 be called memory-notifier-error-inject. 902 903 If unsure, say N. 904 905config DEBUG_PER_CPU_MAPS 906 bool "Debug access to per_cpu maps" 907 depends on DEBUG_KERNEL 908 depends on SMP 909 help 910 Say Y to verify that the per_cpu map being accessed has 911 been set up. This adds a fair amount of code to kernel memory 912 and decreases performance. 913 914 Say N if unsure. 915 916config DEBUG_KMAP_LOCAL 917 bool "Debug kmap_local temporary mappings" 918 depends on DEBUG_KERNEL && KMAP_LOCAL 919 help 920 This option enables additional error checking for the kmap_local 921 infrastructure. Disable for production use. 922 923config ARCH_SUPPORTS_KMAP_LOCAL_FORCE_MAP 924 bool 925 926config DEBUG_KMAP_LOCAL_FORCE_MAP 927 bool "Enforce kmap_local temporary mappings" 928 depends on DEBUG_KERNEL && ARCH_SUPPORTS_KMAP_LOCAL_FORCE_MAP 929 select KMAP_LOCAL 930 select DEBUG_KMAP_LOCAL 931 help 932 This option enforces temporary mappings through the kmap_local 933 mechanism for non-highmem pages and on non-highmem systems. 934 Disable this for production systems! 935 936config DEBUG_HIGHMEM 937 bool "Highmem debugging" 938 depends on DEBUG_KERNEL && HIGHMEM 939 select DEBUG_KMAP_LOCAL_FORCE_MAP if ARCH_SUPPORTS_KMAP_LOCAL_FORCE_MAP 940 select DEBUG_KMAP_LOCAL 941 help 942 This option enables additional error checking for high memory 943 systems. Disable for production systems. 944 945config HAVE_DEBUG_STACKOVERFLOW 946 bool 947 948config DEBUG_STACKOVERFLOW 949 bool "Check for stack overflows" 950 depends on DEBUG_KERNEL && HAVE_DEBUG_STACKOVERFLOW 951 help 952 Say Y here if you want to check for overflows of kernel, IRQ 953 and exception stacks (if your architecture uses them). This 954 option will show detailed messages if free stack space drops 955 below a certain limit. 956 957 These kinds of bugs usually occur when call-chains in the 958 kernel get too deep, especially when interrupts are 959 involved. 960 961 Use this in cases where you see apparently random memory 962 corruption, especially if it appears in 'struct thread_info' 963 964 If in doubt, say "N". 965 966source "lib/Kconfig.kasan" 967source "lib/Kconfig.kfence" 968source "lib/Kconfig.kmsan" 969 970endmenu # "Memory Debugging" 971 972config DEBUG_SHIRQ 973 bool "Debug shared IRQ handlers" 974 depends on DEBUG_KERNEL 975 help 976 Enable this to generate a spurious interrupt just before a shared 977 interrupt handler is deregistered (generating one when registering 978 is currently disabled). Drivers need to handle this correctly. Some 979 don't and need to be caught. 980 981menu "Debug Oops, Lockups and Hangs" 982 983config PANIC_ON_OOPS 984 bool "Panic on Oops" 985 help 986 Say Y here to enable the kernel to panic when it oopses. This 987 has the same effect as setting oops=panic on the kernel command 988 line. 989 990 This feature is useful to ensure that the kernel does not do 991 anything erroneous after an oops which could result in data 992 corruption or other issues. 993 994 Say N if unsure. 995 996config PANIC_ON_OOPS_VALUE 997 int 998 range 0 1 999 default 0 if !PANIC_ON_OOPS 1000 default 1 if PANIC_ON_OOPS 1001 1002config PANIC_TIMEOUT 1003 int "panic timeout" 1004 default 0 1005 help 1006 Set the timeout value (in seconds) until a reboot occurs when 1007 the kernel panics. If n = 0, then we wait forever. A timeout 1008 value n > 0 will wait n seconds before rebooting, while a timeout 1009 value n < 0 will reboot immediately. 1010 1011config LOCKUP_DETECTOR 1012 bool 1013 1014config SOFTLOCKUP_DETECTOR 1015 bool "Detect Soft Lockups" 1016 depends on DEBUG_KERNEL && !S390 1017 select LOCKUP_DETECTOR 1018 help 1019 Say Y here to enable the kernel to act as a watchdog to detect 1020 soft lockups. 1021 1022 Softlockups are bugs that cause the kernel to loop in kernel 1023 mode for more than 20 seconds, without giving other tasks a 1024 chance to run. The current stack trace is displayed upon 1025 detection and the system will stay locked up. 1026 1027config BOOTPARAM_SOFTLOCKUP_PANIC 1028 bool "Panic (Reboot) On Soft Lockups" 1029 depends on SOFTLOCKUP_DETECTOR 1030 help 1031 Say Y here to enable the kernel to panic on "soft lockups", 1032 which are bugs that cause the kernel to loop in kernel 1033 mode for more than 20 seconds (configurable using the watchdog_thresh 1034 sysctl), without giving other tasks a chance to run. 1035 1036 The panic can be used in combination with panic_timeout, 1037 to cause the system to reboot automatically after a 1038 lockup has been detected. This feature is useful for 1039 high-availability systems that have uptime guarantees and 1040 where a lockup must be resolved ASAP. 1041 1042 Say N if unsure. 1043 1044config HAVE_HARDLOCKUP_DETECTOR_BUDDY 1045 bool 1046 depends on SMP 1047 default y 1048 1049# 1050# Global switch whether to build a hardlockup detector at all. It is available 1051# only when the architecture supports at least one implementation. There are 1052# two exceptions. The hardlockup detector is never enabled on: 1053# 1054# s390: it reported many false positives there 1055# 1056# sparc64: has a custom implementation which is not using the common 1057# hardlockup command line options and sysctl interface. 1058# 1059config HARDLOCKUP_DETECTOR 1060 bool "Detect Hard Lockups" 1061 depends on DEBUG_KERNEL && !S390 && !HARDLOCKUP_DETECTOR_SPARC64 1062 depends on HAVE_HARDLOCKUP_DETECTOR_PERF || HAVE_HARDLOCKUP_DETECTOR_BUDDY || HAVE_HARDLOCKUP_DETECTOR_ARCH 1063 imply HARDLOCKUP_DETECTOR_PERF 1064 imply HARDLOCKUP_DETECTOR_BUDDY 1065 imply HARDLOCKUP_DETECTOR_ARCH 1066 select LOCKUP_DETECTOR 1067 1068 help 1069 Say Y here to enable the kernel to act as a watchdog to detect 1070 hard lockups. 1071 1072 Hardlockups are bugs that cause the CPU to loop in kernel mode 1073 for more than 10 seconds, without letting other interrupts have a 1074 chance to run. The current stack trace is displayed upon detection 1075 and the system will stay locked up. 1076 1077# 1078# Note that arch-specific variants are always preferred. 1079# 1080config HARDLOCKUP_DETECTOR_PREFER_BUDDY 1081 bool "Prefer the buddy CPU hardlockup detector" 1082 depends on HARDLOCKUP_DETECTOR 1083 depends on HAVE_HARDLOCKUP_DETECTOR_PERF && HAVE_HARDLOCKUP_DETECTOR_BUDDY 1084 depends on !HAVE_HARDLOCKUP_DETECTOR_ARCH 1085 help 1086 Say Y here to prefer the buddy hardlockup detector over the perf one. 1087 1088 With the buddy detector, each CPU uses its softlockup hrtimer 1089 to check that the next CPU is processing hrtimer interrupts by 1090 verifying that a counter is increasing. 1091 1092 This hardlockup detector is useful on systems that don't have 1093 an arch-specific hardlockup detector or if resources needed 1094 for the hardlockup detector are better used for other things. 1095 1096config HARDLOCKUP_DETECTOR_PERF 1097 bool 1098 depends on HARDLOCKUP_DETECTOR 1099 depends on HAVE_HARDLOCKUP_DETECTOR_PERF && !HARDLOCKUP_DETECTOR_PREFER_BUDDY 1100 depends on !HAVE_HARDLOCKUP_DETECTOR_ARCH 1101 select HARDLOCKUP_DETECTOR_COUNTS_HRTIMER 1102 1103config HARDLOCKUP_DETECTOR_BUDDY 1104 bool 1105 depends on HARDLOCKUP_DETECTOR 1106 depends on HAVE_HARDLOCKUP_DETECTOR_BUDDY 1107 depends on !HAVE_HARDLOCKUP_DETECTOR_PERF || HARDLOCKUP_DETECTOR_PREFER_BUDDY 1108 depends on !HAVE_HARDLOCKUP_DETECTOR_ARCH 1109 select HARDLOCKUP_DETECTOR_COUNTS_HRTIMER 1110 1111config HARDLOCKUP_DETECTOR_ARCH 1112 bool 1113 depends on HARDLOCKUP_DETECTOR 1114 depends on HAVE_HARDLOCKUP_DETECTOR_ARCH 1115 help 1116 The arch-specific implementation of the hardlockup detector will 1117 be used. 1118 1119# 1120# Both the "perf" and "buddy" hardlockup detectors count hrtimer 1121# interrupts. This config enables functions managing this common code. 1122# 1123config HARDLOCKUP_DETECTOR_COUNTS_HRTIMER 1124 bool 1125 select SOFTLOCKUP_DETECTOR 1126 1127# 1128# Enables a timestamp based low pass filter to compensate for perf based 1129# hard lockup detection which runs too fast due to turbo modes. 1130# 1131config HARDLOCKUP_CHECK_TIMESTAMP 1132 bool 1133 1134config BOOTPARAM_HARDLOCKUP_PANIC 1135 bool "Panic (Reboot) On Hard Lockups" 1136 depends on HARDLOCKUP_DETECTOR 1137 help 1138 Say Y here to enable the kernel to panic on "hard lockups", 1139 which are bugs that cause the kernel to loop in kernel 1140 mode with interrupts disabled for more than 10 seconds (configurable 1141 using the watchdog_thresh sysctl). 1142 1143 Say N if unsure. 1144 1145config DETECT_HUNG_TASK 1146 bool "Detect Hung Tasks" 1147 depends on DEBUG_KERNEL 1148 default SOFTLOCKUP_DETECTOR 1149 help 1150 Say Y here to enable the kernel to detect "hung tasks", 1151 which are bugs that cause the task to be stuck in 1152 uninterruptible "D" state indefinitely. 1153 1154 When a hung task is detected, the kernel will print the 1155 current stack trace (which you should report), but the 1156 task will stay in uninterruptible state. If lockdep is 1157 enabled then all held locks will also be reported. This 1158 feature has negligible overhead. 1159 1160config DEFAULT_HUNG_TASK_TIMEOUT 1161 int "Default timeout for hung task detection (in seconds)" 1162 depends on DETECT_HUNG_TASK 1163 default 120 1164 help 1165 This option controls the default timeout (in seconds) used 1166 to determine when a task has become non-responsive and should 1167 be considered hung. 1168 1169 It can be adjusted at runtime via the kernel.hung_task_timeout_secs 1170 sysctl or by writing a value to 1171 /proc/sys/kernel/hung_task_timeout_secs. 1172 1173 A timeout of 0 disables the check. The default is two minutes. 1174 Keeping the default should be fine in most cases. 1175 1176config BOOTPARAM_HUNG_TASK_PANIC 1177 bool "Panic (Reboot) On Hung Tasks" 1178 depends on DETECT_HUNG_TASK 1179 help 1180 Say Y here to enable the kernel to panic on "hung tasks", 1181 which are bugs that cause the kernel to leave a task stuck 1182 in uninterruptible "D" state. 1183 1184 The panic can be used in combination with panic_timeout, 1185 to cause the system to reboot automatically after a 1186 hung task has been detected. This feature is useful for 1187 high-availability systems that have uptime guarantees and 1188 where a hung tasks must be resolved ASAP. 1189 1190 Say N if unsure. 1191 1192config WQ_WATCHDOG 1193 bool "Detect Workqueue Stalls" 1194 depends on DEBUG_KERNEL 1195 help 1196 Say Y here to enable stall detection on workqueues. If a 1197 worker pool doesn't make forward progress on a pending work 1198 item for over a given amount of time, 30s by default, a 1199 warning message is printed along with dump of workqueue 1200 state. This can be configured through kernel parameter 1201 "workqueue.watchdog_thresh" and its sysfs counterpart. 1202 1203config WQ_CPU_INTENSIVE_REPORT 1204 bool "Report per-cpu work items which hog CPU for too long" 1205 depends on DEBUG_KERNEL 1206 help 1207 Say Y here to enable reporting of concurrency-managed per-cpu work 1208 items that hog CPUs for longer than 1209 workqueue.cpu_intensive_thresh_us. Workqueue automatically 1210 detects and excludes them from concurrency management to prevent 1211 them from stalling other per-cpu work items. Occassional 1212 triggering may not necessarily indicate a problem. Repeated 1213 triggering likely indicates that the work item should be switched 1214 to use an unbound workqueue. 1215 1216config TEST_LOCKUP 1217 tristate "Test module to generate lockups" 1218 depends on m 1219 help 1220 This builds the "test_lockup" module that helps to make sure 1221 that watchdogs and lockup detectors are working properly. 1222 1223 Depending on module parameters it could emulate soft or hard 1224 lockup, "hung task", or locking arbitrary lock for a long time. 1225 Also it could generate series of lockups with cooling-down periods. 1226 1227 If unsure, say N. 1228 1229endmenu # "Debug lockups and hangs" 1230 1231menu "Scheduler Debugging" 1232 1233config SCHED_DEBUG 1234 bool "Collect scheduler debugging info" 1235 depends on DEBUG_KERNEL && DEBUG_FS 1236 default y 1237 help 1238 If you say Y here, the /sys/kernel/debug/sched file will be provided 1239 that can help debug the scheduler. The runtime overhead of this 1240 option is minimal. 1241 1242config SCHED_INFO 1243 bool 1244 default n 1245 1246config SCHEDSTATS 1247 bool "Collect scheduler statistics" 1248 depends on DEBUG_KERNEL && PROC_FS 1249 select SCHED_INFO 1250 help 1251 If you say Y here, additional code will be inserted into the 1252 scheduler and related routines to collect statistics about 1253 scheduler behavior and provide them in /proc/schedstat. These 1254 stats may be useful for both tuning and debugging the scheduler 1255 If you aren't debugging the scheduler or trying to tune a specific 1256 application, you can say N to avoid the very slight overhead 1257 this adds. 1258 1259endmenu 1260 1261config DEBUG_TIMEKEEPING 1262 bool "Enable extra timekeeping sanity checking" 1263 help 1264 This option will enable additional timekeeping sanity checks 1265 which may be helpful when diagnosing issues where timekeeping 1266 problems are suspected. 1267 1268 This may include checks in the timekeeping hotpaths, so this 1269 option may have a (very small) performance impact to some 1270 workloads. 1271 1272 If unsure, say N. 1273 1274config DEBUG_PREEMPT 1275 bool "Debug preemptible kernel" 1276 depends on DEBUG_KERNEL && PREEMPTION && TRACE_IRQFLAGS_SUPPORT 1277 help 1278 If you say Y here then the kernel will use a debug variant of the 1279 commonly used smp_processor_id() function and will print warnings 1280 if kernel code uses it in a preemption-unsafe way. Also, the kernel 1281 will detect preemption count underflows. 1282 1283 This option has potential to introduce high runtime overhead, 1284 depending on workload as it triggers debugging routines for each 1285 this_cpu operation. It should only be used for debugging purposes. 1286 1287menu "Lock Debugging (spinlocks, mutexes, etc...)" 1288 1289config LOCK_DEBUGGING_SUPPORT 1290 bool 1291 depends on TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT 1292 default y 1293 1294config PROVE_LOCKING 1295 bool "Lock debugging: prove locking correctness" 1296 depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT 1297 select LOCKDEP 1298 select DEBUG_SPINLOCK 1299 select DEBUG_MUTEXES if !PREEMPT_RT 1300 select DEBUG_RT_MUTEXES if RT_MUTEXES 1301 select DEBUG_RWSEMS 1302 select DEBUG_WW_MUTEX_SLOWPATH 1303 select DEBUG_LOCK_ALLOC 1304 select PREEMPT_COUNT if !ARCH_NO_PREEMPT 1305 select TRACE_IRQFLAGS 1306 default n 1307 help 1308 This feature enables the kernel to prove that all locking 1309 that occurs in the kernel runtime is mathematically 1310 correct: that under no circumstance could an arbitrary (and 1311 not yet triggered) combination of observed locking 1312 sequences (on an arbitrary number of CPUs, running an 1313 arbitrary number of tasks and interrupt contexts) cause a 1314 deadlock. 1315 1316 In short, this feature enables the kernel to report locking 1317 related deadlocks before they actually occur. 1318 1319 The proof does not depend on how hard and complex a 1320 deadlock scenario would be to trigger: how many 1321 participant CPUs, tasks and irq-contexts would be needed 1322 for it to trigger. The proof also does not depend on 1323 timing: if a race and a resulting deadlock is possible 1324 theoretically (no matter how unlikely the race scenario 1325 is), it will be proven so and will immediately be 1326 reported by the kernel (once the event is observed that 1327 makes the deadlock theoretically possible). 1328 1329 If a deadlock is impossible (i.e. the locking rules, as 1330 observed by the kernel, are mathematically correct), the 1331 kernel reports nothing. 1332 1333 NOTE: this feature can also be enabled for rwlocks, mutexes 1334 and rwsems - in which case all dependencies between these 1335 different locking variants are observed and mapped too, and 1336 the proof of observed correctness is also maintained for an 1337 arbitrary combination of these separate locking variants. 1338 1339 For more details, see Documentation/locking/lockdep-design.rst. 1340 1341config PROVE_RAW_LOCK_NESTING 1342 bool "Enable raw_spinlock - spinlock nesting checks" 1343 depends on PROVE_LOCKING 1344 default n 1345 help 1346 Enable the raw_spinlock vs. spinlock nesting checks which ensure 1347 that the lock nesting rules for PREEMPT_RT enabled kernels are 1348 not violated. 1349 1350 NOTE: There are known nesting problems. So if you enable this 1351 option expect lockdep splats until these problems have been fully 1352 addressed which is work in progress. This config switch allows to 1353 identify and analyze these problems. It will be removed and the 1354 check permanently enabled once the main issues have been fixed. 1355 1356 If unsure, select N. 1357 1358config LOCK_STAT 1359 bool "Lock usage statistics" 1360 depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT 1361 select LOCKDEP 1362 select DEBUG_SPINLOCK 1363 select DEBUG_MUTEXES if !PREEMPT_RT 1364 select DEBUG_RT_MUTEXES if RT_MUTEXES 1365 select DEBUG_LOCK_ALLOC 1366 default n 1367 help 1368 This feature enables tracking lock contention points 1369 1370 For more details, see Documentation/locking/lockstat.rst 1371 1372 This also enables lock events required by "perf lock", 1373 subcommand of perf. 1374 If you want to use "perf lock", you also need to turn on 1375 CONFIG_EVENT_TRACING. 1376 1377 CONFIG_LOCK_STAT defines "contended" and "acquired" lock events. 1378 (CONFIG_LOCKDEP defines "acquire" and "release" events.) 1379 1380config DEBUG_RT_MUTEXES 1381 bool "RT Mutex debugging, deadlock detection" 1382 depends on DEBUG_KERNEL && RT_MUTEXES 1383 help 1384 This allows rt mutex semantics violations and rt mutex related 1385 deadlocks (lockups) to be detected and reported automatically. 1386 1387config DEBUG_SPINLOCK 1388 bool "Spinlock and rw-lock debugging: basic checks" 1389 depends on DEBUG_KERNEL 1390 select UNINLINE_SPIN_UNLOCK 1391 help 1392 Say Y here and build SMP to catch missing spinlock initialization 1393 and certain other kinds of spinlock errors commonly made. This is 1394 best used in conjunction with the NMI watchdog so that spinlock 1395 deadlocks are also debuggable. 1396 1397config DEBUG_MUTEXES 1398 bool "Mutex debugging: basic checks" 1399 depends on DEBUG_KERNEL && !PREEMPT_RT 1400 help 1401 This feature allows mutex semantics violations to be detected and 1402 reported. 1403 1404config DEBUG_WW_MUTEX_SLOWPATH 1405 bool "Wait/wound mutex debugging: Slowpath testing" 1406 depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT 1407 select DEBUG_LOCK_ALLOC 1408 select DEBUG_SPINLOCK 1409 select DEBUG_MUTEXES if !PREEMPT_RT 1410 select DEBUG_RT_MUTEXES if PREEMPT_RT 1411 help 1412 This feature enables slowpath testing for w/w mutex users by 1413 injecting additional -EDEADLK wound/backoff cases. Together with 1414 the full mutex checks enabled with (CONFIG_PROVE_LOCKING) this 1415 will test all possible w/w mutex interface abuse with the 1416 exception of simply not acquiring all the required locks. 1417 Note that this feature can introduce significant overhead, so 1418 it really should not be enabled in a production or distro kernel, 1419 even a debug kernel. If you are a driver writer, enable it. If 1420 you are a distro, do not. 1421 1422config DEBUG_RWSEMS 1423 bool "RW Semaphore debugging: basic checks" 1424 depends on DEBUG_KERNEL 1425 help 1426 This debugging feature allows mismatched rw semaphore locks 1427 and unlocks to be detected and reported. 1428 1429config DEBUG_LOCK_ALLOC 1430 bool "Lock debugging: detect incorrect freeing of live locks" 1431 depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT 1432 select DEBUG_SPINLOCK 1433 select DEBUG_MUTEXES if !PREEMPT_RT 1434 select DEBUG_RT_MUTEXES if RT_MUTEXES 1435 select LOCKDEP 1436 help 1437 This feature will check whether any held lock (spinlock, rwlock, 1438 mutex or rwsem) is incorrectly freed by the kernel, via any of the 1439 memory-freeing routines (kfree(), kmem_cache_free(), free_pages(), 1440 vfree(), etc.), whether a live lock is incorrectly reinitialized via 1441 spin_lock_init()/mutex_init()/etc., or whether there is any lock 1442 held during task exit. 1443 1444config LOCKDEP 1445 bool 1446 depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT 1447 select STACKTRACE 1448 select KALLSYMS 1449 select KALLSYMS_ALL 1450 1451config LOCKDEP_SMALL 1452 bool 1453 1454config LOCKDEP_BITS 1455 int "Bitsize for MAX_LOCKDEP_ENTRIES" 1456 depends on LOCKDEP && !LOCKDEP_SMALL 1457 range 10 30 1458 default 15 1459 help 1460 Try increasing this value if you hit "BUG: MAX_LOCKDEP_ENTRIES too low!" message. 1461 1462config LOCKDEP_CHAINS_BITS 1463 int "Bitsize for MAX_LOCKDEP_CHAINS" 1464 depends on LOCKDEP && !LOCKDEP_SMALL 1465 range 10 30 1466 default 16 1467 help 1468 Try increasing this value if you hit "BUG: MAX_LOCKDEP_CHAINS too low!" message. 1469 1470config LOCKDEP_STACK_TRACE_BITS 1471 int "Bitsize for MAX_STACK_TRACE_ENTRIES" 1472 depends on LOCKDEP && !LOCKDEP_SMALL 1473 range 10 30 1474 default 19 1475 help 1476 Try increasing this value if you hit "BUG: MAX_STACK_TRACE_ENTRIES too low!" message. 1477 1478config LOCKDEP_STACK_TRACE_HASH_BITS 1479 int "Bitsize for STACK_TRACE_HASH_SIZE" 1480 depends on LOCKDEP && !LOCKDEP_SMALL 1481 range 10 30 1482 default 14 1483 help 1484 Try increasing this value if you need large STACK_TRACE_HASH_SIZE. 1485 1486config LOCKDEP_CIRCULAR_QUEUE_BITS 1487 int "Bitsize for elements in circular_queue struct" 1488 depends on LOCKDEP 1489 range 10 30 1490 default 12 1491 help 1492 Try increasing this value if you hit "lockdep bfs error:-1" warning due to __cq_enqueue() failure. 1493 1494config DEBUG_LOCKDEP 1495 bool "Lock dependency engine debugging" 1496 depends on DEBUG_KERNEL && LOCKDEP 1497 select DEBUG_IRQFLAGS 1498 help 1499 If you say Y here, the lock dependency engine will do 1500 additional runtime checks to debug itself, at the price 1501 of more runtime overhead. 1502 1503config DEBUG_ATOMIC_SLEEP 1504 bool "Sleep inside atomic section checking" 1505 select PREEMPT_COUNT 1506 depends on DEBUG_KERNEL 1507 depends on !ARCH_NO_PREEMPT 1508 help 1509 If you say Y here, various routines which may sleep will become very 1510 noisy if they are called inside atomic sections: when a spinlock is 1511 held, inside an rcu read side critical section, inside preempt disabled 1512 sections, inside an interrupt, etc... 1513 1514config DEBUG_LOCKING_API_SELFTESTS 1515 bool "Locking API boot-time self-tests" 1516 depends on DEBUG_KERNEL 1517 help 1518 Say Y here if you want the kernel to run a short self-test during 1519 bootup. The self-test checks whether common types of locking bugs 1520 are detected by debugging mechanisms or not. (if you disable 1521 lock debugging then those bugs won't be detected of course.) 1522 The following locking APIs are covered: spinlocks, rwlocks, 1523 mutexes and rwsems. 1524 1525config LOCK_TORTURE_TEST 1526 tristate "torture tests for locking" 1527 depends on DEBUG_KERNEL 1528 select TORTURE_TEST 1529 help 1530 This option provides a kernel module that runs torture tests 1531 on kernel locking primitives. The kernel module may be built 1532 after the fact on the running kernel to be tested, if desired. 1533 1534 Say Y here if you want kernel locking-primitive torture tests 1535 to be built into the kernel. 1536 Say M if you want these torture tests to build as a module. 1537 Say N if you are unsure. 1538 1539config WW_MUTEX_SELFTEST 1540 tristate "Wait/wound mutex selftests" 1541 help 1542 This option provides a kernel module that runs tests on the 1543 on the struct ww_mutex locking API. 1544 1545 It is recommended to enable DEBUG_WW_MUTEX_SLOWPATH in conjunction 1546 with this test harness. 1547 1548 Say M if you want these self tests to build as a module. 1549 Say N if you are unsure. 1550 1551config SCF_TORTURE_TEST 1552 tristate "torture tests for smp_call_function*()" 1553 depends on DEBUG_KERNEL 1554 select TORTURE_TEST 1555 help 1556 This option provides a kernel module that runs torture tests 1557 on the smp_call_function() family of primitives. The kernel 1558 module may be built after the fact on the running kernel to 1559 be tested, if desired. 1560 1561config CSD_LOCK_WAIT_DEBUG 1562 bool "Debugging for csd_lock_wait(), called from smp_call_function*()" 1563 depends on DEBUG_KERNEL 1564 depends on 64BIT 1565 default n 1566 help 1567 This option enables debug prints when CPUs are slow to respond 1568 to the smp_call_function*() IPI wrappers. These debug prints 1569 include the IPI handler function currently executing (if any) 1570 and relevant stack traces. 1571 1572config CSD_LOCK_WAIT_DEBUG_DEFAULT 1573 bool "Default csd_lock_wait() debugging on at boot time" 1574 depends on CSD_LOCK_WAIT_DEBUG 1575 depends on 64BIT 1576 default n 1577 help 1578 This option causes the csdlock_debug= kernel boot parameter to 1579 default to 1 (basic debugging) instead of 0 (no debugging). 1580 1581endmenu # lock debugging 1582 1583config TRACE_IRQFLAGS 1584 depends on TRACE_IRQFLAGS_SUPPORT 1585 bool 1586 help 1587 Enables hooks to interrupt enabling and disabling for 1588 either tracing or lock debugging. 1589 1590config TRACE_IRQFLAGS_NMI 1591 def_bool y 1592 depends on TRACE_IRQFLAGS 1593 depends on TRACE_IRQFLAGS_NMI_SUPPORT 1594 1595config NMI_CHECK_CPU 1596 bool "Debugging for CPUs failing to respond to backtrace requests" 1597 depends on DEBUG_KERNEL 1598 depends on X86 1599 default n 1600 help 1601 Enables debug prints when a CPU fails to respond to a given 1602 backtrace NMI. These prints provide some reasons why a CPU 1603 might legitimately be failing to respond, for example, if it 1604 is offline of if ignore_nmis is set. 1605 1606config DEBUG_IRQFLAGS 1607 bool "Debug IRQ flag manipulation" 1608 help 1609 Enables checks for potentially unsafe enabling or disabling of 1610 interrupts, such as calling raw_local_irq_restore() when interrupts 1611 are enabled. 1612 1613config STACKTRACE 1614 bool "Stack backtrace support" 1615 depends on STACKTRACE_SUPPORT 1616 help 1617 This option causes the kernel to create a /proc/pid/stack for 1618 every process, showing its current stack trace. 1619 It is also used by various kernel debugging features that require 1620 stack trace generation. 1621 1622config WARN_ALL_UNSEEDED_RANDOM 1623 bool "Warn for all uses of unseeded randomness" 1624 default n 1625 help 1626 Some parts of the kernel contain bugs relating to their use of 1627 cryptographically secure random numbers before it's actually possible 1628 to generate those numbers securely. This setting ensures that these 1629 flaws don't go unnoticed, by enabling a message, should this ever 1630 occur. This will allow people with obscure setups to know when things 1631 are going wrong, so that they might contact developers about fixing 1632 it. 1633 1634 Unfortunately, on some models of some architectures getting 1635 a fully seeded CRNG is extremely difficult, and so this can 1636 result in dmesg getting spammed for a surprisingly long 1637 time. This is really bad from a security perspective, and 1638 so architecture maintainers really need to do what they can 1639 to get the CRNG seeded sooner after the system is booted. 1640 However, since users cannot do anything actionable to 1641 address this, by default this option is disabled. 1642 1643 Say Y here if you want to receive warnings for all uses of 1644 unseeded randomness. This will be of use primarily for 1645 those developers interested in improving the security of 1646 Linux kernels running on their architecture (or 1647 subarchitecture). 1648 1649config DEBUG_KOBJECT 1650 bool "kobject debugging" 1651 depends on DEBUG_KERNEL 1652 help 1653 If you say Y here, some extra kobject debugging messages will be sent 1654 to the syslog. 1655 1656config DEBUG_KOBJECT_RELEASE 1657 bool "kobject release debugging" 1658 depends on DEBUG_OBJECTS_TIMERS 1659 help 1660 kobjects are reference counted objects. This means that their 1661 last reference count put is not predictable, and the kobject can 1662 live on past the point at which a driver decides to drop its 1663 initial reference to the kobject gained on allocation. An 1664 example of this would be a struct device which has just been 1665 unregistered. 1666 1667 However, some buggy drivers assume that after such an operation, 1668 the memory backing the kobject can be immediately freed. This 1669 goes completely against the principles of a refcounted object. 1670 1671 If you say Y here, the kernel will delay the release of kobjects 1672 on the last reference count to improve the visibility of this 1673 kind of kobject release bug. 1674 1675config HAVE_DEBUG_BUGVERBOSE 1676 bool 1677 1678menu "Debug kernel data structures" 1679 1680config DEBUG_LIST 1681 bool "Debug linked list manipulation" 1682 depends on DEBUG_KERNEL 1683 select LIST_HARDENED 1684 help 1685 Enable this to turn on extended checks in the linked-list walking 1686 routines. 1687 1688 This option trades better quality error reports for performance, and 1689 is more suitable for kernel debugging. If you care about performance, 1690 you should only enable CONFIG_LIST_HARDENED instead. 1691 1692 If unsure, say N. 1693 1694config DEBUG_PLIST 1695 bool "Debug priority linked list manipulation" 1696 depends on DEBUG_KERNEL 1697 help 1698 Enable this to turn on extended checks in the priority-ordered 1699 linked-list (plist) walking routines. This checks the entire 1700 list multiple times during each manipulation. 1701 1702 If unsure, say N. 1703 1704config DEBUG_SG 1705 bool "Debug SG table operations" 1706 depends on DEBUG_KERNEL 1707 help 1708 Enable this to turn on checks on scatter-gather tables. This can 1709 help find problems with drivers that do not properly initialize 1710 their sg tables. 1711 1712 If unsure, say N. 1713 1714config DEBUG_NOTIFIERS 1715 bool "Debug notifier call chains" 1716 depends on DEBUG_KERNEL 1717 help 1718 Enable this to turn on sanity checking for notifier call chains. 1719 This is most useful for kernel developers to make sure that 1720 modules properly unregister themselves from notifier chains. 1721 This is a relatively cheap check but if you care about maximum 1722 performance, say N. 1723 1724config DEBUG_CLOSURES 1725 bool "Debug closures (bcache async widgits)" 1726 depends on CLOSURES 1727 select DEBUG_FS 1728 help 1729 Keeps all active closures in a linked list and provides a debugfs 1730 interface to list them, which makes it possible to see asynchronous 1731 operations that get stuck. 1732 1733config DEBUG_MAPLE_TREE 1734 bool "Debug maple trees" 1735 depends on DEBUG_KERNEL 1736 help 1737 Enable maple tree debugging information and extra validations. 1738 1739 If unsure, say N. 1740 1741endmenu 1742 1743config DEBUG_CREDENTIALS 1744 bool "Debug credential management" 1745 depends on DEBUG_KERNEL 1746 help 1747 Enable this to turn on some debug checking for credential 1748 management. The additional code keeps track of the number of 1749 pointers from task_structs to any given cred struct, and checks to 1750 see that this number never exceeds the usage count of the cred 1751 struct. 1752 1753 Furthermore, if SELinux is enabled, this also checks that the 1754 security pointer in the cred struct is never seen to be invalid. 1755 1756 If unsure, say N. 1757 1758source "kernel/rcu/Kconfig.debug" 1759 1760config DEBUG_WQ_FORCE_RR_CPU 1761 bool "Force round-robin CPU selection for unbound work items" 1762 depends on DEBUG_KERNEL 1763 default n 1764 help 1765 Workqueue used to implicitly guarantee that work items queued 1766 without explicit CPU specified are put on the local CPU. This 1767 guarantee is no longer true and while local CPU is still 1768 preferred work items may be put on foreign CPUs. Kernel 1769 parameter "workqueue.debug_force_rr_cpu" is added to force 1770 round-robin CPU selection to flush out usages which depend on the 1771 now broken guarantee. This config option enables the debug 1772 feature by default. When enabled, memory and cache locality will 1773 be impacted. 1774 1775config CPU_HOTPLUG_STATE_CONTROL 1776 bool "Enable CPU hotplug state control" 1777 depends on DEBUG_KERNEL 1778 depends on HOTPLUG_CPU 1779 default n 1780 help 1781 Allows to write steps between "offline" and "online" to the CPUs 1782 sysfs target file so states can be stepped granular. This is a debug 1783 option for now as the hotplug machinery cannot be stopped and 1784 restarted at arbitrary points yet. 1785 1786 Say N if your are unsure. 1787 1788config LATENCYTOP 1789 bool "Latency measuring infrastructure" 1790 depends on DEBUG_KERNEL 1791 depends on STACKTRACE_SUPPORT 1792 depends on PROC_FS 1793 depends on FRAME_POINTER || MIPS || PPC || S390 || MICROBLAZE || ARM || ARC || X86 1794 select KALLSYMS 1795 select KALLSYMS_ALL 1796 select STACKTRACE 1797 select SCHEDSTATS 1798 help 1799 Enable this option if you want to use the LatencyTOP tool 1800 to find out which userspace is blocking on what kernel operations. 1801 1802config DEBUG_CGROUP_REF 1803 bool "Disable inlining of cgroup css reference count functions" 1804 depends on DEBUG_KERNEL 1805 depends on CGROUPS 1806 depends on KPROBES 1807 default n 1808 help 1809 Force cgroup css reference count functions to not be inlined so 1810 that they can be kprobed for debugging. 1811 1812source "kernel/trace/Kconfig" 1813 1814config PROVIDE_OHCI1394_DMA_INIT 1815 bool "Remote debugging over FireWire early on boot" 1816 depends on PCI && X86 1817 help 1818 If you want to debug problems which hang or crash the kernel early 1819 on boot and the crashing machine has a FireWire port, you can use 1820 this feature to remotely access the memory of the crashed machine 1821 over FireWire. This employs remote DMA as part of the OHCI1394 1822 specification which is now the standard for FireWire controllers. 1823 1824 With remote DMA, you can monitor the printk buffer remotely using 1825 firescope and access all memory below 4GB using fireproxy from gdb. 1826 Even controlling a kernel debugger is possible using remote DMA. 1827 1828 Usage: 1829 1830 If ohci1394_dma=early is used as boot parameter, it will initialize 1831 all OHCI1394 controllers which are found in the PCI config space. 1832 1833 As all changes to the FireWire bus such as enabling and disabling 1834 devices cause a bus reset and thereby disable remote DMA for all 1835 devices, be sure to have the cable plugged and FireWire enabled on 1836 the debugging host before booting the debug target for debugging. 1837 1838 This code (~1k) is freed after boot. By then, the firewire stack 1839 in charge of the OHCI-1394 controllers should be used instead. 1840 1841 See Documentation/core-api/debugging-via-ohci1394.rst for more information. 1842 1843source "samples/Kconfig" 1844 1845config ARCH_HAS_DEVMEM_IS_ALLOWED 1846 bool 1847 1848config STRICT_DEVMEM 1849 bool "Filter access to /dev/mem" 1850 depends on MMU && DEVMEM 1851 depends on ARCH_HAS_DEVMEM_IS_ALLOWED || GENERIC_LIB_DEVMEM_IS_ALLOWED 1852 default y if PPC || X86 || ARM64 1853 help 1854 If this option is disabled, you allow userspace (root) access to all 1855 of memory, including kernel and userspace memory. Accidental 1856 access to this is obviously disastrous, but specific access can 1857 be used by people debugging the kernel. Note that with PAT support 1858 enabled, even in this case there are restrictions on /dev/mem 1859 use due to the cache aliasing requirements. 1860 1861 If this option is switched on, and IO_STRICT_DEVMEM=n, the /dev/mem 1862 file only allows userspace access to PCI space and the BIOS code and 1863 data regions. This is sufficient for dosemu and X and all common 1864 users of /dev/mem. 1865 1866 If in doubt, say Y. 1867 1868config IO_STRICT_DEVMEM 1869 bool "Filter I/O access to /dev/mem" 1870 depends on STRICT_DEVMEM 1871 help 1872 If this option is disabled, you allow userspace (root) access to all 1873 io-memory regardless of whether a driver is actively using that 1874 range. Accidental access to this is obviously disastrous, but 1875 specific access can be used by people debugging kernel drivers. 1876 1877 If this option is switched on, the /dev/mem file only allows 1878 userspace access to *idle* io-memory ranges (see /proc/iomem) This 1879 may break traditional users of /dev/mem (dosemu, legacy X, etc...) 1880 if the driver using a given range cannot be disabled. 1881 1882 If in doubt, say Y. 1883 1884menu "$(SRCARCH) Debugging" 1885 1886source "arch/$(SRCARCH)/Kconfig.debug" 1887 1888endmenu 1889 1890menu "Kernel Testing and Coverage" 1891 1892source "lib/kunit/Kconfig" 1893 1894config NOTIFIER_ERROR_INJECTION 1895 tristate "Notifier error injection" 1896 depends on DEBUG_KERNEL 1897 select DEBUG_FS 1898 help 1899 This option provides the ability to inject artificial errors to 1900 specified notifier chain callbacks. It is useful to test the error 1901 handling of notifier call chain failures. 1902 1903 Say N if unsure. 1904 1905config PM_NOTIFIER_ERROR_INJECT 1906 tristate "PM notifier error injection module" 1907 depends on PM && NOTIFIER_ERROR_INJECTION 1908 default m if PM_DEBUG 1909 help 1910 This option provides the ability to inject artificial errors to 1911 PM notifier chain callbacks. It is controlled through debugfs 1912 interface /sys/kernel/debug/notifier-error-inject/pm 1913 1914 If the notifier call chain should be failed with some events 1915 notified, write the error code to "actions/<notifier event>/error". 1916 1917 Example: Inject PM suspend error (-12 = -ENOMEM) 1918 1919 # cd /sys/kernel/debug/notifier-error-inject/pm/ 1920 # echo -12 > actions/PM_SUSPEND_PREPARE/error 1921 # echo mem > /sys/power/state 1922 bash: echo: write error: Cannot allocate memory 1923 1924 To compile this code as a module, choose M here: the module will 1925 be called pm-notifier-error-inject. 1926 1927 If unsure, say N. 1928 1929config OF_RECONFIG_NOTIFIER_ERROR_INJECT 1930 tristate "OF reconfig notifier error injection module" 1931 depends on OF_DYNAMIC && NOTIFIER_ERROR_INJECTION 1932 help 1933 This option provides the ability to inject artificial errors to 1934 OF reconfig notifier chain callbacks. It is controlled 1935 through debugfs interface under 1936 /sys/kernel/debug/notifier-error-inject/OF-reconfig/ 1937 1938 If the notifier call chain should be failed with some events 1939 notified, write the error code to "actions/<notifier event>/error". 1940 1941 To compile this code as a module, choose M here: the module will 1942 be called of-reconfig-notifier-error-inject. 1943 1944 If unsure, say N. 1945 1946config NETDEV_NOTIFIER_ERROR_INJECT 1947 tristate "Netdev notifier error injection module" 1948 depends on NET && NOTIFIER_ERROR_INJECTION 1949 help 1950 This option provides the ability to inject artificial errors to 1951 netdevice notifier chain callbacks. It is controlled through debugfs 1952 interface /sys/kernel/debug/notifier-error-inject/netdev 1953 1954 If the notifier call chain should be failed with some events 1955 notified, write the error code to "actions/<notifier event>/error". 1956 1957 Example: Inject netdevice mtu change error (-22 = -EINVAL) 1958 1959 # cd /sys/kernel/debug/notifier-error-inject/netdev 1960 # echo -22 > actions/NETDEV_CHANGEMTU/error 1961 # ip link set eth0 mtu 1024 1962 RTNETLINK answers: Invalid argument 1963 1964 To compile this code as a module, choose M here: the module will 1965 be called netdev-notifier-error-inject. 1966 1967 If unsure, say N. 1968 1969config FUNCTION_ERROR_INJECTION 1970 bool "Fault-injections of functions" 1971 depends on HAVE_FUNCTION_ERROR_INJECTION && KPROBES 1972 help 1973 Add fault injections into various functions that are annotated with 1974 ALLOW_ERROR_INJECTION() in the kernel. BPF may also modify the return 1975 value of these functions. This is useful to test error paths of code. 1976 1977 If unsure, say N 1978 1979config FAULT_INJECTION 1980 bool "Fault-injection framework" 1981 depends on DEBUG_KERNEL 1982 help 1983 Provide fault-injection framework. 1984 For more details, see Documentation/fault-injection/. 1985 1986config FAILSLAB 1987 bool "Fault-injection capability for kmalloc" 1988 depends on FAULT_INJECTION 1989 depends on SLAB || SLUB 1990 help 1991 Provide fault-injection capability for kmalloc. 1992 1993config FAIL_PAGE_ALLOC 1994 bool "Fault-injection capability for alloc_pages()" 1995 depends on FAULT_INJECTION 1996 help 1997 Provide fault-injection capability for alloc_pages(). 1998 1999config FAULT_INJECTION_USERCOPY 2000 bool "Fault injection capability for usercopy functions" 2001 depends on FAULT_INJECTION 2002 help 2003 Provides fault-injection capability to inject failures 2004 in usercopy functions (copy_from_user(), get_user(), ...). 2005 2006config FAIL_MAKE_REQUEST 2007 bool "Fault-injection capability for disk IO" 2008 depends on FAULT_INJECTION && BLOCK 2009 help 2010 Provide fault-injection capability for disk IO. 2011 2012config FAIL_IO_TIMEOUT 2013 bool "Fault-injection capability for faking disk interrupts" 2014 depends on FAULT_INJECTION && BLOCK 2015 help 2016 Provide fault-injection capability on end IO handling. This 2017 will make the block layer "forget" an interrupt as configured, 2018 thus exercising the error handling. 2019 2020 Only works with drivers that use the generic timeout handling, 2021 for others it won't do anything. 2022 2023config FAIL_FUTEX 2024 bool "Fault-injection capability for futexes" 2025 select DEBUG_FS 2026 depends on FAULT_INJECTION && FUTEX 2027 help 2028 Provide fault-injection capability for futexes. 2029 2030config FAULT_INJECTION_DEBUG_FS 2031 bool "Debugfs entries for fault-injection capabilities" 2032 depends on FAULT_INJECTION && SYSFS && DEBUG_FS 2033 help 2034 Enable configuration of fault-injection capabilities via debugfs. 2035 2036config FAIL_FUNCTION 2037 bool "Fault-injection capability for functions" 2038 depends on FAULT_INJECTION_DEBUG_FS && FUNCTION_ERROR_INJECTION 2039 help 2040 Provide function-based fault-injection capability. 2041 This will allow you to override a specific function with a return 2042 with given return value. As a result, function caller will see 2043 an error value and have to handle it. This is useful to test the 2044 error handling in various subsystems. 2045 2046config FAIL_MMC_REQUEST 2047 bool "Fault-injection capability for MMC IO" 2048 depends on FAULT_INJECTION_DEBUG_FS && MMC 2049 help 2050 Provide fault-injection capability for MMC IO. 2051 This will make the mmc core return data errors. This is 2052 useful to test the error handling in the mmc block device 2053 and to test how the mmc host driver handles retries from 2054 the block device. 2055 2056config FAIL_SUNRPC 2057 bool "Fault-injection capability for SunRPC" 2058 depends on FAULT_INJECTION_DEBUG_FS && SUNRPC_DEBUG 2059 help 2060 Provide fault-injection capability for SunRPC and 2061 its consumers. 2062 2063config FAULT_INJECTION_CONFIGFS 2064 bool "Configfs interface for fault-injection capabilities" 2065 depends on FAULT_INJECTION 2066 select CONFIGFS_FS 2067 help 2068 This option allows configfs-based drivers to dynamically configure 2069 fault-injection via configfs. Each parameter for driver-specific 2070 fault-injection can be made visible as a configfs attribute in a 2071 configfs group. 2072 2073 2074config FAULT_INJECTION_STACKTRACE_FILTER 2075 bool "stacktrace filter for fault-injection capabilities" 2076 depends on FAULT_INJECTION 2077 depends on (FAULT_INJECTION_DEBUG_FS || FAULT_INJECTION_CONFIGFS) && STACKTRACE_SUPPORT 2078 select STACKTRACE 2079 depends on FRAME_POINTER || MIPS || PPC || S390 || MICROBLAZE || ARM || ARC || X86 2080 help 2081 Provide stacktrace filter for fault-injection capabilities 2082 2083config ARCH_HAS_KCOV 2084 bool 2085 help 2086 An architecture should select this when it can successfully 2087 build and run with CONFIG_KCOV. This typically requires 2088 disabling instrumentation for some early boot code. 2089 2090config CC_HAS_SANCOV_TRACE_PC 2091 def_bool $(cc-option,-fsanitize-coverage=trace-pc) 2092 2093 2094config KCOV 2095 bool "Code coverage for fuzzing" 2096 depends on ARCH_HAS_KCOV 2097 depends on CC_HAS_SANCOV_TRACE_PC || GCC_PLUGINS 2098 depends on !ARCH_WANTS_NO_INSTR || HAVE_NOINSTR_HACK || \ 2099 GCC_VERSION >= 120000 || CLANG_VERSION >= 130000 2100 select DEBUG_FS 2101 select GCC_PLUGIN_SANCOV if !CC_HAS_SANCOV_TRACE_PC 2102 select OBJTOOL if HAVE_NOINSTR_HACK 2103 help 2104 KCOV exposes kernel code coverage information in a form suitable 2105 for coverage-guided fuzzing (randomized testing). 2106 2107 If RANDOMIZE_BASE is enabled, PC values will not be stable across 2108 different machines and across reboots. If you need stable PC values, 2109 disable RANDOMIZE_BASE. 2110 2111 For more details, see Documentation/dev-tools/kcov.rst. 2112 2113config KCOV_ENABLE_COMPARISONS 2114 bool "Enable comparison operands collection by KCOV" 2115 depends on KCOV 2116 depends on $(cc-option,-fsanitize-coverage=trace-cmp) 2117 help 2118 KCOV also exposes operands of every comparison in the instrumented 2119 code along with operand sizes and PCs of the comparison instructions. 2120 These operands can be used by fuzzing engines to improve the quality 2121 of fuzzing coverage. 2122 2123config KCOV_INSTRUMENT_ALL 2124 bool "Instrument all code by default" 2125 depends on KCOV 2126 default y 2127 help 2128 If you are doing generic system call fuzzing (like e.g. syzkaller), 2129 then you will want to instrument the whole kernel and you should 2130 say y here. If you are doing more targeted fuzzing (like e.g. 2131 filesystem fuzzing with AFL) then you will want to enable coverage 2132 for more specific subsets of files, and should say n here. 2133 2134config KCOV_IRQ_AREA_SIZE 2135 hex "Size of interrupt coverage collection area in words" 2136 depends on KCOV 2137 default 0x40000 2138 help 2139 KCOV uses preallocated per-cpu areas to collect coverage from 2140 soft interrupts. This specifies the size of those areas in the 2141 number of unsigned long words. 2142 2143menuconfig RUNTIME_TESTING_MENU 2144 bool "Runtime Testing" 2145 def_bool y 2146 2147if RUNTIME_TESTING_MENU 2148 2149config TEST_DHRY 2150 tristate "Dhrystone benchmark test" 2151 help 2152 Enable this to include the Dhrystone 2.1 benchmark. This test 2153 calculates the number of Dhrystones per second, and the number of 2154 DMIPS (Dhrystone MIPS) obtained when the Dhrystone score is divided 2155 by 1757 (the number of Dhrystones per second obtained on the VAX 2156 11/780, nominally a 1 MIPS machine). 2157 2158 To run the benchmark, it needs to be enabled explicitly, either from 2159 the kernel command line (when built-in), or from userspace (when 2160 built-in or modular. 2161 2162 Run once during kernel boot: 2163 2164 test_dhry.run 2165 2166 Set number of iterations from kernel command line: 2167 2168 test_dhry.iterations=<n> 2169 2170 Set number of iterations from userspace: 2171 2172 echo <n> > /sys/module/test_dhry/parameters/iterations 2173 2174 Trigger manual run from userspace: 2175 2176 echo y > /sys/module/test_dhry/parameters/run 2177 2178 If the number of iterations is <= 0, the test will devise a suitable 2179 number of iterations (test runs for at least 2s) automatically. 2180 This process takes ca. 4s. 2181 2182 If unsure, say N. 2183 2184config LKDTM 2185 tristate "Linux Kernel Dump Test Tool Module" 2186 depends on DEBUG_FS 2187 help 2188 This module enables testing of the different dumping mechanisms by 2189 inducing system failures at predefined crash points. 2190 If you don't need it: say N 2191 Choose M here to compile this code as a module. The module will be 2192 called lkdtm. 2193 2194 Documentation on how to use the module can be found in 2195 Documentation/fault-injection/provoke-crashes.rst 2196 2197config CPUMASK_KUNIT_TEST 2198 tristate "KUnit test for cpumask" if !KUNIT_ALL_TESTS 2199 depends on KUNIT 2200 default KUNIT_ALL_TESTS 2201 help 2202 Enable to turn on cpumask tests, running at boot or module load time. 2203 2204 For more information on KUnit and unit tests in general, please refer 2205 to the KUnit documentation in Documentation/dev-tools/kunit/. 2206 2207 If unsure, say N. 2208 2209config TEST_LIST_SORT 2210 tristate "Linked list sorting test" if !KUNIT_ALL_TESTS 2211 depends on KUNIT 2212 default KUNIT_ALL_TESTS 2213 help 2214 Enable this to turn on 'list_sort()' function test. This test is 2215 executed only once during system boot (so affects only boot time), 2216 or at module load time. 2217 2218 If unsure, say N. 2219 2220config TEST_MIN_HEAP 2221 tristate "Min heap test" 2222 depends on DEBUG_KERNEL || m 2223 help 2224 Enable this to turn on min heap function tests. This test is 2225 executed only once during system boot (so affects only boot time), 2226 or at module load time. 2227 2228 If unsure, say N. 2229 2230config TEST_SORT 2231 tristate "Array-based sort test" if !KUNIT_ALL_TESTS 2232 depends on KUNIT 2233 default KUNIT_ALL_TESTS 2234 help 2235 This option enables the self-test function of 'sort()' at boot, 2236 or at module load time. 2237 2238 If unsure, say N. 2239 2240config TEST_DIV64 2241 tristate "64bit/32bit division and modulo test" 2242 depends on DEBUG_KERNEL || m 2243 help 2244 Enable this to turn on 'do_div()' function test. This test is 2245 executed only once during system boot (so affects only boot time), 2246 or at module load time. 2247 2248 If unsure, say N. 2249 2250config TEST_IOV_ITER 2251 tristate "Test iov_iter operation" if !KUNIT_ALL_TESTS 2252 depends on KUNIT 2253 default KUNIT_ALL_TESTS 2254 help 2255 Enable this to turn on testing of the operation of the I/O iterator 2256 (iov_iter). This test is executed only once during system boot (so 2257 affects only boot time), or at module load time. 2258 2259 If unsure, say N. 2260 2261config KPROBES_SANITY_TEST 2262 tristate "Kprobes sanity tests" if !KUNIT_ALL_TESTS 2263 depends on DEBUG_KERNEL 2264 depends on KPROBES 2265 depends on KUNIT 2266 select STACKTRACE if ARCH_CORRECT_STACKTRACE_ON_KRETPROBE 2267 default KUNIT_ALL_TESTS 2268 help 2269 This option provides for testing basic kprobes functionality on 2270 boot. Samples of kprobe and kretprobe are inserted and 2271 verified for functionality. 2272 2273 Say N if you are unsure. 2274 2275config FPROBE_SANITY_TEST 2276 bool "Self test for fprobe" 2277 depends on DEBUG_KERNEL 2278 depends on FPROBE 2279 depends on KUNIT=y 2280 help 2281 This option will enable testing the fprobe when the system boot. 2282 A series of tests are made to verify that the fprobe is functioning 2283 properly. 2284 2285 Say N if you are unsure. 2286 2287config BACKTRACE_SELF_TEST 2288 tristate "Self test for the backtrace code" 2289 depends on DEBUG_KERNEL 2290 help 2291 This option provides a kernel module that can be used to test 2292 the kernel stack backtrace code. This option is not useful 2293 for distributions or general kernels, but only for kernel 2294 developers working on architecture code. 2295 2296 Note that if you want to also test saved backtraces, you will 2297 have to enable STACKTRACE as well. 2298 2299 Say N if you are unsure. 2300 2301config TEST_REF_TRACKER 2302 tristate "Self test for reference tracker" 2303 depends on DEBUG_KERNEL && STACKTRACE_SUPPORT 2304 select REF_TRACKER 2305 help 2306 This option provides a kernel module performing tests 2307 using reference tracker infrastructure. 2308 2309 Say N if you are unsure. 2310 2311config RBTREE_TEST 2312 tristate "Red-Black tree test" 2313 depends on DEBUG_KERNEL 2314 help 2315 A benchmark measuring the performance of the rbtree library. 2316 Also includes rbtree invariant checks. 2317 2318config REED_SOLOMON_TEST 2319 tristate "Reed-Solomon library test" 2320 depends on DEBUG_KERNEL || m 2321 select REED_SOLOMON 2322 select REED_SOLOMON_ENC16 2323 select REED_SOLOMON_DEC16 2324 help 2325 This option enables the self-test function of rslib at boot, 2326 or at module load time. 2327 2328 If unsure, say N. 2329 2330config INTERVAL_TREE_TEST 2331 tristate "Interval tree test" 2332 depends on DEBUG_KERNEL 2333 select INTERVAL_TREE 2334 help 2335 A benchmark measuring the performance of the interval tree library 2336 2337config PERCPU_TEST 2338 tristate "Per cpu operations test" 2339 depends on m && DEBUG_KERNEL 2340 help 2341 Enable this option to build test module which validates per-cpu 2342 operations. 2343 2344 If unsure, say N. 2345 2346config ATOMIC64_SELFTEST 2347 tristate "Perform an atomic64_t self-test" 2348 help 2349 Enable this option to test the atomic64_t functions at boot or 2350 at module load time. 2351 2352 If unsure, say N. 2353 2354config ASYNC_RAID6_TEST 2355 tristate "Self test for hardware accelerated raid6 recovery" 2356 depends on ASYNC_RAID6_RECOV 2357 select ASYNC_MEMCPY 2358 help 2359 This is a one-shot self test that permutes through the 2360 recovery of all the possible two disk failure scenarios for a 2361 N-disk array. Recovery is performed with the asynchronous 2362 raid6 recovery routines, and will optionally use an offload 2363 engine if one is available. 2364 2365 If unsure, say N. 2366 2367config TEST_HEXDUMP 2368 tristate "Test functions located in the hexdump module at runtime" 2369 2370config STRING_SELFTEST 2371 tristate "Test string functions at runtime" 2372 2373config TEST_STRING_HELPERS 2374 tristate "Test functions located in the string_helpers module at runtime" 2375 2376config TEST_KSTRTOX 2377 tristate "Test kstrto*() family of functions at runtime" 2378 2379config TEST_PRINTF 2380 tristate "Test printf() family of functions at runtime" 2381 2382config TEST_SCANF 2383 tristate "Test scanf() family of functions at runtime" 2384 2385config TEST_BITMAP 2386 tristate "Test bitmap_*() family of functions at runtime" 2387 help 2388 Enable this option to test the bitmap functions at boot. 2389 2390 If unsure, say N. 2391 2392config TEST_UUID 2393 tristate "Test functions located in the uuid module at runtime" 2394 2395config TEST_XARRAY 2396 tristate "Test the XArray code at runtime" 2397 2398config TEST_MAPLE_TREE 2399 tristate "Test the Maple Tree code at runtime or module load" 2400 help 2401 Enable this option to test the maple tree code functions at boot, or 2402 when the module is loaded. Enable "Debug Maple Trees" will enable 2403 more verbose output on failures. 2404 2405 If unsure, say N. 2406 2407config TEST_RHASHTABLE 2408 tristate "Perform selftest on resizable hash table" 2409 help 2410 Enable this option to test the rhashtable functions at boot. 2411 2412 If unsure, say N. 2413 2414config TEST_IDA 2415 tristate "Perform selftest on IDA functions" 2416 2417config TEST_PARMAN 2418 tristate "Perform selftest on priority array manager" 2419 depends on PARMAN 2420 help 2421 Enable this option to test priority array manager on boot 2422 (or module load). 2423 2424 If unsure, say N. 2425 2426config TEST_IRQ_TIMINGS 2427 bool "IRQ timings selftest" 2428 depends on IRQ_TIMINGS 2429 help 2430 Enable this option to test the irq timings code on boot. 2431 2432 If unsure, say N. 2433 2434config TEST_LKM 2435 tristate "Test module loading with 'hello world' module" 2436 depends on m 2437 help 2438 This builds the "test_module" module that emits "Hello, world" 2439 on printk when loaded. It is designed to be used for basic 2440 evaluation of the module loading subsystem (for example when 2441 validating module verification). It lacks any extra dependencies, 2442 and will not normally be loaded by the system unless explicitly 2443 requested by name. 2444 2445 If unsure, say N. 2446 2447config TEST_BITOPS 2448 tristate "Test module for compilation of bitops operations" 2449 depends on m 2450 help 2451 This builds the "test_bitops" module that is much like the 2452 TEST_LKM module except that it does a basic exercise of the 2453 set/clear_bit macros and get_count_order/long to make sure there are 2454 no compiler warnings from C=1 sparse checker or -Wextra 2455 compilations. It has no dependencies and doesn't run or load unless 2456 explicitly requested by name. for example: modprobe test_bitops. 2457 2458 If unsure, say N. 2459 2460config TEST_VMALLOC 2461 tristate "Test module for stress/performance analysis of vmalloc allocator" 2462 default n 2463 depends on MMU 2464 depends on m 2465 help 2466 This builds the "test_vmalloc" module that should be used for 2467 stress and performance analysis. So, any new change for vmalloc 2468 subsystem can be evaluated from performance and stability point 2469 of view. 2470 2471 If unsure, say N. 2472 2473config TEST_USER_COPY 2474 tristate "Test user/kernel boundary protections" 2475 depends on m 2476 help 2477 This builds the "test_user_copy" module that runs sanity checks 2478 on the copy_to/from_user infrastructure, making sure basic 2479 user/kernel boundary testing is working. If it fails to load, 2480 a regression has been detected in the user/kernel memory boundary 2481 protections. 2482 2483 If unsure, say N. 2484 2485config TEST_BPF 2486 tristate "Test BPF filter functionality" 2487 depends on m && NET 2488 help 2489 This builds the "test_bpf" module that runs various test vectors 2490 against the BPF interpreter or BPF JIT compiler depending on the 2491 current setting. This is in particular useful for BPF JIT compiler 2492 development, but also to run regression tests against changes in 2493 the interpreter code. It also enables test stubs for eBPF maps and 2494 verifier used by user space verifier testsuite. 2495 2496 If unsure, say N. 2497 2498config TEST_BLACKHOLE_DEV 2499 tristate "Test blackhole netdev functionality" 2500 depends on m && NET 2501 help 2502 This builds the "test_blackhole_dev" module that validates the 2503 data path through this blackhole netdev. 2504 2505 If unsure, say N. 2506 2507config FIND_BIT_BENCHMARK 2508 tristate "Test find_bit functions" 2509 help 2510 This builds the "test_find_bit" module that measure find_*_bit() 2511 functions performance. 2512 2513 If unsure, say N. 2514 2515config TEST_FIRMWARE 2516 tristate "Test firmware loading via userspace interface" 2517 depends on FW_LOADER 2518 help 2519 This builds the "test_firmware" module that creates a userspace 2520 interface for testing firmware loading. This can be used to 2521 control the triggering of firmware loading without needing an 2522 actual firmware-using device. The contents can be rechecked by 2523 userspace. 2524 2525 If unsure, say N. 2526 2527config TEST_SYSCTL 2528 tristate "sysctl test driver" 2529 depends on PROC_SYSCTL 2530 help 2531 This builds the "test_sysctl" module. This driver enables to test the 2532 proc sysctl interfaces available to drivers safely without affecting 2533 production knobs which might alter system functionality. 2534 2535 If unsure, say N. 2536 2537config BITFIELD_KUNIT 2538 tristate "KUnit test bitfield functions at runtime" if !KUNIT_ALL_TESTS 2539 depends on KUNIT 2540 default KUNIT_ALL_TESTS 2541 help 2542 Enable this option to test the bitfield functions at boot. 2543 2544 KUnit tests run during boot and output the results to the debug log 2545 in TAP format (http://testanything.org/). Only useful for kernel devs 2546 running the KUnit test harness, and not intended for inclusion into a 2547 production build. 2548 2549 For more information on KUnit and unit tests in general please refer 2550 to the KUnit documentation in Documentation/dev-tools/kunit/. 2551 2552 If unsure, say N. 2553 2554config CHECKSUM_KUNIT 2555 tristate "KUnit test checksum functions at runtime" if !KUNIT_ALL_TESTS 2556 depends on KUNIT 2557 default KUNIT_ALL_TESTS 2558 help 2559 Enable this option to test the checksum functions at boot. 2560 2561 KUnit tests run during boot and output the results to the debug log 2562 in TAP format (http://testanything.org/). Only useful for kernel devs 2563 running the KUnit test harness, and not intended for inclusion into a 2564 production build. 2565 2566 For more information on KUnit and unit tests in general please refer 2567 to the KUnit documentation in Documentation/dev-tools/kunit/. 2568 2569 If unsure, say N. 2570 2571config HASH_KUNIT_TEST 2572 tristate "KUnit Test for integer hash functions" if !KUNIT_ALL_TESTS 2573 depends on KUNIT 2574 default KUNIT_ALL_TESTS 2575 help 2576 Enable this option to test the kernel's string (<linux/stringhash.h>), and 2577 integer (<linux/hash.h>) hash functions on boot. 2578 2579 KUnit tests run during boot and output the results to the debug log 2580 in TAP format (https://testanything.org/). Only useful for kernel devs 2581 running the KUnit test harness, and not intended for inclusion into a 2582 production build. 2583 2584 For more information on KUnit and unit tests in general please refer 2585 to the KUnit documentation in Documentation/dev-tools/kunit/. 2586 2587 This is intended to help people writing architecture-specific 2588 optimized versions. If unsure, say N. 2589 2590config RESOURCE_KUNIT_TEST 2591 tristate "KUnit test for resource API" if !KUNIT_ALL_TESTS 2592 depends on KUNIT 2593 default KUNIT_ALL_TESTS 2594 help 2595 This builds the resource API unit test. 2596 Tests the logic of API provided by resource.c and ioport.h. 2597 For more information on KUnit and unit tests in general please refer 2598 to the KUnit documentation in Documentation/dev-tools/kunit/. 2599 2600 If unsure, say N. 2601 2602config SYSCTL_KUNIT_TEST 2603 tristate "KUnit test for sysctl" if !KUNIT_ALL_TESTS 2604 depends on KUNIT 2605 default KUNIT_ALL_TESTS 2606 help 2607 This builds the proc sysctl unit test, which runs on boot. 2608 Tests the API contract and implementation correctness of sysctl. 2609 For more information on KUnit and unit tests in general please refer 2610 to the KUnit documentation in Documentation/dev-tools/kunit/. 2611 2612 If unsure, say N. 2613 2614config LIST_KUNIT_TEST 2615 tristate "KUnit Test for Kernel Linked-list structures" if !KUNIT_ALL_TESTS 2616 depends on KUNIT 2617 default KUNIT_ALL_TESTS 2618 help 2619 This builds the linked list KUnit test suite. 2620 It tests that the API and basic functionality of the list_head type 2621 and associated macros. 2622 2623 KUnit tests run during boot and output the results to the debug log 2624 in TAP format (https://testanything.org/). Only useful for kernel devs 2625 running the KUnit test harness, and not intended for inclusion into a 2626 production build. 2627 2628 For more information on KUnit and unit tests in general please refer 2629 to the KUnit documentation in Documentation/dev-tools/kunit/. 2630 2631 If unsure, say N. 2632 2633config HASHTABLE_KUNIT_TEST 2634 tristate "KUnit Test for Kernel Hashtable structures" if !KUNIT_ALL_TESTS 2635 depends on KUNIT 2636 default KUNIT_ALL_TESTS 2637 help 2638 This builds the hashtable KUnit test suite. 2639 It tests the basic functionality of the API defined in 2640 include/linux/hashtable.h. For more information on KUnit and 2641 unit tests in general please refer to the KUnit documentation 2642 in Documentation/dev-tools/kunit/. 2643 2644 If unsure, say N. 2645 2646config LINEAR_RANGES_TEST 2647 tristate "KUnit test for linear_ranges" 2648 depends on KUNIT 2649 select LINEAR_RANGES 2650 help 2651 This builds the linear_ranges unit test, which runs on boot. 2652 Tests the linear_ranges logic correctness. 2653 For more information on KUnit and unit tests in general please refer 2654 to the KUnit documentation in Documentation/dev-tools/kunit/. 2655 2656 If unsure, say N. 2657 2658config CMDLINE_KUNIT_TEST 2659 tristate "KUnit test for cmdline API" if !KUNIT_ALL_TESTS 2660 depends on KUNIT 2661 default KUNIT_ALL_TESTS 2662 help 2663 This builds the cmdline API unit test. 2664 Tests the logic of API provided by cmdline.c. 2665 For more information on KUnit and unit tests in general please refer 2666 to the KUnit documentation in Documentation/dev-tools/kunit/. 2667 2668 If unsure, say N. 2669 2670config BITS_TEST 2671 tristate "KUnit test for bits.h" if !KUNIT_ALL_TESTS 2672 depends on KUNIT 2673 default KUNIT_ALL_TESTS 2674 help 2675 This builds the bits unit test. 2676 Tests the logic of macros defined in bits.h. 2677 For more information on KUnit and unit tests in general please refer 2678 to the KUnit documentation in Documentation/dev-tools/kunit/. 2679 2680 If unsure, say N. 2681 2682config SLUB_KUNIT_TEST 2683 tristate "KUnit test for SLUB cache error detection" if !KUNIT_ALL_TESTS 2684 depends on SLUB_DEBUG && KUNIT 2685 default KUNIT_ALL_TESTS 2686 help 2687 This builds SLUB allocator unit test. 2688 Tests SLUB cache debugging functionality. 2689 For more information on KUnit and unit tests in general please refer 2690 to the KUnit documentation in Documentation/dev-tools/kunit/. 2691 2692 If unsure, say N. 2693 2694config RATIONAL_KUNIT_TEST 2695 tristate "KUnit test for rational.c" if !KUNIT_ALL_TESTS 2696 depends on KUNIT && RATIONAL 2697 default KUNIT_ALL_TESTS 2698 help 2699 This builds the rational math unit test. 2700 For more information on KUnit and unit tests in general please refer 2701 to the KUnit documentation in Documentation/dev-tools/kunit/. 2702 2703 If unsure, say N. 2704 2705config MEMCPY_KUNIT_TEST 2706 tristate "Test memcpy(), memmove(), and memset() functions at runtime" if !KUNIT_ALL_TESTS 2707 depends on KUNIT 2708 default KUNIT_ALL_TESTS 2709 help 2710 Builds unit tests for memcpy(), memmove(), and memset() functions. 2711 For more information on KUnit and unit tests in general please refer 2712 to the KUnit documentation in Documentation/dev-tools/kunit/. 2713 2714 If unsure, say N. 2715 2716config MEMCPY_SLOW_KUNIT_TEST 2717 bool "Include exhaustive memcpy tests" 2718 depends on MEMCPY_KUNIT_TEST 2719 default y 2720 help 2721 Some memcpy tests are quite exhaustive in checking for overlaps 2722 and bit ranges. These can be very slow, so they are split out 2723 as a separate config, in case they need to be disabled. 2724 2725 Note this config option will be replaced by the use of KUnit test 2726 attributes. 2727 2728config IS_SIGNED_TYPE_KUNIT_TEST 2729 tristate "Test is_signed_type() macro" if !KUNIT_ALL_TESTS 2730 depends on KUNIT 2731 default KUNIT_ALL_TESTS 2732 help 2733 Builds unit tests for the is_signed_type() macro. 2734 2735 For more information on KUnit and unit tests in general please refer 2736 to the KUnit documentation in Documentation/dev-tools/kunit/. 2737 2738 If unsure, say N. 2739 2740config OVERFLOW_KUNIT_TEST 2741 tristate "Test check_*_overflow() functions at runtime" if !KUNIT_ALL_TESTS 2742 depends on KUNIT 2743 default KUNIT_ALL_TESTS 2744 help 2745 Builds unit tests for the check_*_overflow(), size_*(), allocation, and 2746 related functions. 2747 2748 For more information on KUnit and unit tests in general please refer 2749 to the KUnit documentation in Documentation/dev-tools/kunit/. 2750 2751 If unsure, say N. 2752 2753config STACKINIT_KUNIT_TEST 2754 tristate "Test level of stack variable initialization" if !KUNIT_ALL_TESTS 2755 depends on KUNIT 2756 default KUNIT_ALL_TESTS 2757 help 2758 Test if the kernel is zero-initializing stack variables and 2759 padding. Coverage is controlled by compiler flags, 2760 CONFIG_INIT_STACK_ALL_PATTERN, CONFIG_INIT_STACK_ALL_ZERO, 2761 CONFIG_GCC_PLUGIN_STRUCTLEAK, CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF, 2762 or CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL. 2763 2764config FORTIFY_KUNIT_TEST 2765 tristate "Test fortified str*() and mem*() function internals at runtime" if !KUNIT_ALL_TESTS 2766 depends on KUNIT && FORTIFY_SOURCE 2767 default KUNIT_ALL_TESTS 2768 help 2769 Builds unit tests for checking internals of FORTIFY_SOURCE as used 2770 by the str*() and mem*() family of functions. For testing runtime 2771 traps of FORTIFY_SOURCE, see LKDTM's "FORTIFY_*" tests. 2772 2773config HW_BREAKPOINT_KUNIT_TEST 2774 bool "Test hw_breakpoint constraints accounting" if !KUNIT_ALL_TESTS 2775 depends on HAVE_HW_BREAKPOINT 2776 depends on KUNIT=y 2777 default KUNIT_ALL_TESTS 2778 help 2779 Tests for hw_breakpoint constraints accounting. 2780 2781 If unsure, say N. 2782 2783config STRCAT_KUNIT_TEST 2784 tristate "Test strcat() family of functions at runtime" if !KUNIT_ALL_TESTS 2785 depends on KUNIT 2786 default KUNIT_ALL_TESTS 2787 2788config STRSCPY_KUNIT_TEST 2789 tristate "Test strscpy*() family of functions at runtime" if !KUNIT_ALL_TESTS 2790 depends on KUNIT 2791 default KUNIT_ALL_TESTS 2792 2793config SIPHASH_KUNIT_TEST 2794 tristate "Perform selftest on siphash functions" if !KUNIT_ALL_TESTS 2795 depends on KUNIT 2796 default KUNIT_ALL_TESTS 2797 help 2798 Enable this option to test the kernel's siphash (<linux/siphash.h>) hash 2799 functions on boot (or module load). 2800 2801 This is intended to help people writing architecture-specific 2802 optimized versions. If unsure, say N. 2803 2804config TEST_UDELAY 2805 tristate "udelay test driver" 2806 help 2807 This builds the "udelay_test" module that helps to make sure 2808 that udelay() is working properly. 2809 2810 If unsure, say N. 2811 2812config TEST_STATIC_KEYS 2813 tristate "Test static keys" 2814 depends on m 2815 help 2816 Test the static key interfaces. 2817 2818 If unsure, say N. 2819 2820config TEST_DYNAMIC_DEBUG 2821 tristate "Test DYNAMIC_DEBUG" 2822 depends on DYNAMIC_DEBUG 2823 help 2824 This module registers a tracer callback to count enabled 2825 pr_debugs in a 'do_debugging' function, then alters their 2826 enablements, calls the function, and compares counts. 2827 2828 If unsure, say N. 2829 2830config TEST_KMOD 2831 tristate "kmod stress tester" 2832 depends on m 2833 depends on NETDEVICES && NET_CORE && INET # for TUN 2834 depends on BLOCK 2835 depends on PAGE_SIZE_LESS_THAN_256KB # for BTRFS 2836 select TEST_LKM 2837 select XFS_FS 2838 select TUN 2839 select BTRFS_FS 2840 help 2841 Test the kernel's module loading mechanism: kmod. kmod implements 2842 support to load modules using the Linux kernel's usermode helper. 2843 This test provides a series of tests against kmod. 2844 2845 Although technically you can either build test_kmod as a module or 2846 into the kernel we disallow building it into the kernel since 2847 it stress tests request_module() and this will very likely cause 2848 some issues by taking over precious threads available from other 2849 module load requests, ultimately this could be fatal. 2850 2851 To run tests run: 2852 2853 tools/testing/selftests/kmod/kmod.sh --help 2854 2855 If unsure, say N. 2856 2857config TEST_DEBUG_VIRTUAL 2858 tristate "Test CONFIG_DEBUG_VIRTUAL feature" 2859 depends on DEBUG_VIRTUAL 2860 help 2861 Test the kernel's ability to detect incorrect calls to 2862 virt_to_phys() done against the non-linear part of the 2863 kernel's virtual address map. 2864 2865 If unsure, say N. 2866 2867config TEST_MEMCAT_P 2868 tristate "Test memcat_p() helper function" 2869 help 2870 Test the memcat_p() helper for correctly merging two 2871 pointer arrays together. 2872 2873 If unsure, say N. 2874 2875config TEST_LIVEPATCH 2876 tristate "Test livepatching" 2877 default n 2878 depends on DYNAMIC_DEBUG 2879 depends on LIVEPATCH 2880 depends on m 2881 help 2882 Test kernel livepatching features for correctness. The tests will 2883 load test modules that will be livepatched in various scenarios. 2884 2885 To run all the livepatching tests: 2886 2887 make -C tools/testing/selftests TARGETS=livepatch run_tests 2888 2889 Alternatively, individual tests may be invoked: 2890 2891 tools/testing/selftests/livepatch/test-callbacks.sh 2892 tools/testing/selftests/livepatch/test-livepatch.sh 2893 tools/testing/selftests/livepatch/test-shadow-vars.sh 2894 2895 If unsure, say N. 2896 2897config TEST_OBJAGG 2898 tristate "Perform selftest on object aggreration manager" 2899 default n 2900 depends on OBJAGG 2901 help 2902 Enable this option to test object aggregation manager on boot 2903 (or module load). 2904 2905config TEST_MEMINIT 2906 tristate "Test heap/page initialization" 2907 help 2908 Test if the kernel is zero-initializing heap and page allocations. 2909 This can be useful to test init_on_alloc and init_on_free features. 2910 2911 If unsure, say N. 2912 2913config TEST_HMM 2914 tristate "Test HMM (Heterogeneous Memory Management)" 2915 depends on TRANSPARENT_HUGEPAGE 2916 depends on DEVICE_PRIVATE 2917 select HMM_MIRROR 2918 select MMU_NOTIFIER 2919 help 2920 This is a pseudo device driver solely for testing HMM. 2921 Say M here if you want to build the HMM test module. 2922 Doing so will allow you to run tools/testing/selftest/vm/hmm-tests. 2923 2924 If unsure, say N. 2925 2926config TEST_FREE_PAGES 2927 tristate "Test freeing pages" 2928 help 2929 Test that a memory leak does not occur due to a race between 2930 freeing a block of pages and a speculative page reference. 2931 Loading this module is safe if your kernel has the bug fixed. 2932 If the bug is not fixed, it will leak gigabytes of memory and 2933 probably OOM your system. 2934 2935config TEST_FPU 2936 tristate "Test floating point operations in kernel space" 2937 depends on X86 && !KCOV_INSTRUMENT_ALL 2938 help 2939 Enable this option to add /sys/kernel/debug/selftest_helpers/test_fpu 2940 which will trigger a sequence of floating point operations. This is used 2941 for self-testing floating point control register setting in 2942 kernel_fpu_begin(). 2943 2944 If unsure, say N. 2945 2946config TEST_CLOCKSOURCE_WATCHDOG 2947 tristate "Test clocksource watchdog in kernel space" 2948 depends on CLOCKSOURCE_WATCHDOG 2949 help 2950 Enable this option to create a kernel module that will trigger 2951 a test of the clocksource watchdog. This module may be loaded 2952 via modprobe or insmod in which case it will run upon being 2953 loaded, or it may be built in, in which case it will run 2954 shortly after boot. 2955 2956 If unsure, say N. 2957 2958config TEST_OBJPOOL 2959 tristate "Test module for correctness and stress of objpool" 2960 default n 2961 depends on m && DEBUG_KERNEL 2962 help 2963 This builds the "test_objpool" module that should be used for 2964 correctness verification and concurrent testings of objects 2965 allocation and reclamation. 2966 2967 If unsure, say N. 2968 2969endif # RUNTIME_TESTING_MENU 2970 2971config ARCH_USE_MEMTEST 2972 bool 2973 help 2974 An architecture should select this when it uses early_memtest() 2975 during boot process. 2976 2977config MEMTEST 2978 bool "Memtest" 2979 depends on ARCH_USE_MEMTEST 2980 help 2981 This option adds a kernel parameter 'memtest', which allows memtest 2982 to be set and executed. 2983 memtest=0, mean disabled; -- default 2984 memtest=1, mean do 1 test pattern; 2985 ... 2986 memtest=17, mean do 17 test patterns. 2987 If you are unsure how to answer this question, answer N. 2988 2989 2990 2991config HYPERV_TESTING 2992 bool "Microsoft Hyper-V driver testing" 2993 default n 2994 depends on HYPERV && DEBUG_FS 2995 help 2996 Select this option to enable Hyper-V vmbus testing. 2997 2998endmenu # "Kernel Testing and Coverage" 2999 3000menu "Rust hacking" 3001 3002config RUST_DEBUG_ASSERTIONS 3003 bool "Debug assertions" 3004 depends on RUST 3005 help 3006 Enables rustc's `-Cdebug-assertions` codegen option. 3007 3008 This flag lets you turn `cfg(debug_assertions)` conditional 3009 compilation on or off. This can be used to enable extra debugging 3010 code in development but not in production. For example, it controls 3011 the behavior of the standard library's `debug_assert!` macro. 3012 3013 Note that this will apply to all Rust code, including `core`. 3014 3015 If unsure, say N. 3016 3017config RUST_OVERFLOW_CHECKS 3018 bool "Overflow checks" 3019 default y 3020 depends on RUST 3021 help 3022 Enables rustc's `-Coverflow-checks` codegen option. 3023 3024 This flag allows you to control the behavior of runtime integer 3025 overflow. When overflow-checks are enabled, a Rust panic will occur 3026 on overflow. 3027 3028 Note that this will apply to all Rust code, including `core`. 3029 3030 If unsure, say Y. 3031 3032config RUST_BUILD_ASSERT_ALLOW 3033 bool "Allow unoptimized build-time assertions" 3034 depends on RUST 3035 help 3036 Controls how are `build_error!` and `build_assert!` handled during build. 3037 3038 If calls to them exist in the binary, it may indicate a violated invariant 3039 or that the optimizer failed to verify the invariant during compilation. 3040 3041 This should not happen, thus by default the build is aborted. However, 3042 as an escape hatch, you can choose Y here to ignore them during build 3043 and let the check be carried at runtime (with `panic!` being called if 3044 the check fails). 3045 3046 If unsure, say N. 3047 3048config RUST_KERNEL_DOCTESTS 3049 bool "Doctests for the `kernel` crate" if !KUNIT_ALL_TESTS 3050 depends on RUST && KUNIT=y 3051 default KUNIT_ALL_TESTS 3052 help 3053 This builds the documentation tests of the `kernel` crate 3054 as KUnit tests. 3055 3056 For more information on KUnit and unit tests in general, 3057 please refer to the KUnit documentation in Documentation/dev-tools/kunit/. 3058 3059 If unsure, say N. 3060 3061endmenu # "Rust" 3062 3063endmenu # Kernel hacking 3064