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