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