lib/math/rational: add Kunit test cases
[linux-2.6-microblaze.git] / lib / Kconfig.debug
1 # SPDX-License-Identifier: GPL-2.0-only
2 menu "Kernel hacking"
3
4 menu "printk and dmesg options"
5
6 config PRINTK_TIME
7         bool "Show timing information on printks"
8         depends on PRINTK
9         help
10           Selecting this option causes time stamps of the printk()
11           messages to be added to the output of the syslog() system
12           call and at the console.
13
14           The timestamp is always recorded internally, and exported
15           to /dev/kmsg. This flag just specifies if the timestamp should
16           be included, not that the timestamp is recorded.
17
18           The behavior is also controlled by the kernel command line
19           parameter printk.time=1. See Documentation/admin-guide/kernel-parameters.rst
20
21 config PRINTK_CALLER
22         bool "Show caller information on printks"
23         depends on PRINTK
24         help
25           Selecting this option causes printk() to add a caller "thread id" (if
26           in task context) or a caller "processor id" (if not in task context)
27           to every message.
28
29           This option is intended for environments where multiple threads
30           concurrently call printk() for many times, for it is difficult to
31           interpret without knowing where these lines (or sometimes individual
32           line which was divided into multiple lines due to race) came from.
33
34           Since toggling after boot makes the code racy, currently there is
35           no option to enable/disable at the kernel command line parameter or
36           sysfs interface.
37
38 config 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         depends on FRAME_POINTER || MIPS || PPC || S390 || MICROBLAZE || ARM || ARC || X86
1379         select KALLSYMS
1380         select KALLSYMS_ALL
1381
1382 config LOCKDEP_SMALL
1383         bool
1384
1385 config LOCKDEP_BITS
1386         int "Bitsize for MAX_LOCKDEP_ENTRIES"
1387         depends on LOCKDEP && !LOCKDEP_SMALL
1388         range 10 30
1389         default 15
1390         help
1391           Try increasing this value if you hit "BUG: MAX_LOCKDEP_ENTRIES too low!" message.
1392
1393 config LOCKDEP_CHAINS_BITS
1394         int "Bitsize for MAX_LOCKDEP_CHAINS"
1395         depends on LOCKDEP && !LOCKDEP_SMALL
1396         range 10 30
1397         default 16
1398         help
1399           Try increasing this value if you hit "BUG: MAX_LOCKDEP_CHAINS too low!" message.
1400
1401 config LOCKDEP_STACK_TRACE_BITS
1402         int "Bitsize for MAX_STACK_TRACE_ENTRIES"
1403         depends on LOCKDEP && !LOCKDEP_SMALL
1404         range 10 30
1405         default 19
1406         help
1407           Try increasing this value if you hit "BUG: MAX_STACK_TRACE_ENTRIES too low!" message.
1408
1409 config LOCKDEP_STACK_TRACE_HASH_BITS
1410         int "Bitsize for STACK_TRACE_HASH_SIZE"
1411         depends on LOCKDEP && !LOCKDEP_SMALL
1412         range 10 30
1413         default 14
1414         help
1415           Try increasing this value if you need large MAX_STACK_TRACE_ENTRIES.
1416
1417 config LOCKDEP_CIRCULAR_QUEUE_BITS
1418         int "Bitsize for elements in circular_queue struct"
1419         depends on LOCKDEP
1420         range 10 30
1421         default 12
1422         help
1423           Try increasing this value if you hit "lockdep bfs error:-1" warning due to __cq_enqueue() failure.
1424
1425 config DEBUG_LOCKDEP
1426         bool "Lock dependency engine debugging"
1427         depends on DEBUG_KERNEL && LOCKDEP
1428         select DEBUG_IRQFLAGS
1429         help
1430           If you say Y here, the lock dependency engine will do
1431           additional runtime checks to debug itself, at the price
1432           of more runtime overhead.
1433
1434 config DEBUG_ATOMIC_SLEEP
1435         bool "Sleep inside atomic section checking"
1436         select PREEMPT_COUNT
1437         depends on DEBUG_KERNEL
1438         depends on !ARCH_NO_PREEMPT
1439         help
1440           If you say Y here, various routines which may sleep will become very
1441           noisy if they are called inside atomic sections: when a spinlock is
1442           held, inside an rcu read side critical section, inside preempt disabled
1443           sections, inside an interrupt, etc...
1444
1445 config DEBUG_LOCKING_API_SELFTESTS
1446         bool "Locking API boot-time self-tests"
1447         depends on DEBUG_KERNEL
1448         help
1449           Say Y here if you want the kernel to run a short self-test during
1450           bootup. The self-test checks whether common types of locking bugs
1451           are detected by debugging mechanisms or not. (if you disable
1452           lock debugging then those bugs wont be detected of course.)
1453           The following locking APIs are covered: spinlocks, rwlocks,
1454           mutexes and rwsems.
1455
1456 config LOCK_TORTURE_TEST
1457         tristate "torture tests for locking"
1458         depends on DEBUG_KERNEL
1459         select TORTURE_TEST
1460         help
1461           This option provides a kernel module that runs torture tests
1462           on kernel locking primitives.  The kernel module may be built
1463           after the fact on the running kernel to be tested, if desired.
1464
1465           Say Y here if you want kernel locking-primitive torture tests
1466           to be built into the kernel.
1467           Say M if you want these torture tests to build as a module.
1468           Say N if you are unsure.
1469
1470 config WW_MUTEX_SELFTEST
1471         tristate "Wait/wound mutex selftests"
1472         help
1473           This option provides a kernel module that runs tests on the
1474           on the struct ww_mutex locking API.
1475
1476           It is recommended to enable DEBUG_WW_MUTEX_SLOWPATH in conjunction
1477           with this test harness.
1478
1479           Say M if you want these self tests to build as a module.
1480           Say N if you are unsure.
1481
1482 config SCF_TORTURE_TEST
1483         tristate "torture tests for smp_call_function*()"
1484         depends on DEBUG_KERNEL
1485         select TORTURE_TEST
1486         help
1487           This option provides a kernel module that runs torture tests
1488           on the smp_call_function() family of primitives.  The kernel
1489           module may be built after the fact on the running kernel to
1490           be tested, if desired.
1491
1492 config CSD_LOCK_WAIT_DEBUG
1493         bool "Debugging for csd_lock_wait(), called from smp_call_function*()"
1494         depends on DEBUG_KERNEL
1495         depends on 64BIT
1496         default n
1497         help
1498           This option enables debug prints when CPUs are slow to respond
1499           to the smp_call_function*() IPI wrappers.  These debug prints
1500           include the IPI handler function currently executing (if any)
1501           and relevant stack traces.
1502
1503 endmenu # lock debugging
1504
1505 config TRACE_IRQFLAGS
1506         depends on TRACE_IRQFLAGS_SUPPORT
1507         bool
1508         help
1509           Enables hooks to interrupt enabling and disabling for
1510           either tracing or lock debugging.
1511
1512 config TRACE_IRQFLAGS_NMI
1513         def_bool y
1514         depends on TRACE_IRQFLAGS
1515         depends on TRACE_IRQFLAGS_NMI_SUPPORT
1516
1517 config DEBUG_IRQFLAGS
1518         bool "Debug IRQ flag manipulation"
1519         help
1520           Enables checks for potentially unsafe enabling or disabling of
1521           interrupts, such as calling raw_local_irq_restore() when interrupts
1522           are enabled.
1523
1524 config STACKTRACE
1525         bool "Stack backtrace support"
1526         depends on STACKTRACE_SUPPORT
1527         help
1528           This option causes the kernel to create a /proc/pid/stack for
1529           every process, showing its current stack trace.
1530           It is also used by various kernel debugging features that require
1531           stack trace generation.
1532
1533 config WARN_ALL_UNSEEDED_RANDOM
1534         bool "Warn for all uses of unseeded randomness"
1535         default n
1536         help
1537           Some parts of the kernel contain bugs relating to their use of
1538           cryptographically secure random numbers before it's actually possible
1539           to generate those numbers securely. This setting ensures that these
1540           flaws don't go unnoticed, by enabling a message, should this ever
1541           occur. This will allow people with obscure setups to know when things
1542           are going wrong, so that they might contact developers about fixing
1543           it.
1544
1545           Unfortunately, on some models of some architectures getting
1546           a fully seeded CRNG is extremely difficult, and so this can
1547           result in dmesg getting spammed for a surprisingly long
1548           time.  This is really bad from a security perspective, and
1549           so architecture maintainers really need to do what they can
1550           to get the CRNG seeded sooner after the system is booted.
1551           However, since users cannot do anything actionable to
1552           address this, by default the kernel will issue only a single
1553           warning for the first use of unseeded randomness.
1554
1555           Say Y here if you want to receive warnings for all uses of
1556           unseeded randomness.  This will be of use primarily for
1557           those developers interested in improving the security of
1558           Linux kernels running on their architecture (or
1559           subarchitecture).
1560
1561 config DEBUG_KOBJECT
1562         bool "kobject debugging"
1563         depends on DEBUG_KERNEL
1564         help
1565           If you say Y here, some extra kobject debugging messages will be sent
1566           to the syslog.
1567
1568 config DEBUG_KOBJECT_RELEASE
1569         bool "kobject release debugging"
1570         depends on DEBUG_OBJECTS_TIMERS
1571         help
1572           kobjects are reference counted objects.  This means that their
1573           last reference count put is not predictable, and the kobject can
1574           live on past the point at which a driver decides to drop it's
1575           initial reference to the kobject gained on allocation.  An
1576           example of this would be a struct device which has just been
1577           unregistered.
1578
1579           However, some buggy drivers assume that after such an operation,
1580           the memory backing the kobject can be immediately freed.  This
1581           goes completely against the principles of a refcounted object.
1582
1583           If you say Y here, the kernel will delay the release of kobjects
1584           on the last reference count to improve the visibility of this
1585           kind of kobject release bug.
1586
1587 config HAVE_DEBUG_BUGVERBOSE
1588         bool
1589
1590 menu "Debug kernel data structures"
1591
1592 config DEBUG_LIST
1593         bool "Debug linked list manipulation"
1594         depends on DEBUG_KERNEL || BUG_ON_DATA_CORRUPTION
1595         help
1596           Enable this to turn on extended checks in the linked-list
1597           walking routines.
1598
1599           If unsure, say N.
1600
1601 config DEBUG_PLIST
1602         bool "Debug priority linked list manipulation"
1603         depends on DEBUG_KERNEL
1604         help
1605           Enable this to turn on extended checks in the priority-ordered
1606           linked-list (plist) walking routines.  This checks the entire
1607           list multiple times during each manipulation.
1608
1609           If unsure, say N.
1610
1611 config DEBUG_SG
1612         bool "Debug SG table operations"
1613         depends on DEBUG_KERNEL
1614         help
1615           Enable this to turn on checks on scatter-gather tables. This can
1616           help find problems with drivers that do not properly initialize
1617           their sg tables.
1618
1619           If unsure, say N.
1620
1621 config DEBUG_NOTIFIERS
1622         bool "Debug notifier call chains"
1623         depends on DEBUG_KERNEL
1624         help
1625           Enable this to turn on sanity checking for notifier call chains.
1626           This is most useful for kernel developers to make sure that
1627           modules properly unregister themselves from notifier chains.
1628           This is a relatively cheap check but if you care about maximum
1629           performance, say N.
1630
1631 config BUG_ON_DATA_CORRUPTION
1632         bool "Trigger a BUG when data corruption is detected"
1633         select DEBUG_LIST
1634         help
1635           Select this option if the kernel should BUG when it encounters
1636           data corruption in kernel memory structures when they get checked
1637           for validity.
1638
1639           If unsure, say N.
1640
1641 endmenu
1642
1643 config DEBUG_CREDENTIALS
1644         bool "Debug credential management"
1645         depends on DEBUG_KERNEL
1646         help
1647           Enable this to turn on some debug checking for credential
1648           management.  The additional code keeps track of the number of
1649           pointers from task_structs to any given cred struct, and checks to
1650           see that this number never exceeds the usage count of the cred
1651           struct.
1652
1653           Furthermore, if SELinux is enabled, this also checks that the
1654           security pointer in the cred struct is never seen to be invalid.
1655
1656           If unsure, say N.
1657
1658 source "kernel/rcu/Kconfig.debug"
1659
1660 config DEBUG_WQ_FORCE_RR_CPU
1661         bool "Force round-robin CPU selection for unbound work items"
1662         depends on DEBUG_KERNEL
1663         default n
1664         help
1665           Workqueue used to implicitly guarantee that work items queued
1666           without explicit CPU specified are put on the local CPU.  This
1667           guarantee is no longer true and while local CPU is still
1668           preferred work items may be put on foreign CPUs.  Kernel
1669           parameter "workqueue.debug_force_rr_cpu" is added to force
1670           round-robin CPU selection to flush out usages which depend on the
1671           now broken guarantee.  This config option enables the debug
1672           feature by default.  When enabled, memory and cache locality will
1673           be impacted.
1674
1675 config DEBUG_BLOCK_EXT_DEVT
1676         bool "Force extended block device numbers and spread them"
1677         depends on DEBUG_KERNEL
1678         depends on BLOCK
1679         default n
1680         help
1681           BIG FAT WARNING: ENABLING THIS OPTION MIGHT BREAK BOOTING ON
1682           SOME DISTRIBUTIONS.  DO NOT ENABLE THIS UNLESS YOU KNOW WHAT
1683           YOU ARE DOING.  Distros, please enable this and fix whatever
1684           is broken.
1685
1686           Conventionally, block device numbers are allocated from
1687           predetermined contiguous area.  However, extended block area
1688           may introduce non-contiguous block device numbers.  This
1689           option forces most block device numbers to be allocated from
1690           the extended space and spreads them to discover kernel or
1691           userland code paths which assume predetermined contiguous
1692           device number allocation.
1693
1694           Note that turning on this debug option shuffles all the
1695           device numbers for all IDE and SCSI devices including libata
1696           ones, so root partition specified using device number
1697           directly (via rdev or root=MAJ:MIN) won't work anymore.
1698           Textual device names (root=/dev/sdXn) will continue to work.
1699
1700           Say N if you are unsure.
1701
1702 config CPU_HOTPLUG_STATE_CONTROL
1703         bool "Enable CPU hotplug state control"
1704         depends on DEBUG_KERNEL
1705         depends on HOTPLUG_CPU
1706         default n
1707         help
1708           Allows to write steps between "offline" and "online" to the CPUs
1709           sysfs target file so states can be stepped granular. This is a debug
1710           option for now as the hotplug machinery cannot be stopped and
1711           restarted at arbitrary points yet.
1712
1713           Say N if your are unsure.
1714
1715 config LATENCYTOP
1716         bool "Latency measuring infrastructure"
1717         depends on DEBUG_KERNEL
1718         depends on STACKTRACE_SUPPORT
1719         depends on PROC_FS
1720         depends on FRAME_POINTER || MIPS || PPC || S390 || MICROBLAZE || ARM || ARC || X86
1721         select KALLSYMS
1722         select KALLSYMS_ALL
1723         select STACKTRACE
1724         select SCHEDSTATS
1725         help
1726           Enable this option if you want to use the LatencyTOP tool
1727           to find out which userspace is blocking on what kernel operations.
1728
1729 source "kernel/trace/Kconfig"
1730
1731 config PROVIDE_OHCI1394_DMA_INIT
1732         bool "Remote debugging over FireWire early on boot"
1733         depends on PCI && X86
1734         help
1735           If you want to debug problems which hang or crash the kernel early
1736           on boot and the crashing machine has a FireWire port, you can use
1737           this feature to remotely access the memory of the crashed machine
1738           over FireWire. This employs remote DMA as part of the OHCI1394
1739           specification which is now the standard for FireWire controllers.
1740
1741           With remote DMA, you can monitor the printk buffer remotely using
1742           firescope and access all memory below 4GB using fireproxy from gdb.
1743           Even controlling a kernel debugger is possible using remote DMA.
1744
1745           Usage:
1746
1747           If ohci1394_dma=early is used as boot parameter, it will initialize
1748           all OHCI1394 controllers which are found in the PCI config space.
1749
1750           As all changes to the FireWire bus such as enabling and disabling
1751           devices cause a bus reset and thereby disable remote DMA for all
1752           devices, be sure to have the cable plugged and FireWire enabled on
1753           the debugging host before booting the debug target for debugging.
1754
1755           This code (~1k) is freed after boot. By then, the firewire stack
1756           in charge of the OHCI-1394 controllers should be used instead.
1757
1758           See Documentation/core-api/debugging-via-ohci1394.rst for more information.
1759
1760 source "samples/Kconfig"
1761
1762 config ARCH_HAS_DEVMEM_IS_ALLOWED
1763         bool
1764
1765 config STRICT_DEVMEM
1766         bool "Filter access to /dev/mem"
1767         depends on MMU && DEVMEM
1768         depends on ARCH_HAS_DEVMEM_IS_ALLOWED || GENERIC_LIB_DEVMEM_IS_ALLOWED
1769         default y if PPC || X86 || ARM64
1770         help
1771           If this option is disabled, you allow userspace (root) access to all
1772           of memory, including kernel and userspace memory. Accidental
1773           access to this is obviously disastrous, but specific access can
1774           be used by people debugging the kernel. Note that with PAT support
1775           enabled, even in this case there are restrictions on /dev/mem
1776           use due to the cache aliasing requirements.
1777
1778           If this option is switched on, and IO_STRICT_DEVMEM=n, the /dev/mem
1779           file only allows userspace access to PCI space and the BIOS code and
1780           data regions.  This is sufficient for dosemu and X and all common
1781           users of /dev/mem.
1782
1783           If in doubt, say Y.
1784
1785 config IO_STRICT_DEVMEM
1786         bool "Filter I/O access to /dev/mem"
1787         depends on STRICT_DEVMEM
1788         help
1789           If this option is disabled, you allow userspace (root) access to all
1790           io-memory regardless of whether a driver is actively using that
1791           range.  Accidental access to this is obviously disastrous, but
1792           specific access can be used by people debugging kernel drivers.
1793
1794           If this option is switched on, the /dev/mem file only allows
1795           userspace access to *idle* io-memory ranges (see /proc/iomem) This
1796           may break traditional users of /dev/mem (dosemu, legacy X, etc...)
1797           if the driver using a given range cannot be disabled.
1798
1799           If in doubt, say Y.
1800
1801 menu "$(SRCARCH) Debugging"
1802
1803 source "arch/$(SRCARCH)/Kconfig.debug"
1804
1805 endmenu
1806
1807 menu "Kernel Testing and Coverage"
1808
1809 source "lib/kunit/Kconfig"
1810
1811 config NOTIFIER_ERROR_INJECTION
1812         tristate "Notifier error injection"
1813         depends on DEBUG_KERNEL
1814         select DEBUG_FS
1815         help
1816           This option provides the ability to inject artificial errors to
1817           specified notifier chain callbacks. It is useful to test the error
1818           handling of notifier call chain failures.
1819
1820           Say N if unsure.
1821
1822 config PM_NOTIFIER_ERROR_INJECT
1823         tristate "PM notifier error injection module"
1824         depends on PM && NOTIFIER_ERROR_INJECTION
1825         default m if PM_DEBUG
1826         help
1827           This option provides the ability to inject artificial errors to
1828           PM notifier chain callbacks.  It is controlled through debugfs
1829           interface /sys/kernel/debug/notifier-error-inject/pm
1830
1831           If the notifier call chain should be failed with some events
1832           notified, write the error code to "actions/<notifier event>/error".
1833
1834           Example: Inject PM suspend error (-12 = -ENOMEM)
1835
1836           # cd /sys/kernel/debug/notifier-error-inject/pm/
1837           # echo -12 > actions/PM_SUSPEND_PREPARE/error
1838           # echo mem > /sys/power/state
1839           bash: echo: write error: Cannot allocate memory
1840
1841           To compile this code as a module, choose M here: the module will
1842           be called pm-notifier-error-inject.
1843
1844           If unsure, say N.
1845
1846 config OF_RECONFIG_NOTIFIER_ERROR_INJECT
1847         tristate "OF reconfig notifier error injection module"
1848         depends on OF_DYNAMIC && NOTIFIER_ERROR_INJECTION
1849         help
1850           This option provides the ability to inject artificial errors to
1851           OF reconfig notifier chain callbacks.  It is controlled
1852           through debugfs interface under
1853           /sys/kernel/debug/notifier-error-inject/OF-reconfig/
1854
1855           If the notifier call chain should be failed with some events
1856           notified, write the error code to "actions/<notifier event>/error".
1857
1858           To compile this code as a module, choose M here: the module will
1859           be called of-reconfig-notifier-error-inject.
1860
1861           If unsure, say N.
1862
1863 config NETDEV_NOTIFIER_ERROR_INJECT
1864         tristate "Netdev notifier error injection module"
1865         depends on NET && NOTIFIER_ERROR_INJECTION
1866         help
1867           This option provides the ability to inject artificial errors to
1868           netdevice notifier chain callbacks.  It is controlled through debugfs
1869           interface /sys/kernel/debug/notifier-error-inject/netdev
1870
1871           If the notifier call chain should be failed with some events
1872           notified, write the error code to "actions/<notifier event>/error".
1873
1874           Example: Inject netdevice mtu change error (-22 = -EINVAL)
1875
1876           # cd /sys/kernel/debug/notifier-error-inject/netdev
1877           # echo -22 > actions/NETDEV_CHANGEMTU/error
1878           # ip link set eth0 mtu 1024
1879           RTNETLINK answers: Invalid argument
1880
1881           To compile this code as a module, choose M here: the module will
1882           be called netdev-notifier-error-inject.
1883
1884           If unsure, say N.
1885
1886 config FUNCTION_ERROR_INJECTION
1887         def_bool y
1888         depends on HAVE_FUNCTION_ERROR_INJECTION && KPROBES
1889
1890 config FAULT_INJECTION
1891         bool "Fault-injection framework"
1892         depends on DEBUG_KERNEL
1893         help
1894           Provide fault-injection framework.
1895           For more details, see Documentation/fault-injection/.
1896
1897 config FAILSLAB
1898         bool "Fault-injection capability for kmalloc"
1899         depends on FAULT_INJECTION
1900         depends on SLAB || SLUB
1901         help
1902           Provide fault-injection capability for kmalloc.
1903
1904 config FAIL_PAGE_ALLOC
1905         bool "Fault-injection capability for alloc_pages()"
1906         depends on FAULT_INJECTION
1907         help
1908           Provide fault-injection capability for alloc_pages().
1909
1910 config FAULT_INJECTION_USERCOPY
1911         bool "Fault injection capability for usercopy functions"
1912         depends on FAULT_INJECTION
1913         help
1914           Provides fault-injection capability to inject failures
1915           in usercopy functions (copy_from_user(), get_user(), ...).
1916
1917 config FAIL_MAKE_REQUEST
1918         bool "Fault-injection capability for disk IO"
1919         depends on FAULT_INJECTION && BLOCK
1920         help
1921           Provide fault-injection capability for disk IO.
1922
1923 config FAIL_IO_TIMEOUT
1924         bool "Fault-injection capability for faking disk interrupts"
1925         depends on FAULT_INJECTION && BLOCK
1926         help
1927           Provide fault-injection capability on end IO handling. This
1928           will make the block layer "forget" an interrupt as configured,
1929           thus exercising the error handling.
1930
1931           Only works with drivers that use the generic timeout handling,
1932           for others it wont do anything.
1933
1934 config FAIL_FUTEX
1935         bool "Fault-injection capability for futexes"
1936         select DEBUG_FS
1937         depends on FAULT_INJECTION && FUTEX
1938         help
1939           Provide fault-injection capability for futexes.
1940
1941 config FAULT_INJECTION_DEBUG_FS
1942         bool "Debugfs entries for fault-injection capabilities"
1943         depends on FAULT_INJECTION && SYSFS && DEBUG_FS
1944         help
1945           Enable configuration of fault-injection capabilities via debugfs.
1946
1947 config FAIL_FUNCTION
1948         bool "Fault-injection capability for functions"
1949         depends on FAULT_INJECTION_DEBUG_FS && FUNCTION_ERROR_INJECTION
1950         help
1951           Provide function-based fault-injection capability.
1952           This will allow you to override a specific function with a return
1953           with given return value. As a result, function caller will see
1954           an error value and have to handle it. This is useful to test the
1955           error handling in various subsystems.
1956
1957 config FAIL_MMC_REQUEST
1958         bool "Fault-injection capability for MMC IO"
1959         depends on FAULT_INJECTION_DEBUG_FS && MMC
1960         help
1961           Provide fault-injection capability for MMC IO.
1962           This will make the mmc core return data errors. This is
1963           useful to test the error handling in the mmc block device
1964           and to test how the mmc host driver handles retries from
1965           the block device.
1966
1967 config FAULT_INJECTION_STACKTRACE_FILTER
1968         bool "stacktrace filter for fault-injection capabilities"
1969         depends on FAULT_INJECTION_DEBUG_FS && STACKTRACE_SUPPORT
1970         depends on !X86_64
1971         select STACKTRACE
1972         depends on FRAME_POINTER || MIPS || PPC || S390 || MICROBLAZE || ARM || ARC || X86
1973         help
1974           Provide stacktrace filter for fault-injection capabilities
1975
1976 config ARCH_HAS_KCOV
1977         bool
1978         help
1979           An architecture should select this when it can successfully
1980           build and run with CONFIG_KCOV. This typically requires
1981           disabling instrumentation for some early boot code.
1982
1983 config CC_HAS_SANCOV_TRACE_PC
1984         def_bool $(cc-option,-fsanitize-coverage=trace-pc)
1985
1986
1987 config KCOV
1988         bool "Code coverage for fuzzing"
1989         depends on ARCH_HAS_KCOV
1990         depends on CC_HAS_SANCOV_TRACE_PC || GCC_PLUGINS
1991         select DEBUG_FS
1992         select GCC_PLUGIN_SANCOV if !CC_HAS_SANCOV_TRACE_PC
1993         help
1994           KCOV exposes kernel code coverage information in a form suitable
1995           for coverage-guided fuzzing (randomized testing).
1996
1997           If RANDOMIZE_BASE is enabled, PC values will not be stable across
1998           different machines and across reboots. If you need stable PC values,
1999           disable RANDOMIZE_BASE.
2000
2001           For more details, see Documentation/dev-tools/kcov.rst.
2002
2003 config KCOV_ENABLE_COMPARISONS
2004         bool "Enable comparison operands collection by KCOV"
2005         depends on KCOV
2006         depends on $(cc-option,-fsanitize-coverage=trace-cmp)
2007         help
2008           KCOV also exposes operands of every comparison in the instrumented
2009           code along with operand sizes and PCs of the comparison instructions.
2010           These operands can be used by fuzzing engines to improve the quality
2011           of fuzzing coverage.
2012
2013 config KCOV_INSTRUMENT_ALL
2014         bool "Instrument all code by default"
2015         depends on KCOV
2016         default y
2017         help
2018           If you are doing generic system call fuzzing (like e.g. syzkaller),
2019           then you will want to instrument the whole kernel and you should
2020           say y here. If you are doing more targeted fuzzing (like e.g.
2021           filesystem fuzzing with AFL) then you will want to enable coverage
2022           for more specific subsets of files, and should say n here.
2023
2024 config KCOV_IRQ_AREA_SIZE
2025         hex "Size of interrupt coverage collection area in words"
2026         depends on KCOV
2027         default 0x40000
2028         help
2029           KCOV uses preallocated per-cpu areas to collect coverage from
2030           soft interrupts. This specifies the size of those areas in the
2031           number of unsigned long words.
2032
2033 menuconfig RUNTIME_TESTING_MENU
2034         bool "Runtime Testing"
2035         def_bool y
2036
2037 if RUNTIME_TESTING_MENU
2038
2039 config LKDTM
2040         tristate "Linux Kernel Dump Test Tool Module"
2041         depends on DEBUG_FS
2042         help
2043         This module enables testing of the different dumping mechanisms by
2044         inducing system failures at predefined crash points.
2045         If you don't need it: say N
2046         Choose M here to compile this code as a module. The module will be
2047         called lkdtm.
2048
2049         Documentation on how to use the module can be found in
2050         Documentation/fault-injection/provoke-crashes.rst
2051
2052 config TEST_LIST_SORT
2053         tristate "Linked list sorting test"
2054         depends on DEBUG_KERNEL || m
2055         help
2056           Enable this to turn on 'list_sort()' function test. This test is
2057           executed only once during system boot (so affects only boot time),
2058           or at module load time.
2059
2060           If unsure, say N.
2061
2062 config TEST_MIN_HEAP
2063         tristate "Min heap test"
2064         depends on DEBUG_KERNEL || m
2065         help
2066           Enable this to turn on min heap function tests. This test is
2067           executed only once during system boot (so affects only boot time),
2068           or at module load time.
2069
2070           If unsure, say N.
2071
2072 config TEST_SORT
2073         tristate "Array-based sort test"
2074         depends on DEBUG_KERNEL || m
2075         help
2076           This option enables the self-test function of 'sort()' at boot,
2077           or at module load time.
2078
2079           If unsure, say N.
2080
2081 config TEST_DIV64
2082         tristate "64bit/32bit division and modulo test"
2083         depends on DEBUG_KERNEL || m
2084         help
2085           Enable this to turn on 'do_div()' function test. This test is
2086           executed only once during system boot (so affects only boot time),
2087           or at module load time.
2088
2089           If unsure, say N.
2090
2091 config KPROBES_SANITY_TEST
2092         bool "Kprobes sanity tests"
2093         depends on DEBUG_KERNEL
2094         depends on KPROBES
2095         help
2096           This option provides for testing basic kprobes functionality on
2097           boot. Samples of kprobe and kretprobe are inserted and
2098           verified for functionality.
2099
2100           Say N if you are unsure.
2101
2102 config BACKTRACE_SELF_TEST
2103         tristate "Self test for the backtrace code"
2104         depends on DEBUG_KERNEL
2105         help
2106           This option provides a kernel module that can be used to test
2107           the kernel stack backtrace code. This option is not useful
2108           for distributions or general kernels, but only for kernel
2109           developers working on architecture code.
2110
2111           Note that if you want to also test saved backtraces, you will
2112           have to enable STACKTRACE as well.
2113
2114           Say N if you are unsure.
2115
2116 config RBTREE_TEST
2117         tristate "Red-Black tree test"
2118         depends on DEBUG_KERNEL
2119         help
2120           A benchmark measuring the performance of the rbtree library.
2121           Also includes rbtree invariant checks.
2122
2123 config REED_SOLOMON_TEST
2124         tristate "Reed-Solomon library test"
2125         depends on DEBUG_KERNEL || m
2126         select REED_SOLOMON
2127         select REED_SOLOMON_ENC16
2128         select REED_SOLOMON_DEC16
2129         help
2130           This option enables the self-test function of rslib at boot,
2131           or at module load time.
2132
2133           If unsure, say N.
2134
2135 config INTERVAL_TREE_TEST
2136         tristate "Interval tree test"
2137         depends on DEBUG_KERNEL
2138         select INTERVAL_TREE
2139         help
2140           A benchmark measuring the performance of the interval tree library
2141
2142 config PERCPU_TEST
2143         tristate "Per cpu operations test"
2144         depends on m && DEBUG_KERNEL
2145         help
2146           Enable this option to build test module which validates per-cpu
2147           operations.
2148
2149           If unsure, say N.
2150
2151 config ATOMIC64_SELFTEST
2152         tristate "Perform an atomic64_t self-test"
2153         help
2154           Enable this option to test the atomic64_t functions at boot or
2155           at module load time.
2156
2157           If unsure, say N.
2158
2159 config ASYNC_RAID6_TEST
2160         tristate "Self test for hardware accelerated raid6 recovery"
2161         depends on ASYNC_RAID6_RECOV
2162         select ASYNC_MEMCPY
2163         help
2164           This is a one-shot self test that permutes through the
2165           recovery of all the possible two disk failure scenarios for a
2166           N-disk array.  Recovery is performed with the asynchronous
2167           raid6 recovery routines, and will optionally use an offload
2168           engine if one is available.
2169
2170           If unsure, say N.
2171
2172 config TEST_HEXDUMP
2173         tristate "Test functions located in the hexdump module at runtime"
2174
2175 config TEST_STRING_HELPERS
2176         tristate "Test functions located in the string_helpers module at runtime"
2177
2178 config TEST_STRSCPY
2179         tristate "Test strscpy*() family of functions at runtime"
2180
2181 config TEST_KSTRTOX
2182         tristate "Test kstrto*() family of functions at runtime"
2183
2184 config TEST_PRINTF
2185         tristate "Test printf() family of functions at runtime"
2186
2187 config TEST_BITMAP
2188         tristate "Test bitmap_*() family of functions at runtime"
2189         help
2190           Enable this option to test the bitmap functions at boot.
2191
2192           If unsure, say N.
2193
2194 config TEST_UUID
2195         tristate "Test functions located in the uuid module at runtime"
2196
2197 config TEST_XARRAY
2198         tristate "Test the XArray code at runtime"
2199
2200 config TEST_OVERFLOW
2201         tristate "Test check_*_overflow() functions at runtime"
2202
2203 config TEST_RHASHTABLE
2204         tristate "Perform selftest on resizable hash table"
2205         help
2206           Enable this option to test the rhashtable functions at boot.
2207
2208           If unsure, say N.
2209
2210 config TEST_HASH
2211         tristate "Perform selftest on hash functions"
2212         help
2213           Enable this option to test the kernel's integer (<linux/hash.h>),
2214           string (<linux/stringhash.h>), and siphash (<linux/siphash.h>)
2215           hash functions on boot (or module load).
2216
2217           This is intended to help people writing architecture-specific
2218           optimized versions.  If unsure, say N.
2219
2220 config TEST_IDA
2221         tristate "Perform selftest on IDA functions"
2222
2223 config TEST_PARMAN
2224         tristate "Perform selftest on priority array manager"
2225         depends on PARMAN
2226         help
2227           Enable this option to test priority array manager on boot
2228           (or module load).
2229
2230           If unsure, say N.
2231
2232 config TEST_IRQ_TIMINGS
2233         bool "IRQ timings selftest"
2234         depends on IRQ_TIMINGS
2235         help
2236           Enable this option to test the irq timings code on boot.
2237
2238           If unsure, say N.
2239
2240 config TEST_LKM
2241         tristate "Test module loading with 'hello world' module"
2242         depends on m
2243         help
2244           This builds the "test_module" module that emits "Hello, world"
2245           on printk when loaded. It is designed to be used for basic
2246           evaluation of the module loading subsystem (for example when
2247           validating module verification). It lacks any extra dependencies,
2248           and will not normally be loaded by the system unless explicitly
2249           requested by name.
2250
2251           If unsure, say N.
2252
2253 config TEST_BITOPS
2254         tristate "Test module for compilation of bitops operations"
2255         depends on m
2256         help
2257           This builds the "test_bitops" module that is much like the
2258           TEST_LKM module except that it does a basic exercise of the
2259           set/clear_bit macros and get_count_order/long to make sure there are
2260           no compiler warnings from C=1 sparse checker or -Wextra
2261           compilations. It has no dependencies and doesn't run or load unless
2262           explicitly requested by name.  for example: modprobe test_bitops.
2263
2264           If unsure, say N.
2265
2266 config TEST_VMALLOC
2267         tristate "Test module for stress/performance analysis of vmalloc allocator"
2268         default n
2269        depends on MMU
2270         depends on m
2271         help
2272           This builds the "test_vmalloc" module that should be used for
2273           stress and performance analysis. So, any new change for vmalloc
2274           subsystem can be evaluated from performance and stability point
2275           of view.
2276
2277           If unsure, say N.
2278
2279 config TEST_USER_COPY
2280         tristate "Test user/kernel boundary protections"
2281         depends on m
2282         help
2283           This builds the "test_user_copy" module that runs sanity checks
2284           on the copy_to/from_user infrastructure, making sure basic
2285           user/kernel boundary testing is working. If it fails to load,
2286           a regression has been detected in the user/kernel memory boundary
2287           protections.
2288
2289           If unsure, say N.
2290
2291 config TEST_BPF
2292         tristate "Test BPF filter functionality"
2293         depends on m && NET
2294         help
2295           This builds the "test_bpf" module that runs various test vectors
2296           against the BPF interpreter or BPF JIT compiler depending on the
2297           current setting. This is in particular useful for BPF JIT compiler
2298           development, but also to run regression tests against changes in
2299           the interpreter code. It also enables test stubs for eBPF maps and
2300           verifier used by user space verifier testsuite.
2301
2302           If unsure, say N.
2303
2304 config TEST_BLACKHOLE_DEV
2305         tristate "Test blackhole netdev functionality"
2306         depends on m && NET
2307         help
2308           This builds the "test_blackhole_dev" module that validates the
2309           data path through this blackhole netdev.
2310
2311           If unsure, say N.
2312
2313 config FIND_BIT_BENCHMARK
2314         tristate "Test find_bit functions"
2315         help
2316           This builds the "test_find_bit" module that measure find_*_bit()
2317           functions performance.
2318
2319           If unsure, say N.
2320
2321 config TEST_FIRMWARE
2322         tristate "Test firmware loading via userspace interface"
2323         depends on FW_LOADER
2324         help
2325           This builds the "test_firmware" module that creates a userspace
2326           interface for testing firmware loading. This can be used to
2327           control the triggering of firmware loading without needing an
2328           actual firmware-using device. The contents can be rechecked by
2329           userspace.
2330
2331           If unsure, say N.
2332
2333 config TEST_SYSCTL
2334         tristate "sysctl test driver"
2335         depends on PROC_SYSCTL
2336         help
2337           This builds the "test_sysctl" module. This driver enables to test the
2338           proc sysctl interfaces available to drivers safely without affecting
2339           production knobs which might alter system functionality.
2340
2341           If unsure, say N.
2342
2343 config BITFIELD_KUNIT
2344         tristate "KUnit test bitfield functions at runtime"
2345         depends on KUNIT
2346         help
2347           Enable this option to test the bitfield functions at boot.
2348
2349           KUnit tests run during boot and output the results to the debug log
2350           in TAP format (http://testanything.org/). Only useful for kernel devs
2351           running the KUnit test harness, and not intended for inclusion into a
2352           production build.
2353
2354           For more information on KUnit and unit tests in general please refer
2355           to the KUnit documentation in Documentation/dev-tools/kunit/.
2356
2357           If unsure, say N.
2358
2359 config RESOURCE_KUNIT_TEST
2360         tristate "KUnit test for resource API"
2361         depends on KUNIT
2362         help
2363           This builds the resource API unit test.
2364           Tests the logic of API provided by resource.c and ioport.h.
2365           For more information on KUnit and unit tests in general please refer
2366           to the KUnit documentation in Documentation/dev-tools/kunit/.
2367
2368           If unsure, say N.
2369
2370 config SYSCTL_KUNIT_TEST
2371         tristate "KUnit test for sysctl" if !KUNIT_ALL_TESTS
2372         depends on KUNIT
2373         default KUNIT_ALL_TESTS
2374         help
2375           This builds the proc sysctl unit test, which runs on boot.
2376           Tests the API contract and implementation correctness of sysctl.
2377           For more information on KUnit and unit tests in general please refer
2378           to the KUnit documentation in Documentation/dev-tools/kunit/.
2379
2380           If unsure, say N.
2381
2382 config LIST_KUNIT_TEST
2383         tristate "KUnit Test for Kernel Linked-list structures" if !KUNIT_ALL_TESTS
2384         depends on KUNIT
2385         default KUNIT_ALL_TESTS
2386         help
2387           This builds the linked list KUnit test suite.
2388           It tests that the API and basic functionality of the list_head type
2389           and associated macros.
2390
2391           KUnit tests run during boot and output the results to the debug log
2392           in TAP format (https://testanything.org/). Only useful for kernel devs
2393           running the KUnit test harness, and not intended for inclusion into a
2394           production build.
2395
2396           For more information on KUnit and unit tests in general please refer
2397           to the KUnit documentation in Documentation/dev-tools/kunit/.
2398
2399           If unsure, say N.
2400
2401 config LINEAR_RANGES_TEST
2402         tristate "KUnit test for linear_ranges"
2403         depends on KUNIT
2404         select LINEAR_RANGES
2405         help
2406           This builds the linear_ranges unit test, which runs on boot.
2407           Tests the linear_ranges logic correctness.
2408           For more information on KUnit and unit tests in general please refer
2409           to the KUnit documentation in Documentation/dev-tools/kunit/.
2410
2411           If unsure, say N.
2412
2413 config CMDLINE_KUNIT_TEST
2414         tristate "KUnit test for cmdline API"
2415         depends on KUNIT
2416         help
2417           This builds the cmdline API unit test.
2418           Tests the logic of API provided by cmdline.c.
2419           For more information on KUnit and unit tests in general please refer
2420           to the KUnit documentation in Documentation/dev-tools/kunit/.
2421
2422           If unsure, say N.
2423
2424 config BITS_TEST
2425         tristate "KUnit test for bits.h"
2426         depends on KUNIT
2427         help
2428           This builds the bits unit test.
2429           Tests the logic of macros defined in bits.h.
2430           For more information on KUnit and unit tests in general please refer
2431           to the KUnit documentation in Documentation/dev-tools/kunit/.
2432
2433           If unsure, say N.
2434
2435 config SLUB_KUNIT_TEST
2436         tristate "KUnit test for SLUB cache error detection" if !KUNIT_ALL_TESTS
2437         depends on SLUB_DEBUG && KUNIT
2438         default KUNIT_ALL_TESTS
2439         help
2440           This builds SLUB allocator unit test.
2441           Tests SLUB cache debugging functionality.
2442           For more information on KUnit and unit tests in general please refer
2443           to the KUnit documentation in Documentation/dev-tools/kunit/.
2444
2445           If unsure, say N.
2446
2447 config RATIONAL_KUNIT_TEST
2448         tristate "KUnit test for rational.c" if !KUNIT_ALL_TESTS
2449         depends on KUNIT
2450         select RATIONAL
2451         default KUNIT_ALL_TESTS
2452         help
2453           This builds the rational math unit test.
2454           For more information on KUnit and unit tests in general please refer
2455           to the KUnit documentation in Documentation/dev-tools/kunit/.
2456
2457           If unsure, say N.
2458
2459 config TEST_UDELAY
2460         tristate "udelay test driver"
2461         help
2462           This builds the "udelay_test" module that helps to make sure
2463           that udelay() is working properly.
2464
2465           If unsure, say N.
2466
2467 config TEST_STATIC_KEYS
2468         tristate "Test static keys"
2469         depends on m
2470         help
2471           Test the static key interfaces.
2472
2473           If unsure, say N.
2474
2475 config TEST_KMOD
2476         tristate "kmod stress tester"
2477         depends on m
2478         depends on NETDEVICES && NET_CORE && INET # for TUN
2479         depends on BLOCK
2480         select TEST_LKM
2481         select XFS_FS
2482         select TUN
2483         select BTRFS_FS
2484         help
2485           Test the kernel's module loading mechanism: kmod. kmod implements
2486           support to load modules using the Linux kernel's usermode helper.
2487           This test provides a series of tests against kmod.
2488
2489           Although technically you can either build test_kmod as a module or
2490           into the kernel we disallow building it into the kernel since
2491           it stress tests request_module() and this will very likely cause
2492           some issues by taking over precious threads available from other
2493           module load requests, ultimately this could be fatal.
2494
2495           To run tests run:
2496
2497           tools/testing/selftests/kmod/kmod.sh --help
2498
2499           If unsure, say N.
2500
2501 config TEST_DEBUG_VIRTUAL
2502         tristate "Test CONFIG_DEBUG_VIRTUAL feature"
2503         depends on DEBUG_VIRTUAL
2504         help
2505           Test the kernel's ability to detect incorrect calls to
2506           virt_to_phys() done against the non-linear part of the
2507           kernel's virtual address map.
2508
2509           If unsure, say N.
2510
2511 config TEST_MEMCAT_P
2512         tristate "Test memcat_p() helper function"
2513         help
2514           Test the memcat_p() helper for correctly merging two
2515           pointer arrays together.
2516
2517           If unsure, say N.
2518
2519 config TEST_LIVEPATCH
2520         tristate "Test livepatching"
2521         default n
2522         depends on DYNAMIC_DEBUG
2523         depends on LIVEPATCH
2524         depends on m
2525         help
2526           Test kernel livepatching features for correctness.  The tests will
2527           load test modules that will be livepatched in various scenarios.
2528
2529           To run all the livepatching tests:
2530
2531           make -C tools/testing/selftests TARGETS=livepatch run_tests
2532
2533           Alternatively, individual tests may be invoked:
2534
2535           tools/testing/selftests/livepatch/test-callbacks.sh
2536           tools/testing/selftests/livepatch/test-livepatch.sh
2537           tools/testing/selftests/livepatch/test-shadow-vars.sh
2538
2539           If unsure, say N.
2540
2541 config TEST_OBJAGG
2542         tristate "Perform selftest on object aggreration manager"
2543         default n
2544         depends on OBJAGG
2545         help
2546           Enable this option to test object aggregation manager on boot
2547           (or module load).
2548
2549
2550 config TEST_STACKINIT
2551         tristate "Test level of stack variable initialization"
2552         help
2553           Test if the kernel is zero-initializing stack variables and
2554           padding. Coverage is controlled by compiler flags,
2555           CONFIG_GCC_PLUGIN_STRUCTLEAK, CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF,
2556           or CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL.
2557
2558           If unsure, say N.
2559
2560 config TEST_MEMINIT
2561         tristate "Test heap/page initialization"
2562         help
2563           Test if the kernel is zero-initializing heap and page allocations.
2564           This can be useful to test init_on_alloc and init_on_free features.
2565
2566           If unsure, say N.
2567
2568 config TEST_HMM
2569         tristate "Test HMM (Heterogeneous Memory Management)"
2570         depends on TRANSPARENT_HUGEPAGE
2571         depends on DEVICE_PRIVATE
2572         select HMM_MIRROR
2573         select MMU_NOTIFIER
2574         help
2575           This is a pseudo device driver solely for testing HMM.
2576           Say M here if you want to build the HMM test module.
2577           Doing so will allow you to run tools/testing/selftest/vm/hmm-tests.
2578
2579           If unsure, say N.
2580
2581 config TEST_FREE_PAGES
2582         tristate "Test freeing pages"
2583         help
2584           Test that a memory leak does not occur due to a race between
2585           freeing a block of pages and a speculative page reference.
2586           Loading this module is safe if your kernel has the bug fixed.
2587           If the bug is not fixed, it will leak gigabytes of memory and
2588           probably OOM your system.
2589
2590 config TEST_FPU
2591         tristate "Test floating point operations in kernel space"
2592         depends on X86 && !KCOV_INSTRUMENT_ALL
2593         help
2594           Enable this option to add /sys/kernel/debug/selftest_helpers/test_fpu
2595           which will trigger a sequence of floating point operations. This is used
2596           for self-testing floating point control register setting in
2597           kernel_fpu_begin().
2598
2599           If unsure, say N.
2600
2601 endif # RUNTIME_TESTING_MENU
2602
2603 config ARCH_USE_MEMTEST
2604         bool
2605         help
2606           An architecture should select this when it uses early_memtest()
2607           during boot process.
2608
2609 config MEMTEST
2610         bool "Memtest"
2611         depends on ARCH_USE_MEMTEST
2612         help
2613           This option adds a kernel parameter 'memtest', which allows memtest
2614           to be set and executed.
2615                 memtest=0, mean disabled; -- default
2616                 memtest=1, mean do 1 test pattern;
2617                 ...
2618                 memtest=17, mean do 17 test patterns.
2619           If you are unsure how to answer this question, answer N.
2620
2621
2622
2623 config HYPERV_TESTING
2624         bool "Microsoft Hyper-V driver testing"
2625         default n
2626         depends on HYPERV && DEBUG_FS
2627         help
2628           Select this option to enable Hyper-V vmbus testing.
2629
2630 endmenu # "Kernel Testing and Coverage"
2631
2632 source "Documentation/Kconfig"
2633
2634 endmenu # Kernel hacking