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