Kconfig.debug

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