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