xref: /openbmc/linux/lib/Kconfig.debug (revision 07cc2c93)
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 HAVE_DEBUG_KMEMLEAK
756	bool
757
758config DEBUG_KMEMLEAK
759	bool "Kernel memory leak detector"
760	depends on DEBUG_KERNEL && HAVE_DEBUG_KMEMLEAK
761	select DEBUG_FS
762	select STACKTRACE if STACKTRACE_SUPPORT
763	select KALLSYMS
764	select CRC32
765	select STACKDEPOT
766	help
767	  Say Y here if you want to enable the memory leak
768	  detector. The memory allocation/freeing is traced in a way
769	  similar to the Boehm's conservative garbage collector, the
770	  difference being that the orphan objects are not freed but
771	  only shown in /sys/kernel/debug/kmemleak. Enabling this
772	  feature will introduce an overhead to memory
773	  allocations. See Documentation/dev-tools/kmemleak.rst for more
774	  details.
775
776	  Enabling DEBUG_SLAB or SLUB_DEBUG may increase the chances
777	  of finding leaks due to the slab objects poisoning.
778
779	  In order to access the kmemleak file, debugfs needs to be
780	  mounted (usually at /sys/kernel/debug).
781
782config DEBUG_KMEMLEAK_MEM_POOL_SIZE
783	int "Kmemleak memory pool size"
784	depends on DEBUG_KMEMLEAK
785	range 200 1000000
786	default 16000
787	help
788	  Kmemleak must track all the memory allocations to avoid
789	  reporting false positives. Since memory may be allocated or
790	  freed before kmemleak is fully initialised, use a static pool
791	  of metadata objects to track such callbacks. After kmemleak is
792	  fully initialised, this memory pool acts as an emergency one
793	  if slab allocations fail.
794
795config DEBUG_KMEMLEAK_TEST
796	tristate "Simple test for the kernel memory leak detector"
797	depends on DEBUG_KMEMLEAK && m
798	help
799	  This option enables a module that explicitly leaks memory.
800
801	  If unsure, say N.
802
803config DEBUG_KMEMLEAK_DEFAULT_OFF
804	bool "Default kmemleak to off"
805	depends on DEBUG_KMEMLEAK
806	help
807	  Say Y here to disable kmemleak by default. It can then be enabled
808	  on the command line via kmemleak=on.
809
810config DEBUG_KMEMLEAK_AUTO_SCAN
811	bool "Enable kmemleak auto scan thread on boot up"
812	default y
813	depends on DEBUG_KMEMLEAK
814	help
815	  Depending on the cpu, kmemleak scan may be cpu intensive and can
816	  stall user tasks at times. This option enables/disables automatic
817	  kmemleak scan at boot up.
818
819	  Say N here to disable kmemleak auto scan thread to stop automatic
820	  scanning. Disabling this option disables automatic reporting of
821	  memory leaks.
822
823	  If unsure, say Y.
824
825config DEBUG_STACK_USAGE
826	bool "Stack utilization instrumentation"
827	depends on DEBUG_KERNEL && !IA64
828	help
829	  Enables the display of the minimum amount of free stack which each
830	  task has ever had available in the sysrq-T and sysrq-P debug output.
831
832	  This option will slow down process creation somewhat.
833
834config SCHED_STACK_END_CHECK
835	bool "Detect stack corruption on calls to schedule()"
836	depends on DEBUG_KERNEL
837	default n
838	help
839	  This option checks for a stack overrun on calls to schedule().
840	  If the stack end location is found to be over written always panic as
841	  the content of the corrupted region can no longer be trusted.
842	  This is to ensure no erroneous behaviour occurs which could result in
843	  data corruption or a sporadic crash at a later stage once the region
844	  is examined. The runtime overhead introduced is minimal.
845
846config ARCH_HAS_DEBUG_VM_PGTABLE
847	bool
848	help
849	  An architecture should select this when it can successfully
850	  build and run DEBUG_VM_PGTABLE.
851
852config DEBUG_VM_IRQSOFF
853	def_bool DEBUG_VM && !PREEMPT_RT
854
855config DEBUG_VM
856	bool "Debug VM"
857	depends on DEBUG_KERNEL
858	help
859	  Enable this to turn on extended checks in the virtual-memory system
860	  that may impact performance.
861
862	  If unsure, say N.
863
864config DEBUG_VM_MAPLE_TREE
865	bool "Debug VM maple trees"
866	depends on DEBUG_VM
867	select DEBUG_MAPLE_TREE
868	help
869	  Enable VM maple tree debugging information and extra validations.
870
871	  If unsure, say N.
872
873config DEBUG_VM_RB
874	bool "Debug VM red-black trees"
875	depends on DEBUG_VM
876	help
877	  Enable VM red-black tree debugging information and extra validations.
878
879	  If unsure, say N.
880
881config DEBUG_VM_PGFLAGS
882	bool "Debug page-flags operations"
883	depends on DEBUG_VM
884	help
885	  Enables extra validation on page flags operations.
886
887	  If unsure, say N.
888
889config DEBUG_VM_PGTABLE
890	bool "Debug arch page table for semantics compliance"
891	depends on MMU
892	depends on ARCH_HAS_DEBUG_VM_PGTABLE
893	default y if DEBUG_VM
894	help
895	  This option provides a debug method which can be used to test
896	  architecture page table helper functions on various platforms in
897	  verifying if they comply with expected generic MM semantics. This
898	  will help architecture code in making sure that any changes or
899	  new additions of these helpers still conform to expected
900	  semantics of the generic MM. Platforms will have to opt in for
901	  this through ARCH_HAS_DEBUG_VM_PGTABLE.
902
903	  If unsure, say N.
904
905config ARCH_HAS_DEBUG_VIRTUAL
906	bool
907
908config DEBUG_VIRTUAL
909	bool "Debug VM translations"
910	depends on DEBUG_KERNEL && ARCH_HAS_DEBUG_VIRTUAL
911	help
912	  Enable some costly sanity checks in virtual to page code. This can
913	  catch mistakes with virt_to_page() and friends.
914
915	  If unsure, say N.
916
917config DEBUG_NOMMU_REGIONS
918	bool "Debug the global anon/private NOMMU mapping region tree"
919	depends on DEBUG_KERNEL && !MMU
920	help
921	  This option causes the global tree of anonymous and private mapping
922	  regions to be regularly checked for invalid topology.
923
924config DEBUG_MEMORY_INIT
925	bool "Debug memory initialisation" if EXPERT
926	default !EXPERT
927	help
928	  Enable this for additional checks during memory initialisation.
929	  The sanity checks verify aspects of the VM such as the memory model
930	  and other information provided by the architecture. Verbose
931	  information will be printed at KERN_DEBUG loglevel depending
932	  on the mminit_loglevel= command-line option.
933
934	  If unsure, say Y
935
936config MEMORY_NOTIFIER_ERROR_INJECT
937	tristate "Memory hotplug notifier error injection module"
938	depends on MEMORY_HOTPLUG && NOTIFIER_ERROR_INJECTION
939	help
940	  This option provides the ability to inject artificial errors to
941	  memory hotplug notifier chain callbacks.  It is controlled through
942	  debugfs interface under /sys/kernel/debug/notifier-error-inject/memory
943
944	  If the notifier call chain should be failed with some events
945	  notified, write the error code to "actions/<notifier event>/error".
946
947	  Example: Inject memory hotplug offline error (-12 == -ENOMEM)
948
949	  # cd /sys/kernel/debug/notifier-error-inject/memory
950	  # echo -12 > actions/MEM_GOING_OFFLINE/error
951	  # echo offline > /sys/devices/system/memory/memoryXXX/state
952	  bash: echo: write error: Cannot allocate memory
953
954	  To compile this code as a module, choose M here: the module will
955	  be called memory-notifier-error-inject.
956
957	  If unsure, say N.
958
959config DEBUG_PER_CPU_MAPS
960	bool "Debug access to per_cpu maps"
961	depends on DEBUG_KERNEL
962	depends on SMP
963	help
964	  Say Y to verify that the per_cpu map being accessed has
965	  been set up. This adds a fair amount of code to kernel memory
966	  and decreases performance.
967
968	  Say N if unsure.
969
970config DEBUG_KMAP_LOCAL
971	bool "Debug kmap_local temporary mappings"
972	depends on DEBUG_KERNEL && KMAP_LOCAL
973	help
974	  This option enables additional error checking for the kmap_local
975	  infrastructure.  Disable for production use.
976
977config ARCH_SUPPORTS_KMAP_LOCAL_FORCE_MAP
978	bool
979
980config DEBUG_KMAP_LOCAL_FORCE_MAP
981	bool "Enforce kmap_local temporary mappings"
982	depends on DEBUG_KERNEL && ARCH_SUPPORTS_KMAP_LOCAL_FORCE_MAP
983	select KMAP_LOCAL
984	select DEBUG_KMAP_LOCAL
985	help
986	  This option enforces temporary mappings through the kmap_local
987	  mechanism for non-highmem pages and on non-highmem systems.
988	  Disable this for production systems!
989
990config DEBUG_HIGHMEM
991	bool "Highmem debugging"
992	depends on DEBUG_KERNEL && HIGHMEM
993	select DEBUG_KMAP_LOCAL_FORCE_MAP if ARCH_SUPPORTS_KMAP_LOCAL_FORCE_MAP
994	select DEBUG_KMAP_LOCAL
995	help
996	  This option enables additional error checking for high memory
997	  systems.  Disable for production systems.
998
999config HAVE_DEBUG_STACKOVERFLOW
1000	bool
1001
1002config DEBUG_STACKOVERFLOW
1003	bool "Check for stack overflows"
1004	depends on DEBUG_KERNEL && HAVE_DEBUG_STACKOVERFLOW
1005	help
1006	  Say Y here if you want to check for overflows of kernel, IRQ
1007	  and exception stacks (if your architecture uses them). This
1008	  option will show detailed messages if free stack space drops
1009	  below a certain limit.
1010
1011	  These kinds of bugs usually occur when call-chains in the
1012	  kernel get too deep, especially when interrupts are
1013	  involved.
1014
1015	  Use this in cases where you see apparently random memory
1016	  corruption, especially if it appears in 'struct thread_info'
1017
1018	  If in doubt, say "N".
1019
1020source "lib/Kconfig.kasan"
1021source "lib/Kconfig.kfence"
1022source "lib/Kconfig.kmsan"
1023
1024endmenu # "Memory Debugging"
1025
1026config DEBUG_SHIRQ
1027	bool "Debug shared IRQ handlers"
1028	depends on DEBUG_KERNEL
1029	help
1030	  Enable this to generate a spurious interrupt just before a shared
1031	  interrupt handler is deregistered (generating one when registering
1032	  is currently disabled). Drivers need to handle this correctly. Some
1033	  don't and need to be caught.
1034
1035menu "Debug Oops, Lockups and Hangs"
1036
1037config PANIC_ON_OOPS
1038	bool "Panic on Oops"
1039	help
1040	  Say Y here to enable the kernel to panic when it oopses. This
1041	  has the same effect as setting oops=panic on the kernel command
1042	  line.
1043
1044	  This feature is useful to ensure that the kernel does not do
1045	  anything erroneous after an oops which could result in data
1046	  corruption or other issues.
1047
1048	  Say N if unsure.
1049
1050config PANIC_ON_OOPS_VALUE
1051	int
1052	range 0 1
1053	default 0 if !PANIC_ON_OOPS
1054	default 1 if PANIC_ON_OOPS
1055
1056config PANIC_TIMEOUT
1057	int "panic timeout"
1058	default 0
1059	help
1060	  Set the timeout value (in seconds) until a reboot occurs when
1061	  the kernel panics. If n = 0, then we wait forever. A timeout
1062	  value n > 0 will wait n seconds before rebooting, while a timeout
1063	  value n < 0 will reboot immediately.
1064
1065config LOCKUP_DETECTOR
1066	bool
1067
1068config SOFTLOCKUP_DETECTOR
1069	bool "Detect Soft Lockups"
1070	depends on DEBUG_KERNEL && !S390
1071	select LOCKUP_DETECTOR
1072	help
1073	  Say Y here to enable the kernel to act as a watchdog to detect
1074	  soft lockups.
1075
1076	  Softlockups are bugs that cause the kernel to loop in kernel
1077	  mode for more than 20 seconds, without giving other tasks a
1078	  chance to run.  The current stack trace is displayed upon
1079	  detection and the system will stay locked up.
1080
1081config BOOTPARAM_SOFTLOCKUP_PANIC
1082	bool "Panic (Reboot) On Soft Lockups"
1083	depends on SOFTLOCKUP_DETECTOR
1084	help
1085	  Say Y here to enable the kernel to panic on "soft lockups",
1086	  which are bugs that cause the kernel to loop in kernel
1087	  mode for more than 20 seconds (configurable using the watchdog_thresh
1088	  sysctl), without giving other tasks a chance to run.
1089
1090	  The panic can be used in combination with panic_timeout,
1091	  to cause the system to reboot automatically after a
1092	  lockup has been detected. This feature is useful for
1093	  high-availability systems that have uptime guarantees and
1094	  where a lockup must be resolved ASAP.
1095
1096	  Say N if unsure.
1097
1098config HARDLOCKUP_DETECTOR_PERF
1099	bool
1100	select SOFTLOCKUP_DETECTOR
1101
1102#
1103# Enables a timestamp based low pass filter to compensate for perf based
1104# hard lockup detection which runs too fast due to turbo modes.
1105#
1106config HARDLOCKUP_CHECK_TIMESTAMP
1107	bool
1108
1109#
1110# arch/ can define HAVE_HARDLOCKUP_DETECTOR_ARCH to provide their own hard
1111# lockup detector rather than the perf based detector.
1112#
1113config HARDLOCKUP_DETECTOR
1114	bool "Detect Hard Lockups"
1115	depends on DEBUG_KERNEL && !S390
1116	depends on HAVE_HARDLOCKUP_DETECTOR_PERF || HAVE_HARDLOCKUP_DETECTOR_ARCH
1117	select LOCKUP_DETECTOR
1118	select HARDLOCKUP_DETECTOR_PERF if HAVE_HARDLOCKUP_DETECTOR_PERF
1119	help
1120	  Say Y here to enable the kernel to act as a watchdog to detect
1121	  hard lockups.
1122
1123	  Hardlockups are bugs that cause the CPU to loop in kernel mode
1124	  for more than 10 seconds, without letting other interrupts have a
1125	  chance to run.  The current stack trace is displayed upon detection
1126	  and the system will stay locked up.
1127
1128config BOOTPARAM_HARDLOCKUP_PANIC
1129	bool "Panic (Reboot) On Hard Lockups"
1130	depends on HARDLOCKUP_DETECTOR
1131	help
1132	  Say Y here to enable the kernel to panic on "hard lockups",
1133	  which are bugs that cause the kernel to loop in kernel
1134	  mode with interrupts disabled for more than 10 seconds (configurable
1135	  using the watchdog_thresh sysctl).
1136
1137	  Say N if unsure.
1138
1139config DETECT_HUNG_TASK
1140	bool "Detect Hung Tasks"
1141	depends on DEBUG_KERNEL
1142	default SOFTLOCKUP_DETECTOR
1143	help
1144	  Say Y here to enable the kernel to detect "hung tasks",
1145	  which are bugs that cause the task to be stuck in
1146	  uninterruptible "D" state indefinitely.
1147
1148	  When a hung task is detected, the kernel will print the
1149	  current stack trace (which you should report), but the
1150	  task will stay in uninterruptible state. If lockdep is
1151	  enabled then all held locks will also be reported. This
1152	  feature has negligible overhead.
1153
1154config DEFAULT_HUNG_TASK_TIMEOUT
1155	int "Default timeout for hung task detection (in seconds)"
1156	depends on DETECT_HUNG_TASK
1157	default 120
1158	help
1159	  This option controls the default timeout (in seconds) used
1160	  to determine when a task has become non-responsive and should
1161	  be considered hung.
1162
1163	  It can be adjusted at runtime via the kernel.hung_task_timeout_secs
1164	  sysctl or by writing a value to
1165	  /proc/sys/kernel/hung_task_timeout_secs.
1166
1167	  A timeout of 0 disables the check.  The default is two minutes.
1168	  Keeping the default should be fine in most cases.
1169
1170config BOOTPARAM_HUNG_TASK_PANIC
1171	bool "Panic (Reboot) On Hung Tasks"
1172	depends on DETECT_HUNG_TASK
1173	help
1174	  Say Y here to enable the kernel to panic on "hung tasks",
1175	  which are bugs that cause the kernel to leave a task stuck
1176	  in uninterruptible "D" state.
1177
1178	  The panic can be used in combination with panic_timeout,
1179	  to cause the system to reboot automatically after a
1180	  hung task has been detected. This feature is useful for
1181	  high-availability systems that have uptime guarantees and
1182	  where a hung tasks must be resolved ASAP.
1183
1184	  Say N if unsure.
1185
1186config WQ_WATCHDOG
1187	bool "Detect Workqueue Stalls"
1188	depends on DEBUG_KERNEL
1189	help
1190	  Say Y here to enable stall detection on workqueues.  If a
1191	  worker pool doesn't make forward progress on a pending work
1192	  item for over a given amount of time, 30s by default, a
1193	  warning message is printed along with dump of workqueue
1194	  state.  This can be configured through kernel parameter
1195	  "workqueue.watchdog_thresh" and its sysfs counterpart.
1196
1197config TEST_LOCKUP
1198	tristate "Test module to generate lockups"
1199	depends on m
1200	help
1201	  This builds the "test_lockup" module that helps to make sure
1202	  that watchdogs and lockup detectors are working properly.
1203
1204	  Depending on module parameters it could emulate soft or hard
1205	  lockup, "hung task", or locking arbitrary lock for a long time.
1206	  Also it could generate series of lockups with cooling-down periods.
1207
1208	  If unsure, say N.
1209
1210endmenu # "Debug lockups and hangs"
1211
1212menu "Scheduler Debugging"
1213
1214config SCHED_DEBUG
1215	bool "Collect scheduler debugging info"
1216	depends on DEBUG_KERNEL && PROC_FS
1217	default y
1218	help
1219	  If you say Y here, the /proc/sched_debug file will be provided
1220	  that can help debug the scheduler. The runtime overhead of this
1221	  option is minimal.
1222
1223config SCHED_INFO
1224	bool
1225	default n
1226
1227config SCHEDSTATS
1228	bool "Collect scheduler statistics"
1229	depends on DEBUG_KERNEL && PROC_FS
1230	select SCHED_INFO
1231	help
1232	  If you say Y here, additional code will be inserted into the
1233	  scheduler and related routines to collect statistics about
1234	  scheduler behavior and provide them in /proc/schedstat.  These
1235	  stats may be useful for both tuning and debugging the scheduler
1236	  If you aren't debugging the scheduler or trying to tune a specific
1237	  application, you can say N to avoid the very slight overhead
1238	  this adds.
1239
1240endmenu
1241
1242config DEBUG_TIMEKEEPING
1243	bool "Enable extra timekeeping sanity checking"
1244	help
1245	  This option will enable additional timekeeping sanity checks
1246	  which may be helpful when diagnosing issues where timekeeping
1247	  problems are suspected.
1248
1249	  This may include checks in the timekeeping hotpaths, so this
1250	  option may have a (very small) performance impact to some
1251	  workloads.
1252
1253	  If unsure, say N.
1254
1255config DEBUG_PREEMPT
1256	bool "Debug preemptible kernel"
1257	depends on DEBUG_KERNEL && PREEMPTION && TRACE_IRQFLAGS_SUPPORT
1258	default y
1259	help
1260	  If you say Y here then the kernel will use a debug variant of the
1261	  commonly used smp_processor_id() function and will print warnings
1262	  if kernel code uses it in a preemption-unsafe way. Also, the kernel
1263	  will detect preemption count underflows.
1264
1265menu "Lock Debugging (spinlocks, mutexes, etc...)"
1266
1267config LOCK_DEBUGGING_SUPPORT
1268	bool
1269	depends on TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
1270	default y
1271
1272config PROVE_LOCKING
1273	bool "Lock debugging: prove locking correctness"
1274	depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
1275	select LOCKDEP
1276	select DEBUG_SPINLOCK
1277	select DEBUG_MUTEXES if !PREEMPT_RT
1278	select DEBUG_RT_MUTEXES if RT_MUTEXES
1279	select DEBUG_RWSEMS
1280	select DEBUG_WW_MUTEX_SLOWPATH
1281	select DEBUG_LOCK_ALLOC
1282	select PREEMPT_COUNT if !ARCH_NO_PREEMPT
1283	select TRACE_IRQFLAGS
1284	default n
1285	help
1286	 This feature enables the kernel to prove that all locking
1287	 that occurs in the kernel runtime is mathematically
1288	 correct: that under no circumstance could an arbitrary (and
1289	 not yet triggered) combination of observed locking
1290	 sequences (on an arbitrary number of CPUs, running an
1291	 arbitrary number of tasks and interrupt contexts) cause a
1292	 deadlock.
1293
1294	 In short, this feature enables the kernel to report locking
1295	 related deadlocks before they actually occur.
1296
1297	 The proof does not depend on how hard and complex a
1298	 deadlock scenario would be to trigger: how many
1299	 participant CPUs, tasks and irq-contexts would be needed
1300	 for it to trigger. The proof also does not depend on
1301	 timing: if a race and a resulting deadlock is possible
1302	 theoretically (no matter how unlikely the race scenario
1303	 is), it will be proven so and will immediately be
1304	 reported by the kernel (once the event is observed that
1305	 makes the deadlock theoretically possible).
1306
1307	 If a deadlock is impossible (i.e. the locking rules, as
1308	 observed by the kernel, are mathematically correct), the
1309	 kernel reports nothing.
1310
1311	 NOTE: this feature can also be enabled for rwlocks, mutexes
1312	 and rwsems - in which case all dependencies between these
1313	 different locking variants are observed and mapped too, and
1314	 the proof of observed correctness is also maintained for an
1315	 arbitrary combination of these separate locking variants.
1316
1317	 For more details, see Documentation/locking/lockdep-design.rst.
1318
1319config PROVE_RAW_LOCK_NESTING
1320	bool "Enable raw_spinlock - spinlock nesting checks"
1321	depends on PROVE_LOCKING
1322	default n
1323	help
1324	 Enable the raw_spinlock vs. spinlock nesting checks which ensure
1325	 that the lock nesting rules for PREEMPT_RT enabled kernels are
1326	 not violated.
1327
1328	 NOTE: There are known nesting problems. So if you enable this
1329	 option expect lockdep splats until these problems have been fully
1330	 addressed which is work in progress. This config switch allows to
1331	 identify and analyze these problems. It will be removed and the
1332	 check permanently enabled once the main issues have been fixed.
1333
1334	 If unsure, select N.
1335
1336config LOCK_STAT
1337	bool "Lock usage statistics"
1338	depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
1339	select LOCKDEP
1340	select DEBUG_SPINLOCK
1341	select DEBUG_MUTEXES if !PREEMPT_RT
1342	select DEBUG_RT_MUTEXES if RT_MUTEXES
1343	select DEBUG_LOCK_ALLOC
1344	default n
1345	help
1346	 This feature enables tracking lock contention points
1347
1348	 For more details, see Documentation/locking/lockstat.rst
1349
1350	 This also enables lock events required by "perf lock",
1351	 subcommand of perf.
1352	 If you want to use "perf lock", you also need to turn on
1353	 CONFIG_EVENT_TRACING.
1354
1355	 CONFIG_LOCK_STAT defines "contended" and "acquired" lock events.
1356	 (CONFIG_LOCKDEP defines "acquire" and "release" events.)
1357
1358config DEBUG_RT_MUTEXES
1359	bool "RT Mutex debugging, deadlock detection"
1360	depends on DEBUG_KERNEL && RT_MUTEXES
1361	help
1362	 This allows rt mutex semantics violations and rt mutex related
1363	 deadlocks (lockups) to be detected and reported automatically.
1364
1365config DEBUG_SPINLOCK
1366	bool "Spinlock and rw-lock debugging: basic checks"
1367	depends on DEBUG_KERNEL
1368	select UNINLINE_SPIN_UNLOCK
1369	help
1370	  Say Y here and build SMP to catch missing spinlock initialization
1371	  and certain other kinds of spinlock errors commonly made.  This is
1372	  best used in conjunction with the NMI watchdog so that spinlock
1373	  deadlocks are also debuggable.
1374
1375config DEBUG_MUTEXES
1376	bool "Mutex debugging: basic checks"
1377	depends on DEBUG_KERNEL && !PREEMPT_RT
1378	help
1379	 This feature allows mutex semantics violations to be detected and
1380	 reported.
1381
1382config DEBUG_WW_MUTEX_SLOWPATH
1383	bool "Wait/wound mutex debugging: Slowpath testing"
1384	depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
1385	select DEBUG_LOCK_ALLOC
1386	select DEBUG_SPINLOCK
1387	select DEBUG_MUTEXES if !PREEMPT_RT
1388	select DEBUG_RT_MUTEXES if PREEMPT_RT
1389	help
1390	 This feature enables slowpath testing for w/w mutex users by
1391	 injecting additional -EDEADLK wound/backoff cases. Together with
1392	 the full mutex checks enabled with (CONFIG_PROVE_LOCKING) this
1393	 will test all possible w/w mutex interface abuse with the
1394	 exception of simply not acquiring all the required locks.
1395	 Note that this feature can introduce significant overhead, so
1396	 it really should not be enabled in a production or distro kernel,
1397	 even a debug kernel.  If you are a driver writer, enable it.  If
1398	 you are a distro, do not.
1399
1400config DEBUG_RWSEMS
1401	bool "RW Semaphore debugging: basic checks"
1402	depends on DEBUG_KERNEL
1403	help
1404	  This debugging feature allows mismatched rw semaphore locks
1405	  and unlocks to be detected and reported.
1406
1407config DEBUG_LOCK_ALLOC
1408	bool "Lock debugging: detect incorrect freeing of live locks"
1409	depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
1410	select DEBUG_SPINLOCK
1411	select DEBUG_MUTEXES if !PREEMPT_RT
1412	select DEBUG_RT_MUTEXES if RT_MUTEXES
1413	select LOCKDEP
1414	help
1415	 This feature will check whether any held lock (spinlock, rwlock,
1416	 mutex or rwsem) is incorrectly freed by the kernel, via any of the
1417	 memory-freeing routines (kfree(), kmem_cache_free(), free_pages(),
1418	 vfree(), etc.), whether a live lock is incorrectly reinitialized via
1419	 spin_lock_init()/mutex_init()/etc., or whether there is any lock
1420	 held during task exit.
1421
1422config LOCKDEP
1423	bool
1424	depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
1425	select STACKTRACE
1426	select KALLSYMS
1427	select KALLSYMS_ALL
1428
1429config LOCKDEP_SMALL
1430	bool
1431
1432config LOCKDEP_BITS
1433	int "Bitsize for MAX_LOCKDEP_ENTRIES"
1434	depends on LOCKDEP && !LOCKDEP_SMALL
1435	range 10 30
1436	default 15
1437	help
1438	  Try increasing this value if you hit "BUG: MAX_LOCKDEP_ENTRIES too low!" message.
1439
1440config LOCKDEP_CHAINS_BITS
1441	int "Bitsize for MAX_LOCKDEP_CHAINS"
1442	depends on LOCKDEP && !LOCKDEP_SMALL
1443	range 10 30
1444	default 16
1445	help
1446	  Try increasing this value if you hit "BUG: MAX_LOCKDEP_CHAINS too low!" message.
1447
1448config LOCKDEP_STACK_TRACE_BITS
1449	int "Bitsize for MAX_STACK_TRACE_ENTRIES"
1450	depends on LOCKDEP && !LOCKDEP_SMALL
1451	range 10 30
1452	default 19
1453	help
1454	  Try increasing this value if you hit "BUG: MAX_STACK_TRACE_ENTRIES too low!" message.
1455
1456config LOCKDEP_STACK_TRACE_HASH_BITS
1457	int "Bitsize for STACK_TRACE_HASH_SIZE"
1458	depends on LOCKDEP && !LOCKDEP_SMALL
1459	range 10 30
1460	default 14
1461	help
1462	  Try increasing this value if you need large MAX_STACK_TRACE_ENTRIES.
1463
1464config LOCKDEP_CIRCULAR_QUEUE_BITS
1465	int "Bitsize for elements in circular_queue struct"
1466	depends on LOCKDEP
1467	range 10 30
1468	default 12
1469	help
1470	  Try increasing this value if you hit "lockdep bfs error:-1" warning due to __cq_enqueue() failure.
1471
1472config DEBUG_LOCKDEP
1473	bool "Lock dependency engine debugging"
1474	depends on DEBUG_KERNEL && LOCKDEP
1475	select DEBUG_IRQFLAGS
1476	help
1477	  If you say Y here, the lock dependency engine will do
1478	  additional runtime checks to debug itself, at the price
1479	  of more runtime overhead.
1480
1481config DEBUG_ATOMIC_SLEEP
1482	bool "Sleep inside atomic section checking"
1483	select PREEMPT_COUNT
1484	depends on DEBUG_KERNEL
1485	depends on !ARCH_NO_PREEMPT
1486	help
1487	  If you say Y here, various routines which may sleep will become very
1488	  noisy if they are called inside atomic sections: when a spinlock is
1489	  held, inside an rcu read side critical section, inside preempt disabled
1490	  sections, inside an interrupt, etc...
1491
1492config DEBUG_LOCKING_API_SELFTESTS
1493	bool "Locking API boot-time self-tests"
1494	depends on DEBUG_KERNEL
1495	help
1496	  Say Y here if you want the kernel to run a short self-test during
1497	  bootup. The self-test checks whether common types of locking bugs
1498	  are detected by debugging mechanisms or not. (if you disable
1499	  lock debugging then those bugs won't be detected of course.)
1500	  The following locking APIs are covered: spinlocks, rwlocks,
1501	  mutexes and rwsems.
1502
1503config LOCK_TORTURE_TEST
1504	tristate "torture tests for locking"
1505	depends on DEBUG_KERNEL
1506	select TORTURE_TEST
1507	help
1508	  This option provides a kernel module that runs torture tests
1509	  on kernel locking primitives.  The kernel module may be built
1510	  after the fact on the running kernel to be tested, if desired.
1511
1512	  Say Y here if you want kernel locking-primitive torture tests
1513	  to be built into the kernel.
1514	  Say M if you want these torture tests to build as a module.
1515	  Say N if you are unsure.
1516
1517config WW_MUTEX_SELFTEST
1518	tristate "Wait/wound mutex selftests"
1519	help
1520	  This option provides a kernel module that runs tests on the
1521	  on the struct ww_mutex locking API.
1522
1523	  It is recommended to enable DEBUG_WW_MUTEX_SLOWPATH in conjunction
1524	  with this test harness.
1525
1526	  Say M if you want these self tests to build as a module.
1527	  Say N if you are unsure.
1528
1529config SCF_TORTURE_TEST
1530	tristate "torture tests for smp_call_function*()"
1531	depends on DEBUG_KERNEL
1532	select TORTURE_TEST
1533	help
1534	  This option provides a kernel module that runs torture tests
1535	  on the smp_call_function() family of primitives.  The kernel
1536	  module may be built after the fact on the running kernel to
1537	  be tested, if desired.
1538
1539config CSD_LOCK_WAIT_DEBUG
1540	bool "Debugging for csd_lock_wait(), called from smp_call_function*()"
1541	depends on DEBUG_KERNEL
1542	depends on 64BIT
1543	default n
1544	help
1545	  This option enables debug prints when CPUs are slow to respond
1546	  to the smp_call_function*() IPI wrappers.  These debug prints
1547	  include the IPI handler function currently executing (if any)
1548	  and relevant stack traces.
1549
1550endmenu # lock debugging
1551
1552config TRACE_IRQFLAGS
1553	depends on TRACE_IRQFLAGS_SUPPORT
1554	bool
1555	help
1556	  Enables hooks to interrupt enabling and disabling for
1557	  either tracing or lock debugging.
1558
1559config TRACE_IRQFLAGS_NMI
1560	def_bool y
1561	depends on TRACE_IRQFLAGS
1562	depends on TRACE_IRQFLAGS_NMI_SUPPORT
1563
1564config DEBUG_IRQFLAGS
1565	bool "Debug IRQ flag manipulation"
1566	help
1567	  Enables checks for potentially unsafe enabling or disabling of
1568	  interrupts, such as calling raw_local_irq_restore() when interrupts
1569	  are enabled.
1570
1571config STACKTRACE
1572	bool "Stack backtrace support"
1573	depends on STACKTRACE_SUPPORT
1574	help
1575	  This option causes the kernel to create a /proc/pid/stack for
1576	  every process, showing its current stack trace.
1577	  It is also used by various kernel debugging features that require
1578	  stack trace generation.
1579
1580config WARN_ALL_UNSEEDED_RANDOM
1581	bool "Warn for all uses of unseeded randomness"
1582	default n
1583	help
1584	  Some parts of the kernel contain bugs relating to their use of
1585	  cryptographically secure random numbers before it's actually possible
1586	  to generate those numbers securely. This setting ensures that these
1587	  flaws don't go unnoticed, by enabling a message, should this ever
1588	  occur. This will allow people with obscure setups to know when things
1589	  are going wrong, so that they might contact developers about fixing
1590	  it.
1591
1592	  Unfortunately, on some models of some architectures getting
1593	  a fully seeded CRNG is extremely difficult, and so this can
1594	  result in dmesg getting spammed for a surprisingly long
1595	  time.  This is really bad from a security perspective, and
1596	  so architecture maintainers really need to do what they can
1597	  to get the CRNG seeded sooner after the system is booted.
1598	  However, since users cannot do anything actionable to
1599	  address this, by default this option is disabled.
1600
1601	  Say Y here if you want to receive warnings for all uses of
1602	  unseeded randomness.  This will be of use primarily for
1603	  those developers interested in improving the security of
1604	  Linux kernels running on their architecture (or
1605	  subarchitecture).
1606
1607config DEBUG_KOBJECT
1608	bool "kobject debugging"
1609	depends on DEBUG_KERNEL
1610	help
1611	  If you say Y here, some extra kobject debugging messages will be sent
1612	  to the syslog.
1613
1614config DEBUG_KOBJECT_RELEASE
1615	bool "kobject release debugging"
1616	depends on DEBUG_OBJECTS_TIMERS
1617	help
1618	  kobjects are reference counted objects.  This means that their
1619	  last reference count put is not predictable, and the kobject can
1620	  live on past the point at which a driver decides to drop its
1621	  initial reference to the kobject gained on allocation.  An
1622	  example of this would be a struct device which has just been
1623	  unregistered.
1624
1625	  However, some buggy drivers assume that after such an operation,
1626	  the memory backing the kobject can be immediately freed.  This
1627	  goes completely against the principles of a refcounted object.
1628
1629	  If you say Y here, the kernel will delay the release of kobjects
1630	  on the last reference count to improve the visibility of this
1631	  kind of kobject release bug.
1632
1633config HAVE_DEBUG_BUGVERBOSE
1634	bool
1635
1636menu "Debug kernel data structures"
1637
1638config DEBUG_LIST
1639	bool "Debug linked list manipulation"
1640	depends on DEBUG_KERNEL || BUG_ON_DATA_CORRUPTION
1641	help
1642	  Enable this to turn on extended checks in the linked-list
1643	  walking routines.
1644
1645	  If unsure, say N.
1646
1647config DEBUG_PLIST
1648	bool "Debug priority linked list manipulation"
1649	depends on DEBUG_KERNEL
1650	help
1651	  Enable this to turn on extended checks in the priority-ordered
1652	  linked-list (plist) walking routines.  This checks the entire
1653	  list multiple times during each manipulation.
1654
1655	  If unsure, say N.
1656
1657config DEBUG_SG
1658	bool "Debug SG table operations"
1659	depends on DEBUG_KERNEL
1660	help
1661	  Enable this to turn on checks on scatter-gather tables. This can
1662	  help find problems with drivers that do not properly initialize
1663	  their sg tables.
1664
1665	  If unsure, say N.
1666
1667config DEBUG_NOTIFIERS
1668	bool "Debug notifier call chains"
1669	depends on DEBUG_KERNEL
1670	help
1671	  Enable this to turn on sanity checking for notifier call chains.
1672	  This is most useful for kernel developers to make sure that
1673	  modules properly unregister themselves from notifier chains.
1674	  This is a relatively cheap check but if you care about maximum
1675	  performance, say N.
1676
1677config BUG_ON_DATA_CORRUPTION
1678	bool "Trigger a BUG when data corruption is detected"
1679	select DEBUG_LIST
1680	help
1681	  Select this option if the kernel should BUG when it encounters
1682	  data corruption in kernel memory structures when they get checked
1683	  for validity.
1684
1685	  If unsure, say N.
1686
1687config DEBUG_MAPLE_TREE
1688	bool "Debug maple trees"
1689	depends on DEBUG_KERNEL
1690	help
1691	  Enable maple tree debugging information and extra validations.
1692
1693	  If unsure, say N.
1694
1695endmenu
1696
1697config DEBUG_CREDENTIALS
1698	bool "Debug credential management"
1699	depends on DEBUG_KERNEL
1700	help
1701	  Enable this to turn on some debug checking for credential
1702	  management.  The additional code keeps track of the number of
1703	  pointers from task_structs to any given cred struct, and checks to
1704	  see that this number never exceeds the usage count of the cred
1705	  struct.
1706
1707	  Furthermore, if SELinux is enabled, this also checks that the
1708	  security pointer in the cred struct is never seen to be invalid.
1709
1710	  If unsure, say N.
1711
1712source "kernel/rcu/Kconfig.debug"
1713
1714config DEBUG_WQ_FORCE_RR_CPU
1715	bool "Force round-robin CPU selection for unbound work items"
1716	depends on DEBUG_KERNEL
1717	default n
1718	help
1719	  Workqueue used to implicitly guarantee that work items queued
1720	  without explicit CPU specified are put on the local CPU.  This
1721	  guarantee is no longer true and while local CPU is still
1722	  preferred work items may be put on foreign CPUs.  Kernel
1723	  parameter "workqueue.debug_force_rr_cpu" is added to force
1724	  round-robin CPU selection to flush out usages which depend on the
1725	  now broken guarantee.  This config option enables the debug
1726	  feature by default.  When enabled, memory and cache locality will
1727	  be impacted.
1728
1729config CPU_HOTPLUG_STATE_CONTROL
1730	bool "Enable CPU hotplug state control"
1731	depends on DEBUG_KERNEL
1732	depends on HOTPLUG_CPU
1733	default n
1734	help
1735	  Allows to write steps between "offline" and "online" to the CPUs
1736	  sysfs target file so states can be stepped granular. This is a debug
1737	  option for now as the hotplug machinery cannot be stopped and
1738	  restarted at arbitrary points yet.
1739
1740	  Say N if your are unsure.
1741
1742config LATENCYTOP
1743	bool "Latency measuring infrastructure"
1744	depends on DEBUG_KERNEL
1745	depends on STACKTRACE_SUPPORT
1746	depends on PROC_FS
1747	depends on FRAME_POINTER || MIPS || PPC || S390 || MICROBLAZE || ARM || ARC || X86
1748	select KALLSYMS
1749	select KALLSYMS_ALL
1750	select STACKTRACE
1751	select SCHEDSTATS
1752	help
1753	  Enable this option if you want to use the LatencyTOP tool
1754	  to find out which userspace is blocking on what kernel operations.
1755
1756config DEBUG_CGROUP_REF
1757	bool "Disable inlining of cgroup css reference count functions"
1758	depends on DEBUG_KERNEL
1759	depends on CGROUPS
1760	depends on KPROBES
1761	default n
1762	help
1763	  Force cgroup css reference count functions to not be inlined so
1764	  that they can be kprobed for debugging.
1765
1766source "kernel/trace/Kconfig"
1767
1768config PROVIDE_OHCI1394_DMA_INIT
1769	bool "Remote debugging over FireWire early on boot"
1770	depends on PCI && X86
1771	help
1772	  If you want to debug problems which hang or crash the kernel early
1773	  on boot and the crashing machine has a FireWire port, you can use
1774	  this feature to remotely access the memory of the crashed machine
1775	  over FireWire. This employs remote DMA as part of the OHCI1394
1776	  specification which is now the standard for FireWire controllers.
1777
1778	  With remote DMA, you can monitor the printk buffer remotely using
1779	  firescope and access all memory below 4GB using fireproxy from gdb.
1780	  Even controlling a kernel debugger is possible using remote DMA.
1781
1782	  Usage:
1783
1784	  If ohci1394_dma=early is used as boot parameter, it will initialize
1785	  all OHCI1394 controllers which are found in the PCI config space.
1786
1787	  As all changes to the FireWire bus such as enabling and disabling
1788	  devices cause a bus reset and thereby disable remote DMA for all
1789	  devices, be sure to have the cable plugged and FireWire enabled on
1790	  the debugging host before booting the debug target for debugging.
1791
1792	  This code (~1k) is freed after boot. By then, the firewire stack
1793	  in charge of the OHCI-1394 controllers should be used instead.
1794
1795	  See Documentation/core-api/debugging-via-ohci1394.rst for more information.
1796
1797source "samples/Kconfig"
1798
1799config ARCH_HAS_DEVMEM_IS_ALLOWED
1800	bool
1801
1802config STRICT_DEVMEM
1803	bool "Filter access to /dev/mem"
1804	depends on MMU && DEVMEM
1805	depends on ARCH_HAS_DEVMEM_IS_ALLOWED || GENERIC_LIB_DEVMEM_IS_ALLOWED
1806	default y if PPC || X86 || ARM64
1807	help
1808	  If this option is disabled, you allow userspace (root) access to all
1809	  of memory, including kernel and userspace memory. Accidental
1810	  access to this is obviously disastrous, but specific access can
1811	  be used by people debugging the kernel. Note that with PAT support
1812	  enabled, even in this case there are restrictions on /dev/mem
1813	  use due to the cache aliasing requirements.
1814
1815	  If this option is switched on, and IO_STRICT_DEVMEM=n, the /dev/mem
1816	  file only allows userspace access to PCI space and the BIOS code and
1817	  data regions.  This is sufficient for dosemu and X and all common
1818	  users of /dev/mem.
1819
1820	  If in doubt, say Y.
1821
1822config IO_STRICT_DEVMEM
1823	bool "Filter I/O access to /dev/mem"
1824	depends on STRICT_DEVMEM
1825	help
1826	  If this option is disabled, you allow userspace (root) access to all
1827	  io-memory regardless of whether a driver is actively using that
1828	  range.  Accidental access to this is obviously disastrous, but
1829	  specific access can be used by people debugging kernel drivers.
1830
1831	  If this option is switched on, the /dev/mem file only allows
1832	  userspace access to *idle* io-memory ranges (see /proc/iomem) This
1833	  may break traditional users of /dev/mem (dosemu, legacy X, etc...)
1834	  if the driver using a given range cannot be disabled.
1835
1836	  If in doubt, say Y.
1837
1838menu "$(SRCARCH) Debugging"
1839
1840source "arch/$(SRCARCH)/Kconfig.debug"
1841
1842endmenu
1843
1844menu "Kernel Testing and Coverage"
1845
1846source "lib/kunit/Kconfig"
1847
1848config NOTIFIER_ERROR_INJECTION
1849	tristate "Notifier error injection"
1850	depends on DEBUG_KERNEL
1851	select DEBUG_FS
1852	help
1853	  This option provides the ability to inject artificial errors to
1854	  specified notifier chain callbacks. It is useful to test the error
1855	  handling of notifier call chain failures.
1856
1857	  Say N if unsure.
1858
1859config PM_NOTIFIER_ERROR_INJECT
1860	tristate "PM notifier error injection module"
1861	depends on PM && NOTIFIER_ERROR_INJECTION
1862	default m if PM_DEBUG
1863	help
1864	  This option provides the ability to inject artificial errors to
1865	  PM notifier chain callbacks.  It is controlled through debugfs
1866	  interface /sys/kernel/debug/notifier-error-inject/pm
1867
1868	  If the notifier call chain should be failed with some events
1869	  notified, write the error code to "actions/<notifier event>/error".
1870
1871	  Example: Inject PM suspend error (-12 = -ENOMEM)
1872
1873	  # cd /sys/kernel/debug/notifier-error-inject/pm/
1874	  # echo -12 > actions/PM_SUSPEND_PREPARE/error
1875	  # echo mem > /sys/power/state
1876	  bash: echo: write error: Cannot allocate memory
1877
1878	  To compile this code as a module, choose M here: the module will
1879	  be called pm-notifier-error-inject.
1880
1881	  If unsure, say N.
1882
1883config OF_RECONFIG_NOTIFIER_ERROR_INJECT
1884	tristate "OF reconfig notifier error injection module"
1885	depends on OF_DYNAMIC && NOTIFIER_ERROR_INJECTION
1886	help
1887	  This option provides the ability to inject artificial errors to
1888	  OF reconfig notifier chain callbacks.  It is controlled
1889	  through debugfs interface under
1890	  /sys/kernel/debug/notifier-error-inject/OF-reconfig/
1891
1892	  If the notifier call chain should be failed with some events
1893	  notified, write the error code to "actions/<notifier event>/error".
1894
1895	  To compile this code as a module, choose M here: the module will
1896	  be called of-reconfig-notifier-error-inject.
1897
1898	  If unsure, say N.
1899
1900config NETDEV_NOTIFIER_ERROR_INJECT
1901	tristate "Netdev notifier error injection module"
1902	depends on NET && NOTIFIER_ERROR_INJECTION
1903	help
1904	  This option provides the ability to inject artificial errors to
1905	  netdevice notifier chain callbacks.  It is controlled through debugfs
1906	  interface /sys/kernel/debug/notifier-error-inject/netdev
1907
1908	  If the notifier call chain should be failed with some events
1909	  notified, write the error code to "actions/<notifier event>/error".
1910
1911	  Example: Inject netdevice mtu change error (-22 = -EINVAL)
1912
1913	  # cd /sys/kernel/debug/notifier-error-inject/netdev
1914	  # echo -22 > actions/NETDEV_CHANGEMTU/error
1915	  # ip link set eth0 mtu 1024
1916	  RTNETLINK answers: Invalid argument
1917
1918	  To compile this code as a module, choose M here: the module will
1919	  be called netdev-notifier-error-inject.
1920
1921	  If unsure, say N.
1922
1923config FUNCTION_ERROR_INJECTION
1924	bool "Fault-injections of functions"
1925	depends on HAVE_FUNCTION_ERROR_INJECTION && KPROBES
1926	help
1927	  Add fault injections into various functions that are annotated with
1928	  ALLOW_ERROR_INJECTION() in the kernel. BPF may also modify the return
1929	  value of theses functions. This is useful to test error paths of code.
1930
1931	  If unsure, say N
1932
1933config FAULT_INJECTION
1934	bool "Fault-injection framework"
1935	depends on DEBUG_KERNEL
1936	help
1937	  Provide fault-injection framework.
1938	  For more details, see Documentation/fault-injection/.
1939
1940config FAILSLAB
1941	bool "Fault-injection capability for kmalloc"
1942	depends on FAULT_INJECTION
1943	depends on SLAB || SLUB
1944	help
1945	  Provide fault-injection capability for kmalloc.
1946
1947config FAIL_PAGE_ALLOC
1948	bool "Fault-injection capability for alloc_pages()"
1949	depends on FAULT_INJECTION
1950	help
1951	  Provide fault-injection capability for alloc_pages().
1952
1953config FAULT_INJECTION_USERCOPY
1954	bool "Fault injection capability for usercopy functions"
1955	depends on FAULT_INJECTION
1956	help
1957	  Provides fault-injection capability to inject failures
1958	  in usercopy functions (copy_from_user(), get_user(), ...).
1959
1960config FAIL_MAKE_REQUEST
1961	bool "Fault-injection capability for disk IO"
1962	depends on FAULT_INJECTION && BLOCK
1963	help
1964	  Provide fault-injection capability for disk IO.
1965
1966config FAIL_IO_TIMEOUT
1967	bool "Fault-injection capability for faking disk interrupts"
1968	depends on FAULT_INJECTION && BLOCK
1969	help
1970	  Provide fault-injection capability on end IO handling. This
1971	  will make the block layer "forget" an interrupt as configured,
1972	  thus exercising the error handling.
1973
1974	  Only works with drivers that use the generic timeout handling,
1975	  for others it won't do anything.
1976
1977config FAIL_FUTEX
1978	bool "Fault-injection capability for futexes"
1979	select DEBUG_FS
1980	depends on FAULT_INJECTION && FUTEX
1981	help
1982	  Provide fault-injection capability for futexes.
1983
1984config FAULT_INJECTION_DEBUG_FS
1985	bool "Debugfs entries for fault-injection capabilities"
1986	depends on FAULT_INJECTION && SYSFS && DEBUG_FS
1987	help
1988	  Enable configuration of fault-injection capabilities via debugfs.
1989
1990config FAIL_FUNCTION
1991	bool "Fault-injection capability for functions"
1992	depends on FAULT_INJECTION_DEBUG_FS && FUNCTION_ERROR_INJECTION
1993	help
1994	  Provide function-based fault-injection capability.
1995	  This will allow you to override a specific function with a return
1996	  with given return value. As a result, function caller will see
1997	  an error value and have to handle it. This is useful to test the
1998	  error handling in various subsystems.
1999
2000config FAIL_MMC_REQUEST
2001	bool "Fault-injection capability for MMC IO"
2002	depends on FAULT_INJECTION_DEBUG_FS && MMC
2003	help
2004	  Provide fault-injection capability for MMC IO.
2005	  This will make the mmc core return data errors. This is
2006	  useful to test the error handling in the mmc block device
2007	  and to test how the mmc host driver handles retries from
2008	  the block device.
2009
2010config FAIL_SUNRPC
2011	bool "Fault-injection capability for SunRPC"
2012	depends on FAULT_INJECTION_DEBUG_FS && SUNRPC_DEBUG
2013	help
2014	  Provide fault-injection capability for SunRPC and
2015	  its consumers.
2016
2017config FAULT_INJECTION_STACKTRACE_FILTER
2018	bool "stacktrace filter for fault-injection capabilities"
2019	depends on FAULT_INJECTION_DEBUG_FS && STACKTRACE_SUPPORT
2020	select STACKTRACE
2021	depends on FRAME_POINTER || MIPS || PPC || S390 || MICROBLAZE || ARM || ARC || X86
2022	help
2023	  Provide stacktrace filter for fault-injection capabilities
2024
2025config ARCH_HAS_KCOV
2026	bool
2027	help
2028	  An architecture should select this when it can successfully
2029	  build and run with CONFIG_KCOV. This typically requires
2030	  disabling instrumentation for some early boot code.
2031
2032config CC_HAS_SANCOV_TRACE_PC
2033	def_bool $(cc-option,-fsanitize-coverage=trace-pc)
2034
2035
2036config KCOV
2037	bool "Code coverage for fuzzing"
2038	depends on ARCH_HAS_KCOV
2039	depends on CC_HAS_SANCOV_TRACE_PC || GCC_PLUGINS
2040	depends on !ARCH_WANTS_NO_INSTR || HAVE_NOINSTR_HACK || \
2041		   GCC_VERSION >= 120000 || CLANG_VERSION >= 130000
2042	select DEBUG_FS
2043	select GCC_PLUGIN_SANCOV if !CC_HAS_SANCOV_TRACE_PC
2044	select OBJTOOL if HAVE_NOINSTR_HACK
2045	help
2046	  KCOV exposes kernel code coverage information in a form suitable
2047	  for coverage-guided fuzzing (randomized testing).
2048
2049	  If RANDOMIZE_BASE is enabled, PC values will not be stable across
2050	  different machines and across reboots. If you need stable PC values,
2051	  disable RANDOMIZE_BASE.
2052
2053	  For more details, see Documentation/dev-tools/kcov.rst.
2054
2055config KCOV_ENABLE_COMPARISONS
2056	bool "Enable comparison operands collection by KCOV"
2057	depends on KCOV
2058	depends on $(cc-option,-fsanitize-coverage=trace-cmp)
2059	help
2060	  KCOV also exposes operands of every comparison in the instrumented
2061	  code along with operand sizes and PCs of the comparison instructions.
2062	  These operands can be used by fuzzing engines to improve the quality
2063	  of fuzzing coverage.
2064
2065config KCOV_INSTRUMENT_ALL
2066	bool "Instrument all code by default"
2067	depends on KCOV
2068	default y
2069	help
2070	  If you are doing generic system call fuzzing (like e.g. syzkaller),
2071	  then you will want to instrument the whole kernel and you should
2072	  say y here. If you are doing more targeted fuzzing (like e.g.
2073	  filesystem fuzzing with AFL) then you will want to enable coverage
2074	  for more specific subsets of files, and should say n here.
2075
2076config KCOV_IRQ_AREA_SIZE
2077	hex "Size of interrupt coverage collection area in words"
2078	depends on KCOV
2079	default 0x40000
2080	help
2081	  KCOV uses preallocated per-cpu areas to collect coverage from
2082	  soft interrupts. This specifies the size of those areas in the
2083	  number of unsigned long words.
2084
2085menuconfig RUNTIME_TESTING_MENU
2086	bool "Runtime Testing"
2087	def_bool y
2088
2089if RUNTIME_TESTING_MENU
2090
2091config LKDTM
2092	tristate "Linux Kernel Dump Test Tool Module"
2093	depends on DEBUG_FS
2094	help
2095	This module enables testing of the different dumping mechanisms by
2096	inducing system failures at predefined crash points.
2097	If you don't need it: say N
2098	Choose M here to compile this code as a module. The module will be
2099	called lkdtm.
2100
2101	Documentation on how to use the module can be found in
2102	Documentation/fault-injection/provoke-crashes.rst
2103
2104config CPUMASK_KUNIT_TEST
2105	tristate "KUnit test for cpumask" if !KUNIT_ALL_TESTS
2106	depends on KUNIT
2107	default KUNIT_ALL_TESTS
2108	help
2109	  Enable to turn on cpumask tests, running at boot or module load time.
2110
2111	  For more information on KUnit and unit tests in general, please refer
2112	  to the KUnit documentation in Documentation/dev-tools/kunit/.
2113
2114	  If unsure, say N.
2115
2116config TEST_LIST_SORT
2117	tristate "Linked list sorting test" if !KUNIT_ALL_TESTS
2118	depends on KUNIT
2119	default KUNIT_ALL_TESTS
2120	help
2121	  Enable this to turn on 'list_sort()' function test. This test is
2122	  executed only once during system boot (so affects only boot time),
2123	  or at module load time.
2124
2125	  If unsure, say N.
2126
2127config TEST_MIN_HEAP
2128	tristate "Min heap test"
2129	depends on DEBUG_KERNEL || m
2130	help
2131	  Enable this to turn on min heap function tests. This test is
2132	  executed only once during system boot (so affects only boot time),
2133	  or at module load time.
2134
2135	  If unsure, say N.
2136
2137config TEST_SORT
2138	tristate "Array-based sort test" if !KUNIT_ALL_TESTS
2139	depends on KUNIT
2140	default KUNIT_ALL_TESTS
2141	help
2142	  This option enables the self-test function of 'sort()' at boot,
2143	  or at module load time.
2144
2145	  If unsure, say N.
2146
2147config TEST_DIV64
2148	tristate "64bit/32bit division and modulo test"
2149	depends on DEBUG_KERNEL || m
2150	help
2151	  Enable this to turn on 'do_div()' function test. This test is
2152	  executed only once during system boot (so affects only boot time),
2153	  or at module load time.
2154
2155	  If unsure, say N.
2156
2157config KPROBES_SANITY_TEST
2158	tristate "Kprobes sanity tests" if !KUNIT_ALL_TESTS
2159	depends on DEBUG_KERNEL
2160	depends on KPROBES
2161	depends on KUNIT
2162	select STACKTRACE if ARCH_CORRECT_STACKTRACE_ON_KRETPROBE
2163	default KUNIT_ALL_TESTS
2164	help
2165	  This option provides for testing basic kprobes functionality on
2166	  boot. Samples of kprobe and kretprobe are inserted and
2167	  verified for functionality.
2168
2169	  Say N if you are unsure.
2170
2171config FPROBE_SANITY_TEST
2172	bool "Self test for fprobe"
2173	depends on DEBUG_KERNEL
2174	depends on FPROBE
2175	depends on KUNIT=y
2176	help
2177	  This option will enable testing the fprobe when the system boot.
2178	  A series of tests are made to verify that the fprobe is functioning
2179	  properly.
2180
2181	  Say N if you are unsure.
2182
2183config BACKTRACE_SELF_TEST
2184	tristate "Self test for the backtrace code"
2185	depends on DEBUG_KERNEL
2186	help
2187	  This option provides a kernel module that can be used to test
2188	  the kernel stack backtrace code. This option is not useful
2189	  for distributions or general kernels, but only for kernel
2190	  developers working on architecture code.
2191
2192	  Note that if you want to also test saved backtraces, you will
2193	  have to enable STACKTRACE as well.
2194
2195	  Say N if you are unsure.
2196
2197config TEST_REF_TRACKER
2198	tristate "Self test for reference tracker"
2199	depends on DEBUG_KERNEL && STACKTRACE_SUPPORT
2200	select REF_TRACKER
2201	help
2202	  This option provides a kernel module performing tests
2203	  using reference tracker infrastructure.
2204
2205	  Say N if you are unsure.
2206
2207config RBTREE_TEST
2208	tristate "Red-Black tree test"
2209	depends on DEBUG_KERNEL
2210	help
2211	  A benchmark measuring the performance of the rbtree library.
2212	  Also includes rbtree invariant checks.
2213
2214config REED_SOLOMON_TEST
2215	tristate "Reed-Solomon library test"
2216	depends on DEBUG_KERNEL || m
2217	select REED_SOLOMON
2218	select REED_SOLOMON_ENC16
2219	select REED_SOLOMON_DEC16
2220	help
2221	  This option enables the self-test function of rslib at boot,
2222	  or at module load time.
2223
2224	  If unsure, say N.
2225
2226config INTERVAL_TREE_TEST
2227	tristate "Interval tree test"
2228	depends on DEBUG_KERNEL
2229	select INTERVAL_TREE
2230	help
2231	  A benchmark measuring the performance of the interval tree library
2232
2233config PERCPU_TEST
2234	tristate "Per cpu operations test"
2235	depends on m && DEBUG_KERNEL
2236	help
2237	  Enable this option to build test module which validates per-cpu
2238	  operations.
2239
2240	  If unsure, say N.
2241
2242config ATOMIC64_SELFTEST
2243	tristate "Perform an atomic64_t self-test"
2244	help
2245	  Enable this option to test the atomic64_t functions at boot or
2246	  at module load time.
2247
2248	  If unsure, say N.
2249
2250config ASYNC_RAID6_TEST
2251	tristate "Self test for hardware accelerated raid6 recovery"
2252	depends on ASYNC_RAID6_RECOV
2253	select ASYNC_MEMCPY
2254	help
2255	  This is a one-shot self test that permutes through the
2256	  recovery of all the possible two disk failure scenarios for a
2257	  N-disk array.  Recovery is performed with the asynchronous
2258	  raid6 recovery routines, and will optionally use an offload
2259	  engine if one is available.
2260
2261	  If unsure, say N.
2262
2263config TEST_HEXDUMP
2264	tristate "Test functions located in the hexdump module at runtime"
2265
2266config STRING_SELFTEST
2267	tristate "Test string functions at runtime"
2268
2269config TEST_STRING_HELPERS
2270	tristate "Test functions located in the string_helpers module at runtime"
2271
2272config TEST_KSTRTOX
2273	tristate "Test kstrto*() family of functions at runtime"
2274
2275config TEST_PRINTF
2276	tristate "Test printf() family of functions at runtime"
2277
2278config TEST_SCANF
2279	tristate "Test scanf() family of functions at runtime"
2280
2281config TEST_BITMAP
2282	tristate "Test bitmap_*() family of functions at runtime"
2283	help
2284	  Enable this option to test the bitmap functions at boot.
2285
2286	  If unsure, say N.
2287
2288config TEST_UUID
2289	tristate "Test functions located in the uuid module at runtime"
2290
2291config TEST_XARRAY
2292	tristate "Test the XArray code at runtime"
2293
2294config TEST_MAPLE_TREE
2295	depends on DEBUG_KERNEL
2296	select DEBUG_MAPLE_TREE
2297	tristate "Test the Maple Tree code at runtime"
2298
2299config TEST_RHASHTABLE
2300	tristate "Perform selftest on resizable hash table"
2301	help
2302	  Enable this option to test the rhashtable functions at boot.
2303
2304	  If unsure, say N.
2305
2306config TEST_IDA
2307	tristate "Perform selftest on IDA functions"
2308
2309config TEST_PARMAN
2310	tristate "Perform selftest on priority array manager"
2311	depends on PARMAN
2312	help
2313	  Enable this option to test priority array manager on boot
2314	  (or module load).
2315
2316	  If unsure, say N.
2317
2318config TEST_IRQ_TIMINGS
2319	bool "IRQ timings selftest"
2320	depends on IRQ_TIMINGS
2321	help
2322	  Enable this option to test the irq timings code on boot.
2323
2324	  If unsure, say N.
2325
2326config TEST_LKM
2327	tristate "Test module loading with 'hello world' module"
2328	depends on m
2329	help
2330	  This builds the "test_module" module that emits "Hello, world"
2331	  on printk when loaded. It is designed to be used for basic
2332	  evaluation of the module loading subsystem (for example when
2333	  validating module verification). It lacks any extra dependencies,
2334	  and will not normally be loaded by the system unless explicitly
2335	  requested by name.
2336
2337	  If unsure, say N.
2338
2339config TEST_BITOPS
2340	tristate "Test module for compilation of bitops operations"
2341	depends on m
2342	help
2343	  This builds the "test_bitops" module that is much like the
2344	  TEST_LKM module except that it does a basic exercise of the
2345	  set/clear_bit macros and get_count_order/long to make sure there are
2346	  no compiler warnings from C=1 sparse checker or -Wextra
2347	  compilations. It has no dependencies and doesn't run or load unless
2348	  explicitly requested by name.  for example: modprobe test_bitops.
2349
2350	  If unsure, say N.
2351
2352config TEST_VMALLOC
2353	tristate "Test module for stress/performance analysis of vmalloc allocator"
2354	default n
2355       depends on MMU
2356	depends on m
2357	help
2358	  This builds the "test_vmalloc" module that should be used for
2359	  stress and performance analysis. So, any new change for vmalloc
2360	  subsystem can be evaluated from performance and stability point
2361	  of view.
2362
2363	  If unsure, say N.
2364
2365config TEST_USER_COPY
2366	tristate "Test user/kernel boundary protections"
2367	depends on m
2368	help
2369	  This builds the "test_user_copy" module that runs sanity checks
2370	  on the copy_to/from_user infrastructure, making sure basic
2371	  user/kernel boundary testing is working. If it fails to load,
2372	  a regression has been detected in the user/kernel memory boundary
2373	  protections.
2374
2375	  If unsure, say N.
2376
2377config TEST_BPF
2378	tristate "Test BPF filter functionality"
2379	depends on m && NET
2380	help
2381	  This builds the "test_bpf" module that runs various test vectors
2382	  against the BPF interpreter or BPF JIT compiler depending on the
2383	  current setting. This is in particular useful for BPF JIT compiler
2384	  development, but also to run regression tests against changes in
2385	  the interpreter code. It also enables test stubs for eBPF maps and
2386	  verifier used by user space verifier testsuite.
2387
2388	  If unsure, say N.
2389
2390config TEST_BLACKHOLE_DEV
2391	tristate "Test blackhole netdev functionality"
2392	depends on m && NET
2393	help
2394	  This builds the "test_blackhole_dev" module that validates the
2395	  data path through this blackhole netdev.
2396
2397	  If unsure, say N.
2398
2399config FIND_BIT_BENCHMARK
2400	tristate "Test find_bit functions"
2401	help
2402	  This builds the "test_find_bit" module that measure find_*_bit()
2403	  functions performance.
2404
2405	  If unsure, say N.
2406
2407config TEST_FIRMWARE
2408	tristate "Test firmware loading via userspace interface"
2409	depends on FW_LOADER
2410	help
2411	  This builds the "test_firmware" module that creates a userspace
2412	  interface for testing firmware loading. This can be used to
2413	  control the triggering of firmware loading without needing an
2414	  actual firmware-using device. The contents can be rechecked by
2415	  userspace.
2416
2417	  If unsure, say N.
2418
2419config TEST_SYSCTL
2420	tristate "sysctl test driver"
2421	depends on PROC_SYSCTL
2422	help
2423	  This builds the "test_sysctl" module. This driver enables to test the
2424	  proc sysctl interfaces available to drivers safely without affecting
2425	  production knobs which might alter system functionality.
2426
2427	  If unsure, say N.
2428
2429config BITFIELD_KUNIT
2430	tristate "KUnit test bitfield functions at runtime" if !KUNIT_ALL_TESTS
2431	depends on KUNIT
2432	default KUNIT_ALL_TESTS
2433	help
2434	  Enable this option to test the bitfield functions at boot.
2435
2436	  KUnit tests run during boot and output the results to the debug log
2437	  in TAP format (http://testanything.org/). Only useful for kernel devs
2438	  running the KUnit test harness, and not intended for inclusion into a
2439	  production build.
2440
2441	  For more information on KUnit and unit tests in general please refer
2442	  to the KUnit documentation in Documentation/dev-tools/kunit/.
2443
2444	  If unsure, say N.
2445
2446config HASH_KUNIT_TEST
2447	tristate "KUnit Test for integer hash functions" if !KUNIT_ALL_TESTS
2448	depends on KUNIT
2449	default KUNIT_ALL_TESTS
2450	help
2451	  Enable this option to test the kernel's string (<linux/stringhash.h>), and
2452	  integer (<linux/hash.h>) hash functions on boot.
2453
2454	  KUnit tests run during boot and output the results to the debug log
2455	  in TAP format (https://testanything.org/). Only useful for kernel devs
2456	  running the KUnit test harness, and not intended for inclusion into a
2457	  production build.
2458
2459	  For more information on KUnit and unit tests in general please refer
2460	  to the KUnit documentation in Documentation/dev-tools/kunit/.
2461
2462	  This is intended to help people writing architecture-specific
2463	  optimized versions. If unsure, say N.
2464
2465config RESOURCE_KUNIT_TEST
2466	tristate "KUnit test for resource API" if !KUNIT_ALL_TESTS
2467	depends on KUNIT
2468	default KUNIT_ALL_TESTS
2469	help
2470	  This builds the resource API unit test.
2471	  Tests the logic of API provided by resource.c and ioport.h.
2472	  For more information on KUnit and unit tests in general please refer
2473	  to the KUnit documentation in Documentation/dev-tools/kunit/.
2474
2475	  If unsure, say N.
2476
2477config SYSCTL_KUNIT_TEST
2478	tristate "KUnit test for sysctl" if !KUNIT_ALL_TESTS
2479	depends on KUNIT
2480	default KUNIT_ALL_TESTS
2481	help
2482	  This builds the proc sysctl unit test, which runs on boot.
2483	  Tests the API contract and implementation correctness of sysctl.
2484	  For more information on KUnit and unit tests in general please refer
2485	  to the KUnit documentation in Documentation/dev-tools/kunit/.
2486
2487	  If unsure, say N.
2488
2489config LIST_KUNIT_TEST
2490	tristate "KUnit Test for Kernel Linked-list structures" if !KUNIT_ALL_TESTS
2491	depends on KUNIT
2492	default KUNIT_ALL_TESTS
2493	help
2494	  This builds the linked list KUnit test suite.
2495	  It tests that the API and basic functionality of the list_head type
2496	  and associated macros.
2497
2498	  KUnit tests run during boot and output the results to the debug log
2499	  in TAP format (https://testanything.org/). Only useful for kernel devs
2500	  running the KUnit test harness, and not intended for inclusion into a
2501	  production build.
2502
2503	  For more information on KUnit and unit tests in general please refer
2504	  to the KUnit documentation in Documentation/dev-tools/kunit/.
2505
2506	  If unsure, say N.
2507
2508config LINEAR_RANGES_TEST
2509	tristate "KUnit test for linear_ranges"
2510	depends on KUNIT
2511	select LINEAR_RANGES
2512	help
2513	  This builds the linear_ranges unit test, which runs on boot.
2514	  Tests the linear_ranges logic correctness.
2515	  For more information on KUnit and unit tests in general please refer
2516	  to the KUnit documentation in Documentation/dev-tools/kunit/.
2517
2518	  If unsure, say N.
2519
2520config CMDLINE_KUNIT_TEST
2521	tristate "KUnit test for cmdline API" if !KUNIT_ALL_TESTS
2522	depends on KUNIT
2523	default KUNIT_ALL_TESTS
2524	help
2525	  This builds the cmdline API unit test.
2526	  Tests the logic of API provided by cmdline.c.
2527	  For more information on KUnit and unit tests in general please refer
2528	  to the KUnit documentation in Documentation/dev-tools/kunit/.
2529
2530	  If unsure, say N.
2531
2532config BITS_TEST
2533	tristate "KUnit test for bits.h" if !KUNIT_ALL_TESTS
2534	depends on KUNIT
2535	default KUNIT_ALL_TESTS
2536	help
2537	  This builds the bits unit test.
2538	  Tests the logic of macros defined in bits.h.
2539	  For more information on KUnit and unit tests in general please refer
2540	  to the KUnit documentation in Documentation/dev-tools/kunit/.
2541
2542	  If unsure, say N.
2543
2544config SLUB_KUNIT_TEST
2545	tristate "KUnit test for SLUB cache error detection" if !KUNIT_ALL_TESTS
2546	depends on SLUB_DEBUG && KUNIT
2547	default KUNIT_ALL_TESTS
2548	help
2549	  This builds SLUB allocator unit test.
2550	  Tests SLUB cache debugging functionality.
2551	  For more information on KUnit and unit tests in general please refer
2552	  to the KUnit documentation in Documentation/dev-tools/kunit/.
2553
2554	  If unsure, say N.
2555
2556config RATIONAL_KUNIT_TEST
2557	tristate "KUnit test for rational.c" if !KUNIT_ALL_TESTS
2558	depends on KUNIT && RATIONAL
2559	default KUNIT_ALL_TESTS
2560	help
2561	  This builds the rational math unit test.
2562	  For more information on KUnit and unit tests in general please refer
2563	  to the KUnit documentation in Documentation/dev-tools/kunit/.
2564
2565	  If unsure, say N.
2566
2567config MEMCPY_KUNIT_TEST
2568	tristate "Test memcpy(), memmove(), and memset() functions at runtime" if !KUNIT_ALL_TESTS
2569	depends on KUNIT
2570	default KUNIT_ALL_TESTS
2571	help
2572	  Builds unit tests for memcpy(), memmove(), and memset() functions.
2573	  For more information on KUnit and unit tests in general please refer
2574	  to the KUnit documentation in Documentation/dev-tools/kunit/.
2575
2576	  If unsure, say N.
2577
2578config IS_SIGNED_TYPE_KUNIT_TEST
2579	tristate "Test is_signed_type() macro" if !KUNIT_ALL_TESTS
2580	depends on KUNIT
2581	default KUNIT_ALL_TESTS
2582	help
2583	  Builds unit tests for the is_signed_type() macro.
2584
2585	  For more information on KUnit and unit tests in general please refer
2586	  to the KUnit documentation in Documentation/dev-tools/kunit/.
2587
2588	  If unsure, say N.
2589
2590config OVERFLOW_KUNIT_TEST
2591	tristate "Test check_*_overflow() functions at runtime" if !KUNIT_ALL_TESTS
2592	depends on KUNIT
2593	default KUNIT_ALL_TESTS
2594	help
2595	  Builds unit tests for the check_*_overflow(), size_*(), allocation, and
2596	  related functions.
2597
2598	  For more information on KUnit and unit tests in general please refer
2599	  to the KUnit documentation in Documentation/dev-tools/kunit/.
2600
2601	  If unsure, say N.
2602
2603config STACKINIT_KUNIT_TEST
2604	tristate "Test level of stack variable initialization" if !KUNIT_ALL_TESTS
2605	depends on KUNIT
2606	default KUNIT_ALL_TESTS
2607	help
2608	  Test if the kernel is zero-initializing stack variables and
2609	  padding. Coverage is controlled by compiler flags,
2610	  CONFIG_INIT_STACK_ALL_PATTERN, CONFIG_INIT_STACK_ALL_ZERO,
2611	  CONFIG_GCC_PLUGIN_STRUCTLEAK, CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF,
2612	  or CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL.
2613
2614config FORTIFY_KUNIT_TEST
2615	tristate "Test fortified str*() and mem*() function internals at runtime" if !KUNIT_ALL_TESTS
2616	depends on KUNIT && FORTIFY_SOURCE
2617	default KUNIT_ALL_TESTS
2618	help
2619	  Builds unit tests for checking internals of FORTIFY_SOURCE as used
2620	  by the str*() and mem*() family of functions. For testing runtime
2621	  traps of FORTIFY_SOURCE, see LKDTM's "FORTIFY_*" tests.
2622
2623config HW_BREAKPOINT_KUNIT_TEST
2624	bool "Test hw_breakpoint constraints accounting" if !KUNIT_ALL_TESTS
2625	depends on HAVE_HW_BREAKPOINT
2626	depends on KUNIT=y
2627	default KUNIT_ALL_TESTS
2628	help
2629	  Tests for hw_breakpoint constraints accounting.
2630
2631	  If unsure, say N.
2632
2633config STRSCPY_KUNIT_TEST
2634	tristate "Test strscpy*() family of functions at runtime" if !KUNIT_ALL_TESTS
2635	depends on KUNIT
2636	default KUNIT_ALL_TESTS
2637
2638config SIPHASH_KUNIT_TEST
2639	tristate "Perform selftest on siphash functions" if !KUNIT_ALL_TESTS
2640	depends on KUNIT
2641	default KUNIT_ALL_TESTS
2642	help
2643	  Enable this option to test the kernel's siphash (<linux/siphash.h>) hash
2644	  functions on boot (or module load).
2645
2646	  This is intended to help people writing architecture-specific
2647	  optimized versions.  If unsure, say N.
2648
2649config TEST_UDELAY
2650	tristate "udelay test driver"
2651	help
2652	  This builds the "udelay_test" module that helps to make sure
2653	  that udelay() is working properly.
2654
2655	  If unsure, say N.
2656
2657config TEST_STATIC_KEYS
2658	tristate "Test static keys"
2659	depends on m
2660	help
2661	  Test the static key interfaces.
2662
2663	  If unsure, say N.
2664
2665config TEST_DYNAMIC_DEBUG
2666	tristate "Test DYNAMIC_DEBUG"
2667	depends on DYNAMIC_DEBUG
2668	help
2669	  This module registers a tracer callback to count enabled
2670	  pr_debugs in a 'do_debugging' function, then alters their
2671	  enablements, calls the function, and compares counts.
2672
2673	  If unsure, say N.
2674
2675config TEST_KMOD
2676	tristate "kmod stress tester"
2677	depends on m
2678	depends on NETDEVICES && NET_CORE && INET # for TUN
2679	depends on BLOCK
2680	depends on PAGE_SIZE_LESS_THAN_256KB # for BTRFS
2681	select TEST_LKM
2682	select XFS_FS
2683	select TUN
2684	select BTRFS_FS
2685	help
2686	  Test the kernel's module loading mechanism: kmod. kmod implements
2687	  support to load modules using the Linux kernel's usermode helper.
2688	  This test provides a series of tests against kmod.
2689
2690	  Although technically you can either build test_kmod as a module or
2691	  into the kernel we disallow building it into the kernel since
2692	  it stress tests request_module() and this will very likely cause
2693	  some issues by taking over precious threads available from other
2694	  module load requests, ultimately this could be fatal.
2695
2696	  To run tests run:
2697
2698	  tools/testing/selftests/kmod/kmod.sh --help
2699
2700	  If unsure, say N.
2701
2702config TEST_DEBUG_VIRTUAL
2703	tristate "Test CONFIG_DEBUG_VIRTUAL feature"
2704	depends on DEBUG_VIRTUAL
2705	help
2706	  Test the kernel's ability to detect incorrect calls to
2707	  virt_to_phys() done against the non-linear part of the
2708	  kernel's virtual address map.
2709
2710	  If unsure, say N.
2711
2712config TEST_MEMCAT_P
2713	tristate "Test memcat_p() helper function"
2714	help
2715	  Test the memcat_p() helper for correctly merging two
2716	  pointer arrays together.
2717
2718	  If unsure, say N.
2719
2720config TEST_LIVEPATCH
2721	tristate "Test livepatching"
2722	default n
2723	depends on DYNAMIC_DEBUG
2724	depends on LIVEPATCH
2725	depends on m
2726	help
2727	  Test kernel livepatching features for correctness.  The tests will
2728	  load test modules that will be livepatched in various scenarios.
2729
2730	  To run all the livepatching tests:
2731
2732	  make -C tools/testing/selftests TARGETS=livepatch run_tests
2733
2734	  Alternatively, individual tests may be invoked:
2735
2736	  tools/testing/selftests/livepatch/test-callbacks.sh
2737	  tools/testing/selftests/livepatch/test-livepatch.sh
2738	  tools/testing/selftests/livepatch/test-shadow-vars.sh
2739
2740	  If unsure, say N.
2741
2742config TEST_OBJAGG
2743	tristate "Perform selftest on object aggreration manager"
2744	default n
2745	depends on OBJAGG
2746	help
2747	  Enable this option to test object aggregation manager on boot
2748	  (or module load).
2749
2750config TEST_MEMINIT
2751	tristate "Test heap/page initialization"
2752	help
2753	  Test if the kernel is zero-initializing heap and page allocations.
2754	  This can be useful to test init_on_alloc and init_on_free features.
2755
2756	  If unsure, say N.
2757
2758config TEST_HMM
2759	tristate "Test HMM (Heterogeneous Memory Management)"
2760	depends on TRANSPARENT_HUGEPAGE
2761	depends on DEVICE_PRIVATE
2762	select HMM_MIRROR
2763	select MMU_NOTIFIER
2764	help
2765	  This is a pseudo device driver solely for testing HMM.
2766	  Say M here if you want to build the HMM test module.
2767	  Doing so will allow you to run tools/testing/selftest/vm/hmm-tests.
2768
2769	  If unsure, say N.
2770
2771config TEST_FREE_PAGES
2772	tristate "Test freeing pages"
2773	help
2774	  Test that a memory leak does not occur due to a race between
2775	  freeing a block of pages and a speculative page reference.
2776	  Loading this module is safe if your kernel has the bug fixed.
2777	  If the bug is not fixed, it will leak gigabytes of memory and
2778	  probably OOM your system.
2779
2780config TEST_FPU
2781	tristate "Test floating point operations in kernel space"
2782	depends on X86 && !KCOV_INSTRUMENT_ALL
2783	help
2784	  Enable this option to add /sys/kernel/debug/selftest_helpers/test_fpu
2785	  which will trigger a sequence of floating point operations. This is used
2786	  for self-testing floating point control register setting in
2787	  kernel_fpu_begin().
2788
2789	  If unsure, say N.
2790
2791config TEST_CLOCKSOURCE_WATCHDOG
2792	tristate "Test clocksource watchdog in kernel space"
2793	depends on CLOCKSOURCE_WATCHDOG
2794	help
2795	  Enable this option to create a kernel module that will trigger
2796	  a test of the clocksource watchdog.  This module may be loaded
2797	  via modprobe or insmod in which case it will run upon being
2798	  loaded, or it may be built in, in which case it will run
2799	  shortly after boot.
2800
2801	  If unsure, say N.
2802
2803endif # RUNTIME_TESTING_MENU
2804
2805config ARCH_USE_MEMTEST
2806	bool
2807	help
2808	  An architecture should select this when it uses early_memtest()
2809	  during boot process.
2810
2811config MEMTEST
2812	bool "Memtest"
2813	depends on ARCH_USE_MEMTEST
2814	help
2815	  This option adds a kernel parameter 'memtest', which allows memtest
2816	  to be set and executed.
2817	        memtest=0, mean disabled; -- default
2818	        memtest=1, mean do 1 test pattern;
2819	        ...
2820	        memtest=17, mean do 17 test patterns.
2821	  If you are unsure how to answer this question, answer N.
2822
2823
2824
2825config HYPERV_TESTING
2826	bool "Microsoft Hyper-V driver testing"
2827	default n
2828	depends on HYPERV && DEBUG_FS
2829	help
2830	  Select this option to enable Hyper-V vmbus testing.
2831
2832endmenu # "Kernel Testing and Coverage"
2833
2834menu "Rust hacking"
2835
2836config RUST_DEBUG_ASSERTIONS
2837	bool "Debug assertions"
2838	depends on RUST
2839	help
2840	  Enables rustc's `-Cdebug-assertions` codegen option.
2841
2842	  This flag lets you turn `cfg(debug_assertions)` conditional
2843	  compilation on or off. This can be used to enable extra debugging
2844	  code in development but not in production. For example, it controls
2845	  the behavior of the standard library's `debug_assert!` macro.
2846
2847	  Note that this will apply to all Rust code, including `core`.
2848
2849	  If unsure, say N.
2850
2851config RUST_OVERFLOW_CHECKS
2852	bool "Overflow checks"
2853	default y
2854	depends on RUST
2855	help
2856	  Enables rustc's `-Coverflow-checks` codegen option.
2857
2858	  This flag allows you to control the behavior of runtime integer
2859	  overflow. When overflow-checks are enabled, a Rust panic will occur
2860	  on overflow.
2861
2862	  Note that this will apply to all Rust code, including `core`.
2863
2864	  If unsure, say Y.
2865
2866config RUST_BUILD_ASSERT_ALLOW
2867	bool "Allow unoptimized build-time assertions"
2868	depends on RUST
2869	help
2870	  Controls how are `build_error!` and `build_assert!` handled during build.
2871
2872	  If calls to them exist in the binary, it may indicate a violated invariant
2873	  or that the optimizer failed to verify the invariant during compilation.
2874
2875	  This should not happen, thus by default the build is aborted. However,
2876	  as an escape hatch, you can choose Y here to ignore them during build
2877	  and let the check be carried at runtime (with `panic!` being called if
2878	  the check fails).
2879
2880	  If unsure, say N.
2881
2882endmenu # "Rust"
2883
2884source "Documentation/Kconfig"
2885
2886endmenu # Kernel hacking
2887