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