path: root/lib/Kconfig.debug (plain)
blob: 598e92cab8e8ebe36083e62c4afaf72eebc918b5

1	menu "printk and dmesg options"
2
3	config 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
18	config 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
29	config 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
47	config 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
116	endmenu # "printk and dmesg options"
117
118	menu "Compile-time checks and compiler options"
119
120	config 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
133	config 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
146	config DEBUG_INFO_SPLIT
147	bool "Produce split debuginfo in .dwo files"
148	depends on DEBUG_INFO && !FRV
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
161	config 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
170	config 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
181	config 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
189	config 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
197	config FRAME_WARN
198	int "Warn for stack frames larger than (needs gcc 4.4)"
199	range 0 8192
200	default 2048 if GCC_PLUGIN_LATENT_ENTROPY
201	default 2048 if ARM64_A32
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
210	config 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
218	config 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
227	config 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
243	config 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
260	config 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
273	config 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
287	config 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
318	config 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	#
332	config ARCH_WANT_FRAME_POINTERS
333	bool
334	help
335
336	config 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
348	config 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
360	config 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
375	endmenu # "Compiler options"
376
377	config 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
391	config 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
400	config 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
406	menu "Memory Debugging"
407
408	source mm/Kconfig.debug
409
410	config 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
418	config 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
424	config 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
433	config 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
441	config 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
449	config 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
455	config 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
463	config 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
471	config 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
479	config DEBUG_SLAB_LEAK
480	bool "Memory leak debugging"
481	depends on DEBUG_SLAB
482
483	config 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
496	config 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
509	config HAVE_DEBUG_KMEMLEAK
510	bool
511
512	config 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
535	config 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
547	config 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
555	config 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
562	config 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
571	config 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
580	config 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
590	config 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
598	config 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
606	config 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
615	config 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
622	config 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
634	config 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
657	config 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
668	config 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
675	config HAVE_DEBUG_STACKOVERFLOW
676	bool
677
678	config 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
696	source "lib/Kconfig.kmemcheck"
697
698	source "lib/Kconfig.kasan"
699
700	endmenu # "Memory Debugging"
701
702	config 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
709	config 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
725	config 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
736	config 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
745	menu "Debug Lockups and Hangs"
746
747	config 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	If NMIs are not available on the platform, every 12 seconds the
768	hrtimer interrupt on one cpu will be used to check for hardlockups
769	on the next cpu.
770
771	The frequency of hrtimer and NMI events and the soft and hard lockup
772	thresholds can be controlled through the sysctl watchdog_thresh.
773
774	config HARDLOCKUP_DETECTOR_NMI
775	def_bool y
776	depends on LOCKUP_DETECTOR && !HAVE_NMI_WATCHDOG
777	depends on PERF_EVENTS && HAVE_PERF_EVENTS_NMI
778
779	config HARDLOCKUP_DETECTOR_OTHER_CPU
780	def_bool y
781	depends on LOCKUP_DETECTOR && SMP
782	depends on !HARDLOCKUP_DETECTOR_NMI && !HAVE_NMI_WATCHDOG
783
784	config HARDLOCKUP_DETECTOR
785	def_bool y
786	depends on HARDLOCKUP_DETECTOR_NMI || HARDLOCKUP_DETECTOR_OTHER_CPU
787
788	config BOOTPARAM_HARDLOCKUP_PANIC
789	bool "Panic (Reboot) On Hard Lockups"
790	depends on HARDLOCKUP_DETECTOR
791	help
792	Say Y here to enable the kernel to panic on "hard lockups",
793	which are bugs that cause the kernel to loop in kernel
794	mode with interrupts disabled for more than 10 seconds (configurable
795	using the watchdog_thresh sysctl).
796
797	Say N if unsure.
798
799	config BOOTPARAM_HARDLOCKUP_PANIC_VALUE
800	int
801	depends on HARDLOCKUP_DETECTOR
802	range 0 1
803	default 0 if !BOOTPARAM_HARDLOCKUP_PANIC
804	default 1 if BOOTPARAM_HARDLOCKUP_PANIC
805
806	config BOOTPARAM_SOFTLOCKUP_PANIC
807	bool "Panic (Reboot) On Soft Lockups"
808	depends on LOCKUP_DETECTOR
809	help
810	Say Y here to enable the kernel to panic on "soft lockups",
811	which are bugs that cause the kernel to loop in kernel
812	mode for more than 20 seconds (configurable using the watchdog_thresh
813	sysctl), without giving other tasks a chance to run.
814
815	The panic can be used in combination with panic_timeout,
816	to cause the system to reboot automatically after a
817	lockup has been detected. This feature is useful for
818	high-availability systems that have uptime guarantees and
819	where a lockup must be resolved ASAP.
820
821	Say N if unsure.
822
823	config BOOTPARAM_SOFTLOCKUP_PANIC_VALUE
824	int
825	depends on LOCKUP_DETECTOR
826	range 0 1
827	default 0 if !BOOTPARAM_SOFTLOCKUP_PANIC
828	default 1 if BOOTPARAM_SOFTLOCKUP_PANIC
829
830	config DETECT_HUNG_TASK
831	bool "Detect Hung Tasks"
832	depends on DEBUG_KERNEL
833	default LOCKUP_DETECTOR
834	help
835	Say Y here to enable the kernel to detect "hung tasks",
836	which are bugs that cause the task to be stuck in
837	uninterruptible "D" state indefinitely.
838
839	When a hung task is detected, the kernel will print the
840	current stack trace (which you should report), but the
841	task will stay in uninterruptible state. If lockdep is
842	enabled then all held locks will also be reported. This
843	feature has negligible overhead.
844
845	config DEFAULT_HUNG_TASK_TIMEOUT
846	int "Default timeout for hung task detection (in seconds)"
847	depends on DETECT_HUNG_TASK
848	default 120
849	help
850	This option controls the default timeout (in seconds) used
851	to determine when a task has become non-responsive and should
852	be considered hung.
853
854	It can be adjusted at runtime via the kernel.hung_task_timeout_secs
855	sysctl or by writing a value to
856	/proc/sys/kernel/hung_task_timeout_secs.
857
858	A timeout of 0 disables the check. The default is two minutes.
859	Keeping the default should be fine in most cases.
860
861	config BOOTPARAM_HUNG_TASK_PANIC
862	bool "Panic (Reboot) On Hung Tasks"
863	depends on DETECT_HUNG_TASK
864	help
865	Say Y here to enable the kernel to panic on "hung tasks",
866	which are bugs that cause the kernel to leave a task stuck
867	in uninterruptible "D" state.
868
869	The panic can be used in combination with panic_timeout,
870	to cause the system to reboot automatically after a
871	hung task has been detected. This feature is useful for
872	high-availability systems that have uptime guarantees and
873	where a hung tasks must be resolved ASAP.
874
875	Say N if unsure.
876
877	config BOOTPARAM_HUNG_TASK_PANIC_VALUE
878	int
879	depends on DETECT_HUNG_TASK
880	range 0 1
881	default 0 if !BOOTPARAM_HUNG_TASK_PANIC
882	default 1 if BOOTPARAM_HUNG_TASK_PANIC
883
884	config WQ_WATCHDOG
885	bool "Detect Workqueue Stalls"
886	depends on DEBUG_KERNEL
887	help
888	Say Y here to enable stall detection on workqueues. If a
889	worker pool doesn't make forward progress on a pending work
890	item for over a given amount of time, 30s by default, a
891	warning message is printed along with dump of workqueue
892	state. This can be configured through kernel parameter
893	"workqueue.watchdog_thresh" and its sysfs counterpart.
894
895	endmenu # "Debug lockups and hangs"
896
897	config PANIC_ON_OOPS
898	bool "Panic on Oops"
899	help
900	Say Y here to enable the kernel to panic when it oopses. This
901	has the same effect as setting oops=panic on the kernel command
902	line.
903
904	This feature is useful to ensure that the kernel does not do
905	anything erroneous after an oops which could result in data
906	corruption or other issues.
907
908	Say N if unsure.
909
910	config PANIC_ON_OOPS_VALUE
911	int
912	range 0 1
913	default 0 if !PANIC_ON_OOPS
914	default 1 if PANIC_ON_OOPS
915
916	config PANIC_TIMEOUT
917	int "panic timeout"
918	default 0
919	help
920	Set the timeout value (in seconds) until a reboot occurs when the
921	the kernel panics. If n = 0, then we wait forever. A timeout
922	value n > 0 will wait n seconds before rebooting, while a timeout
923	value n < 0 will reboot immediately.
924
925	config SCHED_DEBUG
926	bool "Collect scheduler debugging info"
927	depends on DEBUG_KERNEL && PROC_FS
928	default y
929	help
930	If you say Y here, the /proc/sched_debug file will be provided
931	that can help debug the scheduler. The runtime overhead of this
932	option is minimal.
933
934	config SCHED_INFO
935	bool
936	default n
937
938	config PANIC_ON_RT_THROTTLING
939	bool "Panic on RT throttling"
940	help
941	Say Y here to enable the kernel to panic when a realtime
942	runqueue is throttled. This may be useful for detecting
943	and debugging RT throttling issues.
944
945	Say N if unsure.
946
947	config SCHEDSTATS
948	bool "Collect scheduler statistics"
949	depends on DEBUG_KERNEL && PROC_FS
950	select SCHED_INFO
951	help
952	If you say Y here, additional code will be inserted into the
953	scheduler and related routines to collect statistics about
954	scheduler behavior and provide them in /proc/schedstat. These
955	stats may be useful for both tuning and debugging the scheduler
956	If you aren't debugging the scheduler or trying to tune a specific
957	application, you can say N to avoid the very slight overhead
958	this adds.
959
960	config SCHED_STACK_END_CHECK
961	bool "Detect stack corruption on calls to schedule()"
962	depends on DEBUG_KERNEL
963	default n
964	help
965	This option checks for a stack overrun on calls to schedule().
966	If the stack end location is found to be over written always panic as
967	the content of the corrupted region can no longer be trusted.
968	This is to ensure no erroneous behaviour occurs which could result in
969	data corruption or a sporadic crash at a later stage once the region
970	is examined. The runtime overhead introduced is minimal.
971
972	config DEBUG_TIMEKEEPING
973	bool "Enable extra timekeeping sanity checking"
974	help
975	This option will enable additional timekeeping sanity checks
976	which may be helpful when diagnosing issues where timekeeping
977	problems are suspected.
978
979	This may include checks in the timekeeping hotpaths, so this
980	option may have a (very small) performance impact to some
981	workloads.
982
983	If unsure, say N.
984
985	config TIMER_STATS
986	bool "Collect kernel timers statistics"
987	depends on DEBUG_KERNEL && PROC_FS
988	help
989	If you say Y here, additional code will be inserted into the
990	timer routines to collect statistics about kernel timers being
991	reprogrammed. The statistics can be read from /proc/timer_stats.
992	The statistics collection is started by writing 1 to /proc/timer_stats,
993	writing 0 stops it. This feature is useful to collect information
994	about timer usage patterns in kernel and userspace. This feature
995	is lightweight if enabled in the kernel config but not activated
996	(it defaults to deactivated on bootup and will only be activated
997	if some application like powertop activates it explicitly).
998
999	config DEBUG_PREEMPT
1000	bool "Debug preemptible kernel"
1001	depends on DEBUG_KERNEL && PREEMPT && TRACE_IRQFLAGS_SUPPORT
1002	default y
1003	help
1004	If you say Y here then the kernel will use a debug variant of the
1005	commonly used smp_processor_id() function and will print warnings
1006	if kernel code uses it in a preemption-unsafe way. Also, the kernel
1007	will detect preemption count underflows.
1008
1009	menu "Lock Debugging (spinlocks, mutexes, etc...)"
1010
1011	config DEBUG_RT_MUTEXES
1012	bool "RT Mutex debugging, deadlock detection"
1013	depends on DEBUG_KERNEL && RT_MUTEXES
1014	help
1015	This allows rt mutex semantics violations and rt mutex related
1016	deadlocks (lockups) to be detected and reported automatically.
1017
1018	config DEBUG_SPINLOCK
1019	bool "Spinlock and rw-lock debugging: basic checks"
1020	depends on DEBUG_KERNEL
1021	select UNINLINE_SPIN_UNLOCK
1022	help
1023	Say Y here and build SMP to catch missing spinlock initialization
1024	and certain other kinds of spinlock errors commonly made. This is
1025	best used in conjunction with the NMI watchdog so that spinlock
1026	deadlocks are also debuggable.
1027
1028	config DEBUG_MUTEXES
1029	bool "Mutex debugging: basic checks"
1030	depends on DEBUG_KERNEL
1031	help
1032	This feature allows mutex semantics violations to be detected and
1033	reported.
1034
1035	config DEBUG_WW_MUTEX_SLOWPATH
1036	bool "Wait/wound mutex debugging: Slowpath testing"
1037	depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
1038	select DEBUG_LOCK_ALLOC
1039	select DEBUG_SPINLOCK
1040	select DEBUG_MUTEXES
1041	help
1042	This feature enables slowpath testing for w/w mutex users by
1043	injecting additional -EDEADLK wound/backoff cases. Together with
1044	the full mutex checks enabled with (CONFIG_PROVE_LOCKING) this
1045	will test all possible w/w mutex interface abuse with the
1046	exception of simply not acquiring all the required locks.
1047	Note that this feature can introduce significant overhead, so
1048	it really should not be enabled in a production or distro kernel,
1049	even a debug kernel. If you are a driver writer, enable it. If
1050	you are a distro, do not.
1051
1052	config DEBUG_LOCK_ALLOC
1053	bool "Lock debugging: detect incorrect freeing of live locks"
1054	depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
1055	select DEBUG_SPINLOCK
1056	select DEBUG_MUTEXES
1057	select LOCKDEP
1058	help
1059	This feature will check whether any held lock (spinlock, rwlock,
1060	mutex or rwsem) is incorrectly freed by the kernel, via any of the
1061	memory-freeing routines (kfree(), kmem_cache_free(), free_pages(),
1062	vfree(), etc.), whether a live lock is incorrectly reinitialized via
1063	spin_lock_init()/mutex_init()/etc., or whether there is any lock
1064	held during task exit.
1065
1066	config PROVE_LOCKING
1067	bool "Lock debugging: prove locking correctness"
1068	depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
1069	select LOCKDEP
1070	select DEBUG_SPINLOCK
1071	select DEBUG_MUTEXES
1072	select DEBUG_LOCK_ALLOC
1073	select TRACE_IRQFLAGS
1074	default n
1075	help
1076	This feature enables the kernel to prove that all locking
1077	that occurs in the kernel runtime is mathematically
1078	correct: that under no circumstance could an arbitrary (and
1079	not yet triggered) combination of observed locking
1080	sequences (on an arbitrary number of CPUs, running an
1081	arbitrary number of tasks and interrupt contexts) cause a
1082	deadlock.
1083
1084	In short, this feature enables the kernel to report locking
1085	related deadlocks before they actually occur.
1086
1087	The proof does not depend on how hard and complex a
1088	deadlock scenario would be to trigger: how many
1089	participant CPUs, tasks and irq-contexts would be needed
1090	for it to trigger. The proof also does not depend on
1091	timing: if a race and a resulting deadlock is possible
1092	theoretically (no matter how unlikely the race scenario
1093	is), it will be proven so and will immediately be
1094	reported by the kernel (once the event is observed that
1095	makes the deadlock theoretically possible).
1096
1097	If a deadlock is impossible (i.e. the locking rules, as
1098	observed by the kernel, are mathematically correct), the
1099	kernel reports nothing.
1100
1101	NOTE: this feature can also be enabled for rwlocks, mutexes
1102	and rwsems - in which case all dependencies between these
1103	different locking variants are observed and mapped too, and
1104	the proof of observed correctness is also maintained for an
1105	arbitrary combination of these separate locking variants.
1106
1107	For more details, see Documentation/locking/lockdep-design.txt.
1108
1109	config PROVE_LOCKING_SMALL
1110	bool
1111
1112	config LOCKDEP
1113	bool
1114	depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
1115	select STACKTRACE
1116	select FRAME_POINTER if !MIPS && !PPC && !ARM_UNWIND && !S390 && !MICROBLAZE && !ARC && !SCORE
1117	select KALLSYMS
1118	select KALLSYMS_ALL
1119
1120	config LOCK_STAT
1121	bool "Lock usage statistics"
1122	depends on DEBUG_KERNEL && TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
1123	select LOCKDEP
1124	select DEBUG_SPINLOCK
1125	select DEBUG_MUTEXES
1126	select DEBUG_LOCK_ALLOC
1127	default n
1128	help
1129	This feature enables tracking lock contention points
1130
1131	For more details, see Documentation/locking/lockstat.txt
1132
1133	This also enables lock events required by "perf lock",
1134	subcommand of perf.
1135	If you want to use "perf lock", you also need to turn on
1136	CONFIG_EVENT_TRACING.
1137
1138	CONFIG_LOCK_STAT defines "contended" and "acquired" lock events.
1139	(CONFIG_LOCKDEP defines "acquire" and "release" events.)
1140
1141	config DEBUG_LOCKDEP
1142	bool "Lock dependency engine debugging"
1143	depends on DEBUG_KERNEL && LOCKDEP
1144	help
1145	If you say Y here, the lock dependency engine will do
1146	additional runtime checks to debug itself, at the price
1147	of more runtime overhead.
1148
1149	config DEBUG_ATOMIC_SLEEP
1150	bool "Sleep inside atomic section checking"
1151	select PREEMPT_COUNT
1152	depends on DEBUG_KERNEL
1153	help
1154	If you say Y here, various routines which may sleep will become very
1155	noisy if they are called inside atomic sections: when a spinlock is
1156	held, inside an rcu read side critical section, inside preempt disabled
1157	sections, inside an interrupt, etc...
1158
1159	config DEBUG_LOCKING_API_SELFTESTS
1160	bool "Locking API boot-time self-tests"
1161	depends on DEBUG_KERNEL
1162	help
1163	Say Y here if you want the kernel to run a short self-test during
1164	bootup. The self-test checks whether common types of locking bugs
1165	are detected by debugging mechanisms or not. (if you disable
1166	lock debugging then those bugs wont be detected of course.)
1167	The following locking APIs are covered: spinlocks, rwlocks,
1168	mutexes and rwsems.
1169
1170	config LOCK_TORTURE_TEST
1171	tristate "torture tests for locking"
1172	depends on DEBUG_KERNEL
1173	select TORTURE_TEST
1174	default n
1175	help
1176	This option provides a kernel module that runs torture tests
1177	on kernel locking primitives. The kernel module may be built
1178	after the fact on the running kernel to be tested, if desired.
1179
1180	Say Y here if you want kernel locking-primitive torture tests
1181	to be built into the kernel.
1182	Say M if you want these torture tests to build as a module.
1183	Say N if you are unsure.
1184
1185	endmenu # lock debugging
1186
1187	config TRACE_IRQFLAGS
1188	bool
1189	help
1190	Enables hooks to interrupt enabling and disabling for
1191	either tracing or lock debugging.
1192
1193	config STACKTRACE
1194	bool "Stack backtrace support"
1195	depends on STACKTRACE_SUPPORT
1196	help
1197	This option causes the kernel to create a /proc/pid/stack for
1198	every process, showing its current stack trace.
1199	It is also used by various kernel debugging features that require
1200	stack trace generation.
1201
1202	config DEBUG_KOBJECT
1203	bool "kobject debugging"
1204	depends on DEBUG_KERNEL
1205	help
1206	If you say Y here, some extra kobject debugging messages will be sent
1207	to the syslog.
1208
1209	config DEBUG_KOBJECT_RELEASE
1210	bool "kobject release debugging"
1211	depends on DEBUG_OBJECTS_TIMERS
1212	help
1213	kobjects are reference counted objects. This means that their
1214	last reference count put is not predictable, and the kobject can
1215	live on past the point at which a driver decides to drop it's
1216	initial reference to the kobject gained on allocation. An
1217	example of this would be a struct device which has just been
1218	unregistered.
1219
1220	However, some buggy drivers assume that after such an operation,
1221	the memory backing the kobject can be immediately freed. This
1222	goes completely against the principles of a refcounted object.
1223
1224	If you say Y here, the kernel will delay the release of kobjects
1225	on the last reference count to improve the visibility of this
1226	kind of kobject release bug.
1227
1228	config HAVE_DEBUG_BUGVERBOSE
1229	bool
1230
1231	config DEBUG_BUGVERBOSE
1232	bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT
1233	depends on BUG && (GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE)
1234	default y
1235	help
1236	Say Y here to make BUG() panics output the file name and line number
1237	of the BUG call as well as the EIP and oops trace. This aids
1238	debugging but costs about 70-100K of memory.
1239
1240	config DEBUG_LIST
1241	bool "Debug linked list manipulation"
1242	depends on DEBUG_KERNEL
1243	help
1244	Enable this to turn on extended checks in the linked-list
1245	walking routines.
1246
1247	If unsure, say N.
1248
1249	config DEBUG_PI_LIST
1250	bool "Debug priority linked list manipulation"
1251	depends on DEBUG_KERNEL
1252	help
1253	Enable this to turn on extended checks in the priority-ordered
1254	linked-list (plist) walking routines. This checks the entire
1255	list multiple times during each manipulation.
1256
1257	If unsure, say N.
1258
1259	config DEBUG_SG
1260	bool "Debug SG table operations"
1261	depends on DEBUG_KERNEL
1262	help
1263	Enable this to turn on checks on scatter-gather tables. This can
1264	help find problems with drivers that do not properly initialize
1265	their sg tables.
1266
1267	If unsure, say N.
1268
1269	config DEBUG_NOTIFIERS
1270	bool "Debug notifier call chains"
1271	depends on DEBUG_KERNEL
1272	help
1273	Enable this to turn on sanity checking for notifier call chains.
1274	This is most useful for kernel developers to make sure that
1275	modules properly unregister themselves from notifier chains.
1276	This is a relatively cheap check but if you care about maximum
1277	performance, say N.
1278
1279	config DEBUG_CREDENTIALS
1280	bool "Debug credential management"
1281	depends on DEBUG_KERNEL
1282	help
1283	Enable this to turn on some debug checking for credential
1284	management. The additional code keeps track of the number of
1285	pointers from task_structs to any given cred struct, and checks to
1286	see that this number never exceeds the usage count of the cred
1287	struct.
1288
1289	Furthermore, if SELinux is enabled, this also checks that the
1290	security pointer in the cred struct is never seen to be invalid.
1291
1292	If unsure, say N.
1293
1294	menu "RCU Debugging"
1295
1296	config PROVE_RCU
1297	def_bool PROVE_LOCKING
1298
1299	config PROVE_RCU_REPEATEDLY
1300	bool "RCU debugging: don't disable PROVE_RCU on first splat"
1301	depends on PROVE_RCU
1302	default n
1303	help
1304	By itself, PROVE_RCU will disable checking upon issuing the
1305	first warning (or "splat"). This feature prevents such
1306	disabling, allowing multiple RCU-lockdep warnings to be printed
1307	on a single reboot.
1308
1309	Say Y to allow multiple RCU-lockdep warnings per boot.
1310
1311	Say N if you are unsure.
1312
1313	config SPARSE_RCU_POINTER
1314	bool "RCU debugging: sparse-based checks for pointer usage"
1315	default n
1316	help
1317	This feature enables the __rcu sparse annotation for
1318	RCU-protected pointers. This annotation will cause sparse
1319	to flag any non-RCU used of annotated pointers. This can be
1320	helpful when debugging RCU usage. Please note that this feature
1321	is not intended to enforce code cleanliness; it is instead merely
1322	a debugging aid.
1323
1324	Say Y to make sparse flag questionable use of RCU-protected pointers
1325
1326	Say N if you are unsure.
1327
1328	config TORTURE_TEST
1329	tristate
1330	default n
1331
1332	config RCU_PERF_TEST
1333	tristate "performance tests for RCU"
1334	depends on DEBUG_KERNEL
1335	select TORTURE_TEST
1336	select SRCU
1337	select TASKS_RCU
1338	default n
1339	help
1340	This option provides a kernel module that runs performance
1341	tests on the RCU infrastructure. The kernel module may be built
1342	after the fact on the running kernel to be tested, if desired.
1343
1344	Say Y here if you want RCU performance tests to be built into
1345	the kernel.
1346	Say M if you want the RCU performance tests to build as a module.
1347	Say N if you are unsure.
1348
1349	config RCU_TORTURE_TEST
1350	tristate "torture tests for RCU"
1351	depends on DEBUG_KERNEL
1352	select TORTURE_TEST
1353	select SRCU
1354	select TASKS_RCU
1355	default n
1356	help
1357	This option provides a kernel module that runs torture tests
1358	on the RCU infrastructure. The kernel module may be built
1359	after the fact on the running kernel to be tested, if desired.
1360
1361	Say Y here if you want RCU torture tests to be built into
1362	the kernel.
1363	Say M if you want the RCU torture tests to build as a module.
1364	Say N if you are unsure.
1365
1366	config RCU_TORTURE_TEST_SLOW_PREINIT
1367	bool "Slow down RCU grace-period pre-initialization to expose races"
1368	depends on RCU_TORTURE_TEST
1369	help
1370	This option delays grace-period pre-initialization (the
1371	propagation of CPU-hotplug changes up the rcu_node combining
1372	tree) for a few jiffies between initializing each pair of
1373	consecutive rcu_node structures. This helps to expose races
1374	involving grace-period pre-initialization, in other words, it
1375	makes your kernel less stable. It can also greatly increase
1376	grace-period latency, especially on systems with large numbers
1377	of CPUs. This is useful when torture-testing RCU, but in
1378	almost no other circumstance.
1379
1380	Say Y here if you want your system to crash and hang more often.
1381	Say N if you want a sane system.
1382
1383	config RCU_TORTURE_TEST_SLOW_PREINIT_DELAY
1384	int "How much to slow down RCU grace-period pre-initialization"
1385	range 0 5
1386	default 3
1387	depends on RCU_TORTURE_TEST_SLOW_PREINIT
1388	help
1389	This option specifies the number of jiffies to wait between
1390	each rcu_node structure pre-initialization step.
1391
1392	config RCU_TORTURE_TEST_SLOW_INIT
1393	bool "Slow down RCU grace-period initialization to expose races"
1394	depends on RCU_TORTURE_TEST
1395	help
1396	This option delays grace-period initialization for a few
1397	jiffies between initializing each pair of consecutive
1398	rcu_node structures. This helps to expose races involving
1399	grace-period initialization, in other words, it makes your
1400	kernel less stable. It can also greatly increase grace-period
1401	latency, especially on systems with large numbers of CPUs.
1402	This is useful when torture-testing RCU, but in almost no
1403	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
1408	config RCU_TORTURE_TEST_SLOW_INIT_DELAY
1409	int "How much to slow down RCU grace-period initialization"
1410	range 0 5
1411	default 3
1412	depends on RCU_TORTURE_TEST_SLOW_INIT
1413	help
1414	This option specifies the number of jiffies to wait between
1415	each rcu_node structure initialization.
1416
1417	config RCU_TORTURE_TEST_SLOW_CLEANUP
1418	bool "Slow down RCU grace-period cleanup to expose races"
1419	depends on RCU_TORTURE_TEST
1420	help
1421	This option delays grace-period cleanup for a few jiffies
1422	between cleaning up each pair of consecutive rcu_node
1423	structures. This helps to expose races involving grace-period
1424	cleanup, in other words, it makes your kernel less stable.
1425	It can also greatly increase grace-period latency, especially
1426	on systems with large numbers of CPUs. This is useful when
1427	torture-testing RCU, but in almost no other circumstance.
1428
1429	Say Y here if you want your system to crash and hang more often.
1430	Say N if you want a sane system.
1431
1432	config RCU_TORTURE_TEST_SLOW_CLEANUP_DELAY
1433	int "How much to slow down RCU grace-period cleanup"
1434	range 0 5
1435	default 3
1436	depends on RCU_TORTURE_TEST_SLOW_CLEANUP
1437	help
1438	This option specifies the number of jiffies to wait between
1439	each rcu_node structure cleanup operation.
1440
1441	config RCU_CPU_STALL_TIMEOUT
1442	int "RCU CPU stall timeout in seconds"
1443	depends on RCU_STALL_COMMON
1444	range 3 300
1445	default 21
1446	help
1447	If a given RCU grace period extends more than the specified
1448	number of seconds, a CPU stall warning is printed. If the
1449	RCU grace period persists, additional CPU stall warnings are
1450	printed at more widely spaced intervals.
1451
1452	config RCU_TRACE
1453	bool "Enable tracing for RCU"
1454	depends on DEBUG_KERNEL
1455	select TRACE_CLOCK
1456	help
1457	This option provides tracing in RCU which presents stats
1458	in debugfs for debugging RCU implementation.
1459
1460	Say Y here if you want to enable RCU tracing
1461	Say N if you are unsure.
1462
1463	config RCU_EQS_DEBUG
1464	bool "Provide debugging asserts for adding NO_HZ support to an arch"
1465	depends on DEBUG_KERNEL
1466	help
1467	This option provides consistency checks in RCU's handling of
1468	NO_HZ. These checks have proven quite helpful in detecting
1469	bugs in arch-specific NO_HZ code.
1470
1471	Say N here if you need ultimate kernel/user switch latencies
1472	Say Y if you are unsure
1473
1474	endmenu # "RCU Debugging"
1475
1476	config DEBUG_WQ_FORCE_RR_CPU
1477	bool "Force round-robin CPU selection for unbound work items"
1478	depends on DEBUG_KERNEL
1479	default n
1480	help
1481	Workqueue used to implicitly guarantee that work items queued
1482	without explicit CPU specified are put on the local CPU. This
1483	guarantee is no longer true and while local CPU is still
1484	preferred work items may be put on foreign CPUs. Kernel
1485	parameter "workqueue.debug_force_rr_cpu" is added to force
1486	round-robin CPU selection to flush out usages which depend on the
1487	now broken guarantee. This config option enables the debug
1488	feature by default. When enabled, memory and cache locality will
1489	be impacted.
1490
1491	config DEBUG_BLOCK_EXT_DEVT
1492	bool "Force extended block device numbers and spread them"
1493	depends on DEBUG_KERNEL
1494	depends on BLOCK
1495	default n
1496	help
1497	BIG FAT WARNING: ENABLING THIS OPTION MIGHT BREAK BOOTING ON
1498	SOME DISTRIBUTIONS. DO NOT ENABLE THIS UNLESS YOU KNOW WHAT
1499	YOU ARE DOING. Distros, please enable this and fix whatever
1500	is broken.
1501
1502	Conventionally, block device numbers are allocated from
1503	predetermined contiguous area. However, extended block area
1504	may introduce non-contiguous block device numbers. This
1505	option forces most block device numbers to be allocated from
1506	the extended space and spreads them to discover kernel or
1507	userland code paths which assume predetermined contiguous
1508	device number allocation.
1509
1510	Note that turning on this debug option shuffles all the
1511	device numbers for all IDE and SCSI devices including libata
1512	ones, so root partition specified using device number
1513	directly (via rdev or root=MAJ:MIN) won't work anymore.
1514	Textual device names (root=/dev/sdXn) will continue to work.
1515
1516	Say N if you are unsure.
1517
1518	config CPU_HOTPLUG_STATE_CONTROL
1519	bool "Enable CPU hotplug state control"
1520	depends on DEBUG_KERNEL
1521	depends on HOTPLUG_CPU
1522	default n
1523	help
1524	Allows to write steps between "offline" and "online" to the CPUs
1525	sysfs target file so states can be stepped granular. This is a debug
1526	option for now as the hotplug machinery cannot be stopped and
1527	restarted at arbitrary points yet.
1528
1529	Say N if your are unsure.
1530
1531	config NOTIFIER_ERROR_INJECTION
1532	tristate "Notifier error injection"
1533	depends on DEBUG_KERNEL
1534	select DEBUG_FS
1535	help
1536	This option provides the ability to inject artificial errors to
1537	specified notifier chain callbacks. It is useful to test the error
1538	handling of notifier call chain failures.
1539
1540	Say N if unsure.
1541
1542	config CPU_NOTIFIER_ERROR_INJECT
1543	tristate "CPU notifier error injection module"
1544	depends on HOTPLUG_CPU && NOTIFIER_ERROR_INJECTION
1545	help
1546	This option provides a kernel module that can be used to test
1547	the error handling of the cpu notifiers by injecting artificial
1548	errors to CPU notifier chain callbacks. It is controlled through
1549	debugfs interface under /sys/kernel/debug/notifier-error-inject/cpu
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 CPU offline error (-1 == -EPERM)
1555
1556	# cd /sys/kernel/debug/notifier-error-inject/cpu
1557	# echo -1 > actions/CPU_DOWN_PREPARE/error
1558	# echo 0 > /sys/devices/system/cpu/cpu1/online
1559	bash: echo: write error: Operation not permitted
1560
1561	To compile this code as a module, choose M here: the module will
1562	be called cpu-notifier-error-inject.
1563
1564	If unsure, say N.
1565
1566	config PM_NOTIFIER_ERROR_INJECT
1567	tristate "PM notifier error injection module"
1568	depends on PM && NOTIFIER_ERROR_INJECTION
1569	default m if PM_DEBUG
1570	help
1571	This option provides the ability to inject artificial errors to
1572	PM notifier chain callbacks. It is controlled through debugfs
1573	interface /sys/kernel/debug/notifier-error-inject/pm
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	Example: Inject PM suspend error (-12 = -ENOMEM)
1579
1580	# cd /sys/kernel/debug/notifier-error-inject/pm/
1581	# echo -12 > actions/PM_SUSPEND_PREPARE/error
1582	# echo mem > /sys/power/state
1583	bash: echo: write error: Cannot allocate memory
1584
1585	To compile this code as a module, choose M here: the module will
1586	be called pm-notifier-error-inject.
1587
1588	If unsure, say N.
1589
1590	config OF_RECONFIG_NOTIFIER_ERROR_INJECT
1591	tristate "OF reconfig notifier error injection module"
1592	depends on OF_DYNAMIC && NOTIFIER_ERROR_INJECTION
1593	help
1594	This option provides the ability to inject artificial errors to
1595	OF reconfig notifier chain callbacks. It is controlled
1596	through debugfs interface under
1597	/sys/kernel/debug/notifier-error-inject/OF-reconfig/
1598
1599	If the notifier call chain should be failed with some events
1600	notified, write the error code to "actions/<notifier event>/error".
1601
1602	To compile this code as a module, choose M here: the module will
1603	be called of-reconfig-notifier-error-inject.
1604
1605	If unsure, say N.
1606
1607	config NETDEV_NOTIFIER_ERROR_INJECT
1608	tristate "Netdev notifier error injection module"
1609	depends on NET && NOTIFIER_ERROR_INJECTION
1610	help
1611	This option provides the ability to inject artificial errors to
1612	netdevice notifier chain callbacks. It is controlled through debugfs
1613	interface /sys/kernel/debug/notifier-error-inject/netdev
1614
1615	If the notifier call chain should be failed with some events
1616	notified, write the error code to "actions/<notifier event>/error".
1617
1618	Example: Inject netdevice mtu change error (-22 = -EINVAL)
1619
1620	# cd /sys/kernel/debug/notifier-error-inject/netdev
1621	# echo -22 > actions/NETDEV_CHANGEMTU/error
1622	# ip link set eth0 mtu 1024
1623	RTNETLINK answers: Invalid argument
1624
1625	To compile this code as a module, choose M here: the module will
1626	be called netdev-notifier-error-inject.
1627
1628	If unsure, say N.
1629
1630	config FAULT_INJECTION
1631	bool "Fault-injection framework"
1632	depends on DEBUG_KERNEL
1633	help
1634	Provide fault-injection framework.
1635	For more details, see Documentation/fault-injection/.
1636
1637	config FAILSLAB
1638	bool "Fault-injection capability for kmalloc"
1639	depends on FAULT_INJECTION
1640	depends on SLAB || SLUB
1641	help
1642	Provide fault-injection capability for kmalloc.
1643
1644	config FAIL_PAGE_ALLOC
1645	bool "Fault-injection capabilitiy for alloc_pages()"
1646	depends on FAULT_INJECTION
1647	help
1648	Provide fault-injection capability for alloc_pages().
1649
1650	config FAIL_MAKE_REQUEST
1651	bool "Fault-injection capability for disk IO"
1652	depends on FAULT_INJECTION && BLOCK
1653	help
1654	Provide fault-injection capability for disk IO.
1655
1656	config FAIL_IO_TIMEOUT
1657	bool "Fault-injection capability for faking disk interrupts"
1658	depends on FAULT_INJECTION && BLOCK
1659	help
1660	Provide fault-injection capability on end IO handling. This
1661	will make the block layer "forget" an interrupt as configured,
1662	thus exercising the error handling.
1663
1664	Only works with drivers that use the generic timeout handling,
1665	for others it wont do anything.
1666
1667	config FAIL_MMC_REQUEST
1668	bool "Fault-injection capability for MMC IO"
1669	depends on FAULT_INJECTION_DEBUG_FS && MMC
1670	help
1671	Provide fault-injection capability for MMC IO.
1672	This will make the mmc core return data errors. This is
1673	useful to test the error handling in the mmc block device
1674	and to test how the mmc host driver handles retries from
1675	the block device.
1676
1677	config FAIL_FUTEX
1678	bool "Fault-injection capability for futexes"
1679	select DEBUG_FS
1680	depends on FAULT_INJECTION && FUTEX
1681	help
1682	Provide fault-injection capability for futexes.
1683
1684	config FAULT_INJECTION_DEBUG_FS
1685	bool "Debugfs entries for fault-injection capabilities"
1686	depends on FAULT_INJECTION && SYSFS && DEBUG_FS
1687	help
1688	Enable configuration of fault-injection capabilities via debugfs.
1689
1690	config FAULT_INJECTION_STACKTRACE_FILTER
1691	bool "stacktrace filter for fault-injection capabilities"
1692	depends on FAULT_INJECTION_DEBUG_FS && STACKTRACE_SUPPORT
1693	depends on !X86_64
1694	select STACKTRACE
1695	select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM_UNWIND && !ARC && !SCORE
1696	help
1697	Provide stacktrace filter for fault-injection capabilities
1698
1699	config LATENCYTOP
1700	bool "Latency measuring infrastructure"
1701	depends on DEBUG_KERNEL
1702	depends on STACKTRACE_SUPPORT
1703	depends on PROC_FS
1704	select FRAME_POINTER if !MIPS && !PPC && !S390 && !MICROBLAZE && !ARM_UNWIND && !ARC
1705	select KALLSYMS
1706	select KALLSYMS_ALL
1707	select STACKTRACE
1708	select SCHEDSTATS
1709	select SCHED_DEBUG
1710	help
1711	Enable this option if you want to use the LatencyTOP tool
1712	to find out which userspace is blocking on what kernel operations.
1713
1714	source kernel/trace/Kconfig
1715
1716	menu "Runtime Testing"
1717
1718	config LKDTM
1719	tristate "Linux Kernel Dump Test Tool Module"
1720	depends on DEBUG_FS
1721	depends on BLOCK
1722	default n
1723	help
1724	This module enables testing of the different dumping mechanisms by
1725	inducing system failures at predefined crash points.
1726	If you don't need it: say N
1727	Choose M here to compile this code as a module. The module will be
1728	called lkdtm.
1729
1730	Documentation on how to use the module can be found in
1731	Documentation/fault-injection/provoke-crashes.txt
1732
1733	config TEST_LIST_SORT
1734	bool "Linked list sorting test"
1735	depends on DEBUG_KERNEL
1736	help
1737	Enable this to turn on 'list_sort()' function test. This test is
1738	executed only once during system boot, so affects only boot time.
1739
1740	If unsure, say N.
1741
1742	config KPROBES_SANITY_TEST
1743	bool "Kprobes sanity tests"
1744	depends on DEBUG_KERNEL
1745	depends on KPROBES
1746	default n
1747	help
1748	This option provides for testing basic kprobes functionality on
1749	boot. A sample kprobe, jprobe and kretprobe are inserted and
1750	verified for functionality.
1751
1752	Say N if you are unsure.
1753
1754	config BACKTRACE_SELF_TEST
1755	tristate "Self test for the backtrace code"
1756	depends on DEBUG_KERNEL
1757	default n
1758	help
1759	This option provides a kernel module that can be used to test
1760	the kernel stack backtrace code. This option is not useful
1761	for distributions or general kernels, but only for kernel
1762	developers working on architecture code.
1763
1764	Note that if you want to also test saved backtraces, you will
1765	have to enable STACKTRACE as well.
1766
1767	Say N if you are unsure.
1768
1769	config RBTREE_TEST
1770	tristate "Red-Black tree test"
1771	depends on DEBUG_KERNEL
1772	help
1773	A benchmark measuring the performance of the rbtree library.
1774	Also includes rbtree invariant checks.
1775
1776	config INTERVAL_TREE_TEST
1777	tristate "Interval tree test"
1778	depends on m && DEBUG_KERNEL
1779	select INTERVAL_TREE
1780	help
1781	A benchmark measuring the performance of the interval tree library
1782
1783	config PERCPU_TEST
1784	tristate "Per cpu operations test"
1785	depends on m && DEBUG_KERNEL
1786	help
1787	Enable this option to build test module which validates per-cpu
1788	operations.
1789
1790	If unsure, say N.
1791
1792	config ATOMIC64_SELFTEST
1793	bool "Perform an atomic64_t self-test at boot"
1794	help
1795	Enable this option to test the atomic64_t functions at boot.
1796
1797	If unsure, say N.
1798
1799	config ASYNC_RAID6_TEST
1800	tristate "Self test for hardware accelerated raid6 recovery"
1801	depends on ASYNC_RAID6_RECOV
1802	select ASYNC_MEMCPY
1803	---help---
1804	This is a one-shot self test that permutes through the
1805	recovery of all the possible two disk failure scenarios for a
1806	N-disk array. Recovery is performed with the asynchronous
1807	raid6 recovery routines, and will optionally use an offload
1808	engine if one is available.
1809
1810	If unsure, say N.
1811
1812	config TEST_HEXDUMP
1813	tristate "Test functions located in the hexdump module at runtime"
1814
1815	config TEST_STRING_HELPERS
1816	tristate "Test functions located in the string_helpers module at runtime"
1817
1818	config TEST_KSTRTOX
1819	tristate "Test kstrto*() family of functions at runtime"
1820
1821	config TEST_PRINTF
1822	tristate "Test printf() family of functions at runtime"
1823
1824	config TEST_BITMAP
1825	tristate "Test bitmap_*() family of functions at runtime"
1826	default n
1827	help
1828	Enable this option to test the bitmap functions at boot.
1829
1830	If unsure, say N.
1831
1832	config TEST_UUID
1833	tristate "Test functions located in the uuid module at runtime"
1834
1835	config TEST_RHASHTABLE
1836	tristate "Perform selftest on resizable hash table"
1837	default n
1838	help
1839	Enable this option to test the rhashtable functions at boot.
1840
1841	If unsure, say N.
1842
1843	config TEST_HASH
1844	tristate "Perform selftest on hash functions"
1845	default n
1846	help
1847	Enable this option to test the kernel's integer (<linux/hash.h>),
1848	string (<linux/stringhash.h>), and siphash (<linux/siphash.h>)
1849	hash functions on boot (or module load).
1850
1851	This is intended to help people writing architecture-specific
1852	optimized versions. If unsure, say N.
1853
1854	endmenu # runtime tests
1855
1856	config PROVIDE_OHCI1394_DMA_INIT
1857	bool "Remote debugging over FireWire early on boot"
1858	depends on PCI && X86
1859	help
1860	If you want to debug problems which hang or crash the kernel early
1861	on boot and the crashing machine has a FireWire port, you can use
1862	this feature to remotely access the memory of the crashed machine
1863	over FireWire. This employs remote DMA as part of the OHCI1394
1864	specification which is now the standard for FireWire controllers.
1865
1866	With remote DMA, you can monitor the printk buffer remotely using
1867	firescope and access all memory below 4GB using fireproxy from gdb.
1868	Even controlling a kernel debugger is possible using remote DMA.
1869
1870	Usage:
1871
1872	If ohci1394_dma=early is used as boot parameter, it will initialize
1873	all OHCI1394 controllers which are found in the PCI config space.
1874
1875	As all changes to the FireWire bus such as enabling and disabling
1876	devices cause a bus reset and thereby disable remote DMA for all
1877	devices, be sure to have the cable plugged and FireWire enabled on
1878	the debugging host before booting the debug target for debugging.
1879
1880	This code (~1k) is freed after boot. By then, the firewire stack
1881	in charge of the OHCI-1394 controllers should be used instead.
1882
1883	See Documentation/debugging-via-ohci1394.txt for more information.
1884
1885	config DMA_API_DEBUG
1886	bool "Enable debugging of DMA-API usage"
1887	depends on HAVE_DMA_API_DEBUG
1888	help
1889	Enable this option to debug the use of the DMA API by device drivers.
1890	With this option you will be able to detect common bugs in device
1891	drivers like double-freeing of DMA mappings or freeing mappings that
1892	were never allocated.
1893
1894	This also attempts to catch cases where a page owned by DMA is
1895	accessed by the cpu in a way that could cause data corruption. For
1896	example, this enables cow_user_page() to check that the source page is
1897	not undergoing DMA.
1898
1899	This option causes a performance degradation. Use only if you want to
1900	debug device drivers and dma interactions.
1901
1902	If unsure, say N.
1903
1904	config TEST_LKM
1905	tristate "Test module loading with 'hello world' module"
1906	default n
1907	depends on m
1908	help
1909	This builds the "test_module" module that emits "Hello, world"
1910	on printk when loaded. It is designed to be used for basic
1911	evaluation of the module loading subsystem (for example when
1912	validating module verification). It lacks any extra dependencies,
1913	and will not normally be loaded by the system unless explicitly
1914	requested by name.
1915
1916	If unsure, say N.
1917
1918	config TEST_USER_COPY
1919	tristate "Test user/kernel boundary protections"
1920	default n
1921	depends on m
1922	help
1923	This builds the "test_user_copy" module that runs sanity checks
1924	on the copy_to/from_user infrastructure, making sure basic
1925	user/kernel boundary testing is working. If it fails to load,
1926	a regression has been detected in the user/kernel memory boundary
1927	protections.
1928
1929	If unsure, say N.
1930
1931	config TEST_BPF
1932	tristate "Test BPF filter functionality"
1933	default n
1934	depends on m && NET
1935	help
1936	This builds the "test_bpf" module that runs various test vectors
1937	against the BPF interpreter or BPF JIT compiler depending on the
1938	current setting. This is in particular useful for BPF JIT compiler
1939	development, but also to run regression tests against changes in
1940	the interpreter code. It also enables test stubs for eBPF maps and
1941	verifier used by user space verifier testsuite.
1942
1943	If unsure, say N.
1944
1945	config TEST_FIRMWARE
1946	tristate "Test firmware loading via userspace interface"
1947	default n
1948	depends on FW_LOADER
1949	help
1950	This builds the "test_firmware" module that creates a userspace
1951	interface for testing firmware loading. This can be used to
1952	control the triggering of firmware loading without needing an
1953	actual firmware-using device. The contents can be rechecked by
1954	userspace.
1955
1956	If unsure, say N.
1957
1958	config TEST_UDELAY
1959	tristate "udelay test driver"
1960	default n
1961	help
1962	This builds the "udelay_test" module that helps to make sure
1963	that udelay() is working properly.
1964
1965	If unsure, say N.
1966
1967	config MEMTEST
1968	bool "Memtest"
1969	depends on HAVE_MEMBLOCK
1970	---help---
1971	This option adds a kernel parameter 'memtest', which allows memtest
1972	to be set.
1973	memtest=0, mean disabled; -- default
1974	memtest=1, mean do 1 test pattern;
1975	...
1976	memtest=17, mean do 17 test patterns.
1977	If you are unsure how to answer this question, answer N.
1978
1979	config TEST_STATIC_KEYS
1980	tristate "Test static keys"
1981	default n
1982	depends on m
1983	help
1984	Test the static key interfaces.
1985
1986	If unsure, say N.
1987
1988	config BUG_ON_DATA_CORRUPTION
1989	bool "Trigger a BUG when data corruption is detected"
1990	select CONFIG_DEBUG_LIST
1991	help
1992	Select this option if the kernel should BUG when it encounters
1993	data corruption in kernel memory structures when they get checked
1994	for validity.
1995
1996	If unsure, say N.
1997
1998	source "samples/Kconfig"
1999
2000	source "lib/Kconfig.kgdb"
2001
2002	source "lib/Kconfig.ubsan"
2003
2004	config ARCH_HAS_DEVMEM_IS_ALLOWED
2005	bool
2006
2007	config STRICT_DEVMEM
2008	bool "Filter access to /dev/mem"
2009	depends on MMU
2010	depends on ARCH_HAS_DEVMEM_IS_ALLOWED
2011	default y if TILE || PPC
2012	---help---
2013	If this option is disabled, you allow userspace (root) access to all
2014	of memory, including kernel and userspace memory. Accidental
2015	access to this is obviously disastrous, but specific access can
2016	be used by people debugging the kernel. Note that with PAT support
2017	enabled, even in this case there are restrictions on /dev/mem
2018	use due to the cache aliasing requirements.
2019
2020	If this option is switched on, and IO_STRICT_DEVMEM=n, the /dev/mem
2021	file only allows userspace access to PCI space and the BIOS code and
2022	data regions. This is sufficient for dosemu and X and all common
2023	users of /dev/mem.
2024
2025	If in doubt, say Y.
2026
2027	config IO_STRICT_DEVMEM
2028	bool "Filter I/O access to /dev/mem"
2029	depends on STRICT_DEVMEM
2030	---help---
2031	If this option is disabled, you allow userspace (root) access to all
2032	io-memory regardless of whether a driver is actively using that
2033	range. Accidental access to this is obviously disastrous, but
2034	specific access can be used by people debugging kernel drivers.
2035
2036	If this option is switched on, the /dev/mem file only allows
2037	userspace access to *idle* io-memory ranges (see /proc/iomem) This
2038	may break traditional users of /dev/mem (dosemu, legacy X, etc...)
2039	if the driver using a given range cannot be disabled.
2040
2041	If in doubt, say Y.
2042