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