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