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