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