cachepc-linux

Fork of AMDESE/linux with modifications for CachePC side-channel attack
git clone https://git.sinitax.com/sinitax/cachepc-linux
Log | Files | Refs | README | LICENSE | sfeed.txt

Kconfig.debug (89460B)


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