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