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