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