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