Linux kernel mirror (for testing)
git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel
os
linux
1# SPDX-License-Identifier: GPL-2.0-only
2menu "Kernel hacking"
3
4menu "printk and dmesg options"
5
6config PRINTK_TIME
7 bool "Show timing information on printks"
8 depends on PRINTK
9 help
10 Selecting this option causes time stamps of the printk()
11 messages to be added to the output of the syslog() system
12 call and at the console.
13
14 The timestamp is always recorded internally, and exported
15 to /dev/kmsg. This flag just specifies if the timestamp should
16 be included, not that the timestamp is recorded.
17
18 The behavior is also controlled by the kernel command line
19 parameter printk.time=1. See Documentation/admin-guide/kernel-parameters.rst
20
21config PRINTK_CALLER
22 bool "Show caller information on printks"
23 depends on PRINTK
24 help
25 Selecting this option causes printk() to add a caller "thread id" (if
26 in task context) or a caller "processor id" (if not in task context)
27 to every message.
28
29 This option is intended for environments where multiple threads
30 concurrently call printk() for many times, for it is difficult to
31 interpret without knowing where these lines (or sometimes individual
32 line which was divided into multiple lines due to race) came from.
33
34 Since toggling after boot makes the code racy, currently there is
35 no option to enable/disable at the kernel command line parameter or
36 sysfs interface.
37
38config PRINTK_EXECUTION_CTX
39 bool
40 depends on PRINTK
41 help
42 This option extends struct printk_info to include extra execution
43 context in printk, such as task name and CPU number from where the
44 message originated. This is useful for correlating printk messages
45 with specific execution contexts.
46
47 This is automatically enabled when a console driver that supports
48 execution context is selected.
49
50config STACKTRACE_BUILD_ID
51 bool "Show build ID information in stacktraces"
52 depends on PRINTK
53 help
54 Selecting this option adds build ID information for symbols in
55 stacktraces printed with the printk format '%p[SR]b'.
56
57 This option is intended for distros where debuginfo is not easily
58 accessible but can be downloaded given the build ID of the vmlinux or
59 kernel module where the function is located.
60
61config CONSOLE_LOGLEVEL_DEFAULT
62 int "Default console loglevel (1-15)"
63 range 1 15
64 default "7"
65 help
66 Default loglevel to determine what will be printed on the console.
67
68 Setting a default here is equivalent to passing in loglevel=<x> in
69 the kernel bootargs. loglevel=<x> continues to override whatever
70 value is specified here as well.
71
72 Note: This does not affect the log level of un-prefixed printk()
73 usage in the kernel. That is controlled by the MESSAGE_LOGLEVEL_DEFAULT
74 option.
75
76config CONSOLE_LOGLEVEL_QUIET
77 int "quiet console loglevel (1-15)"
78 range 1 15
79 default "4"
80 help
81 loglevel to use when "quiet" is passed on the kernel commandline.
82
83 When "quiet" is passed on the kernel commandline this loglevel
84 will be used as the loglevel. IOW passing "quiet" will be the
85 equivalent of passing "loglevel=<CONSOLE_LOGLEVEL_QUIET>"
86
87config MESSAGE_LOGLEVEL_DEFAULT
88 int "Default message log level (1-7)"
89 range 1 7
90 default "4"
91 help
92 Default log level for printk statements with no specified priority.
93
94 This was hard-coded to KERN_WARNING since at least 2.6.10 but folks
95 that are auditing their logs closely may want to set it to a lower
96 priority.
97
98 Note: This does not affect what message level gets printed on the console
99 by default. To change that, use loglevel=<x> in the kernel bootargs,
100 or pick a different CONSOLE_LOGLEVEL_DEFAULT configuration value.
101
102config BOOT_PRINTK_DELAY
103 bool "Delay each boot printk message by N milliseconds"
104 depends on DEBUG_KERNEL && PRINTK && GENERIC_CALIBRATE_DELAY
105 help
106 This build option allows you to read kernel boot messages
107 by inserting a short delay after each one. The delay is
108 specified in milliseconds on the kernel command line,
109 using "boot_delay=N".
110
111 It is likely that you would also need to use "lpj=M" to preset
112 the "loops per jiffy" value.
113 See a previous boot log for the "lpj" value to use for your
114 system, and then set "lpj=M" before setting "boot_delay=N".
115 NOTE: Using this option may adversely affect SMP systems.
116 I.e., processors other than the first one may not boot up.
117 BOOT_PRINTK_DELAY also may cause LOCKUP_DETECTOR to detect
118 what it believes to be lockup conditions.
119
120config DYNAMIC_DEBUG
121 bool "Enable dynamic printk() support"
122 default n
123 depends on PRINTK
124 depends on (DEBUG_FS || PROC_FS)
125 select DYNAMIC_DEBUG_CORE
126 help
127
128 Compiles debug level messages into the kernel, which would not
129 otherwise be available at runtime. These messages can then be
130 enabled/disabled based on various levels of scope - per source file,
131 function, module, format string, and line number. This mechanism
132 implicitly compiles in all pr_debug() and dev_dbg() calls, which
133 enlarges the kernel text size by about 2%.
134
135 If a source file is compiled with DEBUG flag set, any
136 pr_debug() calls in it are enabled by default, but can be
137 disabled at runtime as below. Note that DEBUG flag is
138 turned on by many CONFIG_*DEBUG* options.
139
140 Usage:
141
142 Dynamic debugging is controlled via the 'dynamic_debug/control' file,
143 which is contained in the 'debugfs' filesystem or procfs.
144 Thus, the debugfs or procfs filesystem must first be mounted before
145 making use of this feature.
146 We refer the control file as: <debugfs>/dynamic_debug/control. This
147 file contains a list of the debug statements that can be enabled. The
148 format for each line of the file is:
149
150 filename:lineno [module]function flags format
151
152 filename : source file of the debug statement
153 lineno : line number of the debug statement
154 module : module that contains the debug statement
155 function : function that contains the debug statement
156 flags : '=p' means the line is turned 'on' for printing
157 format : the format used for the debug statement
158
159 From a live system:
160
161 nullarbor:~ # cat <debugfs>/dynamic_debug/control
162 # filename:lineno [module]function flags format
163 fs/aio.c:222 [aio]__put_ioctx =_ "__put_ioctx:\040freeing\040%p\012"
164 fs/aio.c:248 [aio]ioctx_alloc =_ "ENOMEM:\040nr_events\040too\040high\012"
165 fs/aio.c:1770 [aio]sys_io_cancel =_ "calling\040cancel\012"
166
167 Example usage:
168
169 // enable the message at line 1603 of file svcsock.c
170 nullarbor:~ # echo -n 'file svcsock.c line 1603 +p' >
171 <debugfs>/dynamic_debug/control
172
173 // enable all the messages in file svcsock.c
174 nullarbor:~ # echo -n 'file svcsock.c +p' >
175 <debugfs>/dynamic_debug/control
176
177 // enable all the messages in the NFS server module
178 nullarbor:~ # echo -n 'module nfsd +p' >
179 <debugfs>/dynamic_debug/control
180
181 // enable all 12 messages in the function svc_process()
182 nullarbor:~ # echo -n 'func svc_process +p' >
183 <debugfs>/dynamic_debug/control
184
185 // disable all 12 messages in the function svc_process()
186 nullarbor:~ # echo -n 'func svc_process -p' >
187 <debugfs>/dynamic_debug/control
188
189 See Documentation/admin-guide/dynamic-debug-howto.rst for additional
190 information.
191
192config DYNAMIC_DEBUG_CORE
193 bool "Enable core function of dynamic debug support"
194 depends on PRINTK
195 depends on (DEBUG_FS || PROC_FS)
196 help
197 Enable core functional support of dynamic debug. It is useful
198 when you want to tie dynamic debug to your kernel modules with
199 DYNAMIC_DEBUG_MODULE defined for each of them, especially for
200 the case of embedded system where the kernel image size is
201 sensitive for people.
202
203config SYMBOLIC_ERRNAME
204 bool "Support symbolic error names in printf"
205 default y if PRINTK
206 help
207 If you say Y here, the kernel's printf implementation will
208 be able to print symbolic error names such as ENOSPC instead
209 of the number 28. It makes the kernel image slightly larger
210 (about 3KB), but can make the kernel logs easier to read.
211
212config DEBUG_BUGVERBOSE
213 bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EXPERT
214 depends on BUG && (GENERIC_BUG || HAVE_DEBUG_BUGVERBOSE)
215 default y
216 help
217 Say Y here to make BUG() panics output the file name and line number
218 of the BUG call as well as the EIP and oops trace. This aids
219 debugging but costs about 70-100K of memory.
220
221config DEBUG_BUGVERBOSE_DETAILED
222 bool "Verbose WARN_ON_ONCE() reporting (adds 100K)" if DEBUG_BUGVERBOSE
223 help
224 Say Y here to make WARN_ON_ONCE() output the condition string of the
225 warning, in addition to the file name and line number.
226 This helps debugging, but costs about 100K of memory.
227
228 Say N if unsure.
229
230
231endmenu # "printk and dmesg options"
232
233config DEBUG_KERNEL
234 bool "Kernel debugging"
235 help
236 Say Y here if you are developing drivers or trying to debug and
237 identify kernel problems.
238
239config DEBUG_MISC
240 bool "Miscellaneous debug code"
241 default DEBUG_KERNEL
242 depends on DEBUG_KERNEL
243 help
244 Say Y here if you need to enable miscellaneous debug code that should
245 be under a more specific debug option but isn't.
246
247menu "Compile-time checks and compiler options"
248
249config DEBUG_INFO
250 bool
251 help
252 A kernel debug info option other than "None" has been selected
253 in the "Debug information" choice below, indicating that debug
254 information will be generated for build targets.
255
256# Clang generates .uleb128 with label differences for DWARF v5, a feature that
257# older binutils ports do not support when utilizing RISC-V style linker
258# relaxation: https://sourceware.org/bugzilla/show_bug.cgi?id=27215
259config AS_HAS_NON_CONST_ULEB128
260 def_bool $(as-instr,.uleb128 .Lexpr_end4 - .Lexpr_start3\n.Lexpr_start3:\n.Lexpr_end4:)
261
262choice
263 prompt "Debug information"
264 depends on DEBUG_KERNEL
265 help
266 Selecting something other than "None" results in a kernel image
267 that will include debugging info resulting in a larger kernel image.
268 This adds debug symbols to the kernel and modules (gcc -g), and
269 is needed if you intend to use kernel crashdump or binary object
270 tools like crash, kgdb, LKCD, gdb, etc on the kernel.
271
272 Choose which version of DWARF debug info to emit. If unsure,
273 select "Toolchain default".
274
275config DEBUG_INFO_NONE
276 bool "Disable debug information"
277 help
278 Do not build the kernel with debugging information, which will
279 result in a faster and smaller build.
280
281config DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT
282 bool "Rely on the toolchain's implicit default DWARF version"
283 select DEBUG_INFO
284 depends on !CC_IS_CLANG || AS_IS_LLVM || (AS_IS_GNU && AS_VERSION >= 23502 && AS_HAS_NON_CONST_ULEB128)
285 help
286 The implicit default version of DWARF debug info produced by a
287 toolchain changes over time.
288
289 This can break consumers of the debug info that haven't upgraded to
290 support newer revisions, and prevent testing newer versions, but
291 those should be less common scenarios.
292
293config DEBUG_INFO_DWARF4
294 bool "Generate DWARF Version 4 debuginfo"
295 select DEBUG_INFO
296 depends on !CC_IS_CLANG || AS_IS_LLVM || (AS_IS_GNU && AS_VERSION >= 23502)
297 help
298 Generate DWARF v4 debug info. This requires gcc 4.5+, binutils 2.35.2
299 if using clang without clang's integrated assembler, and gdb 7.0+.
300
301 If you have consumers of DWARF debug info that are not ready for
302 newer revisions of DWARF, you may wish to choose this or have your
303 config select this.
304
305config DEBUG_INFO_DWARF5
306 bool "Generate DWARF Version 5 debuginfo"
307 select DEBUG_INFO
308 depends on !ARCH_HAS_BROKEN_DWARF5
309 depends on !CC_IS_CLANG || AS_IS_LLVM || (AS_IS_GNU && AS_VERSION >= 23502 && AS_HAS_NON_CONST_ULEB128)
310 help
311 Generate DWARF v5 debug info. Requires binutils 2.35.2, gcc 5.0+ (gcc
312 5.0+ accepts the -gdwarf-5 flag but only had partial support for some
313 draft features until 7.0), and gdb 8.0+.
314
315 Changes to the structure of debug info in Version 5 allow for around
316 15-18% savings in resulting image and debug info section sizes as
317 compared to DWARF Version 4. DWARF Version 5 standardizes previous
318 extensions such as accelerators for symbol indexing and the format
319 for fission (.dwo/.dwp) files. Users may not want to select this
320 config if they rely on tooling that has not yet been updated to
321 support DWARF Version 5.
322
323endchoice # "Debug information"
324
325if DEBUG_INFO
326
327config DEBUG_INFO_REDUCED
328 bool "Reduce debugging information"
329 help
330 If you say Y here gcc is instructed to generate less debugging
331 information for structure types. This means that tools that
332 need full debugging information (like kgdb or systemtap) won't
333 be happy. But if you merely need debugging information to
334 resolve line numbers there is no loss. Advantage is that
335 build directory object sizes shrink dramatically over a full
336 DEBUG_INFO build and compile times are reduced too.
337 Only works with newer gcc versions.
338
339choice
340 prompt "Compressed Debug information"
341 help
342 Compress the resulting debug info. Results in smaller debug info sections,
343 but requires that consumers are able to decompress the results.
344
345 If unsure, choose DEBUG_INFO_COMPRESSED_NONE.
346
347config DEBUG_INFO_COMPRESSED_NONE
348 bool "Don't compress debug information"
349 help
350 Don't compress debug info sections.
351
352config DEBUG_INFO_COMPRESSED_ZLIB
353 bool "Compress debugging information with zlib"
354 depends on $(cc-option,-gz=zlib)
355 depends on $(ld-option,--compress-debug-sections=zlib)
356 help
357 Compress the debug information using zlib.
358
359 Users of dpkg-deb via debian/rules may find an increase in
360 size of their debug .deb packages with this config set, due to the
361 debug info being compressed with zlib, then the object files being
362 recompressed with a different compression scheme. But this is still
363 preferable to setting KDEB_COMPRESS or DPKG_DEB_COMPRESSOR_TYPE to
364 "none" which would be even larger.
365
366config DEBUG_INFO_COMPRESSED_ZSTD
367 bool "Compress debugging information with zstd"
368 depends on $(cc-option,-gz=zstd)
369 depends on $(ld-option,--compress-debug-sections=zstd)
370 help
371 Compress the debug information using zstd. This may provide better
372 compression than zlib, for about the same time costs, but requires newer
373 toolchain support. Requires GCC 13.0+ or Clang 16.0+, binutils 2.40+, and
374 zstd.
375
376endchoice # "Compressed Debug information"
377
378config DEBUG_INFO_SPLIT
379 bool "Produce split debuginfo in .dwo files"
380 depends on $(cc-option,-gsplit-dwarf)
381 # RISC-V linker relaxation + -gsplit-dwarf has issues with LLVM and GCC
382 # prior to 12.x:
383 # https://github.com/llvm/llvm-project/issues/56642
384 # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99090
385 depends on !RISCV || GCC_VERSION >= 120000
386 help
387 Generate debug info into separate .dwo files. This significantly
388 reduces the build directory size for builds with DEBUG_INFO,
389 because it stores the information only once on disk in .dwo
390 files instead of multiple times in object files and executables.
391 In addition the debug information is also compressed.
392
393 Requires recent gcc (4.7+) and recent gdb/binutils.
394 Any tool that packages or reads debug information would need
395 to know about the .dwo files and include them.
396 Incompatible with older versions of ccache.
397
398config DEBUG_INFO_BTF
399 bool "Generate BTF type information"
400 depends on !DEBUG_INFO_SPLIT && !DEBUG_INFO_REDUCED
401 depends on !GCC_PLUGIN_RANDSTRUCT || COMPILE_TEST
402 depends on BPF_SYSCALL
403 depends on PAHOLE_VERSION >= 122
404 # pahole uses elfutils, which does not have support for Hexagon relocations
405 depends on !HEXAGON
406 help
407 Generate deduplicated BTF type information from DWARF debug info.
408 Turning this on requires pahole v1.22 or later, which will convert
409 DWARF type info into equivalent deduplicated BTF type info.
410
411config PAHOLE_HAS_BTF_TAG
412 def_bool PAHOLE_VERSION >= 123
413 depends on CC_IS_CLANG
414 help
415 Decide whether pahole emits btf_tag attributes (btf_type_tag and
416 btf_decl_tag) or not. Currently only clang compiler implements
417 these attributes, so make the config depend on CC_IS_CLANG.
418
419config PAHOLE_HAS_LANG_EXCLUDE
420 def_bool PAHOLE_VERSION >= 124
421 help
422 Support for the --lang_exclude flag which makes pahole exclude
423 compilation units from the supplied language. Used in Kbuild to
424 omit Rust CUs which are not supported in version 1.24 of pahole,
425 otherwise it would emit malformed kernel and module binaries when
426 using DEBUG_INFO_BTF_MODULES.
427
428config DEBUG_INFO_BTF_MODULES
429 bool "Generate BTF type information for kernel modules"
430 default y
431 depends on DEBUG_INFO_BTF && MODULES
432 help
433 Generate compact split BTF type information for kernel modules.
434
435config MODULE_ALLOW_BTF_MISMATCH
436 bool "Allow loading modules with non-matching BTF type info"
437 depends on DEBUG_INFO_BTF_MODULES
438 help
439 For modules whose split BTF does not match vmlinux, load without
440 BTF rather than refusing to load. The default behavior with
441 module BTF enabled is to reject modules with such mismatches;
442 this option will still load module BTF where possible but ignore
443 it when a mismatch is found.
444
445config GDB_SCRIPTS
446 bool "Provide GDB scripts for kernel debugging"
447 help
448 This creates the required links to GDB helper scripts in the
449 build directory. If you load vmlinux into gdb, the helper
450 scripts will be automatically imported by gdb as well, and
451 additional functions are available to analyze a Linux kernel
452 instance. See Documentation/process/debugging/gdb-kernel-debugging.rst
453 for further details.
454
455endif # DEBUG_INFO
456
457config FRAME_WARN
458 int "Warn for stack frames larger than"
459 range 0 8192
460 default 0 if KMSAN
461 default 2048 if GCC_PLUGIN_LATENT_ENTROPY
462 default 2048 if PARISC
463 default 1536 if (!64BIT && XTENSA)
464 default 1280 if !64BIT
465 default 2048 if 64BIT
466 help
467 Tell the compiler to warn at build time for stack frames larger than this.
468 Setting this too low will cause a lot of warnings.
469 Setting it to 0 disables the warning.
470
471config STRIP_ASM_SYMS
472 bool "Strip assembler-generated symbols during link"
473 default n
474 help
475 Strip internal assembler-generated symbols during a link (symbols
476 that look like '.Lxxx') so they don't pollute the output of
477 get_wchan() and suchlike.
478
479config READABLE_ASM
480 bool "Generate readable assembler code"
481 depends on DEBUG_KERNEL
482 depends on CC_IS_GCC
483 help
484 Disable some compiler optimizations that tend to generate human unreadable
485 assembler output. This may make the kernel slightly slower, but it helps
486 to keep kernel developers who have to stare a lot at assembler listings
487 sane.
488
489config HEADERS_INSTALL
490 bool "Install uapi headers to usr/include"
491 help
492 This option will install uapi headers (headers exported to user-space)
493 into the usr/include directory for use during the kernel build.
494 This is unneeded for building the kernel itself, but needed for some
495 user-space program samples. It is also needed by some features such
496 as uapi header sanity checks.
497
498config DEBUG_SECTION_MISMATCH
499 bool "Enable full Section mismatch analysis"
500 depends on CC_IS_GCC
501 help
502 The section mismatch analysis checks if there are illegal references
503 from one section to another. During linktime or runtime, some
504 sections are dropped; any use of code/data previously in these
505 sections would most likely result in an oops.
506
507 In the code, functions and variables are annotated with __init,
508 __initdata, and so on (see the full list in include/linux/init.h).
509 This directs the toolchain to place code/data in specific sections.
510
511 The section mismatch analysis is always performed after a full
512 kernel build, and enabling this option causes the option
513 -fno-inline-functions-called-once to be added to gcc commands.
514
515 However, when inlining a function annotated with __init in
516 a non-init function, we would lose the section information and thus
517 the analysis would not catch the illegal reference. This option
518 tells gcc to inline less (but it does result in a larger kernel).
519
520config SECTION_MISMATCH_WARN_ONLY
521 bool "Make section mismatch errors non-fatal"
522 default y
523 help
524 If you say N here, the build process will fail if there are any
525 section mismatch, instead of just throwing warnings.
526
527 If unsure, say Y.
528
529config DEBUG_FORCE_FUNCTION_ALIGN_64B
530 bool "Force all function address 64B aligned"
531 depends on EXPERT && (X86_64 || ARM64 || PPC32 || PPC64 || ARC || RISCV || S390)
532 select FUNCTION_ALIGNMENT_64B
533 help
534 There are cases that a commit from one domain changes the function
535 address alignment of other domains, and cause magic performance
536 bump (regression or improvement). Enable this option will help to
537 verify if the bump is caused by function alignment changes, while
538 it will slightly increase the kernel size and affect icache usage.
539
540 It is mainly for debug and performance tuning use.
541
542#
543# Select this config option from the architecture Kconfig, if it
544# is preferred to always offer frame pointers as a config
545# option on the architecture (regardless of KERNEL_DEBUG):
546#
547config ARCH_WANT_FRAME_POINTERS
548 bool
549
550config FRAME_POINTER
551 bool "Compile the kernel with frame pointers"
552 depends on DEBUG_KERNEL && (M68K || UML || SUPERH) || ARCH_WANT_FRAME_POINTERS
553 default y if (DEBUG_INFO && UML) || ARCH_WANT_FRAME_POINTERS
554 help
555 If you say Y here the resulting kernel image will be slightly
556 larger and slower, but it gives very useful debugging information
557 in case of kernel bugs. (precise oopses/stacktraces/warnings)
558
559config OBJTOOL
560 bool
561
562config OBJTOOL_WERROR
563 bool "Upgrade objtool warnings to errors"
564 depends on OBJTOOL && !COMPILE_TEST
565 help
566 Fail the build on objtool warnings.
567
568 Objtool warnings can indicate kernel instability, including boot
569 failures. This option is highly recommended.
570
571 If unsure, say Y.
572
573config STACK_VALIDATION
574 bool "Compile-time stack metadata validation"
575 depends on HAVE_STACK_VALIDATION && UNWINDER_FRAME_POINTER
576 select OBJTOOL
577 default n
578 help
579 Validate frame pointer rules at compile-time. This helps ensure that
580 runtime stack traces are more reliable.
581
582 For more information, see
583 tools/objtool/Documentation/objtool.txt.
584
585config NOINSTR_VALIDATION
586 bool
587 depends on HAVE_NOINSTR_VALIDATION && DEBUG_ENTRY
588 select OBJTOOL
589 default y
590
591config VMLINUX_MAP
592 bool "Generate vmlinux.map file when linking"
593 depends on EXPERT
594 help
595 Selecting this option will pass "-Map=vmlinux.map" to ld
596 when linking vmlinux. That file can be useful for verifying
597 and debugging magic section games, and for seeing which
598 pieces of code get eliminated with
599 CONFIG_LD_DEAD_CODE_DATA_ELIMINATION.
600
601config BUILTIN_MODULE_RANGES
602 bool "Generate address range information for builtin modules"
603 depends on !LTO
604 depends on VMLINUX_MAP
605 help
606 When modules are built into the kernel, there will be no module name
607 associated with its symbols in /proc/kallsyms. Tracers may want to
608 identify symbols by module name and symbol name regardless of whether
609 the module is configured as loadable or not.
610
611 This option generates modules.builtin.ranges in the build tree with
612 offset ranges (per ELF section) for the module(s) they belong to.
613 It also records an anchor symbol to determine the load address of the
614 section.
615
616config DEBUG_FORCE_WEAK_PER_CPU
617 bool "Force weak per-cpu definitions"
618 depends on DEBUG_KERNEL
619 help
620 s390 and alpha require percpu variables in modules to be
621 defined weak to work around addressing range issue which
622 puts the following two restrictions on percpu variable
623 definitions.
624
625 1. percpu symbols must be unique whether static or not
626 2. percpu variables can't be defined inside a function
627
628 To ensure that generic code follows the above rules, this
629 option forces all percpu variables to be defined as weak.
630
631config WARN_CONTEXT_ANALYSIS
632 bool "Compiler context-analysis warnings"
633 depends on CC_IS_CLANG && CLANG_VERSION >= 220100
634 # Branch profiling re-defines "if", which messes with the compiler's
635 # ability to analyze __cond_acquires(..), resulting in false positives.
636 depends on !TRACE_BRANCH_PROFILING
637 default y
638 help
639 Context Analysis is a language extension, which enables statically
640 checking that required contexts are active (or inactive) by acquiring
641 and releasing user-definable "context locks".
642
643 Clang's name of the feature is "Thread Safety Analysis". Requires
644 Clang 22.1.0 or later.
645
646 Produces warnings by default. Select CONFIG_WERROR if you wish to
647 turn these warnings into errors.
648
649 For more details, see Documentation/dev-tools/context-analysis.rst.
650
651config WARN_CONTEXT_ANALYSIS_ALL
652 bool "Enable context analysis for all source files"
653 depends on WARN_CONTEXT_ANALYSIS
654 depends on EXPERT && !COMPILE_TEST
655 help
656 Enable tree-wide context analysis. This is likely to produce a
657 large number of false positives - enable at your own risk.
658
659 If unsure, say N.
660
661endmenu # "Compiler options"
662
663menu "Generic Kernel Debugging Instruments"
664
665config MAGIC_SYSRQ
666 bool "Magic SysRq key"
667 depends on !UML
668 help
669 If you say Y here, you will have some control over the system even
670 if the system crashes for example during kernel debugging (e.g., you
671 will be able to flush the buffer cache to disk, reboot the system
672 immediately or dump some status information). This is accomplished
673 by pressing various keys while holding SysRq (Alt+PrintScreen). It
674 also works on a serial console (on PC hardware at least), if you
675 send a BREAK and then within 5 seconds a command keypress. The
676 keys are documented in <file:Documentation/admin-guide/sysrq.rst>.
677 Don't say Y unless you really know what this hack does.
678
679config MAGIC_SYSRQ_DEFAULT_ENABLE
680 hex "Enable magic SysRq key functions by default"
681 depends on MAGIC_SYSRQ
682 default 0x1
683 help
684 Specifies which SysRq key functions are enabled by default.
685 This may be set to 1 or 0 to enable or disable them all, or
686 to a bitmask as described in Documentation/admin-guide/sysrq.rst.
687
688config MAGIC_SYSRQ_SERIAL
689 bool "Enable magic SysRq key over serial"
690 depends on MAGIC_SYSRQ
691 default y
692 help
693 Many embedded boards have a disconnected TTL level serial which can
694 generate some garbage that can lead to spurious false sysrq detects.
695 This option allows you to decide whether you want to enable the
696 magic SysRq key.
697
698config MAGIC_SYSRQ_SERIAL_SEQUENCE
699 string "Char sequence that enables magic SysRq over serial"
700 depends on MAGIC_SYSRQ_SERIAL
701 default ""
702 help
703 Specifies a sequence of characters that can follow BREAK to enable
704 SysRq on a serial console.
705
706 If unsure, leave an empty string and the option will not be enabled.
707
708config DEBUG_FS
709 bool "Debug Filesystem"
710 help
711 debugfs is a virtual file system that kernel developers use to put
712 debugging files into. Enable this option to be able to read and
713 write to these files.
714
715 For detailed documentation on the debugfs API, see
716 Documentation/filesystems/.
717
718 If unsure, say N.
719
720choice
721 prompt "Debugfs default access"
722 depends on DEBUG_FS
723 default DEBUG_FS_ALLOW_ALL
724 help
725 This selects the default access restrictions for debugfs.
726 It can be overridden with kernel command line option
727 debugfs=[on,off]. The restrictions apply for API access
728 and filesystem registration.
729
730config DEBUG_FS_ALLOW_ALL
731 bool "Access normal"
732 help
733 No restrictions apply. Both API and filesystem registration
734 is on. This is the normal default operation.
735
736config DEBUG_FS_ALLOW_NONE
737 bool "No access"
738 help
739 Access is off. Clients get -PERM when trying to create nodes in
740 debugfs tree and debugfs is not registered as a filesystem.
741 Client can then back-off or continue without debugfs access.
742
743endchoice
744
745source "lib/Kconfig.kgdb"
746source "lib/Kconfig.ubsan"
747source "lib/Kconfig.kcsan"
748
749endmenu
750
751menu "Networking Debugging"
752
753source "net/Kconfig.debug"
754
755endmenu # "Networking Debugging"
756
757menu "Memory Debugging"
758
759source "mm/Kconfig.debug"
760
761config DEBUG_OBJECTS
762 bool "Debug object operations"
763 depends on PREEMPT_COUNT || !DEFERRED_STRUCT_PAGE_INIT
764 depends on DEBUG_KERNEL
765 help
766 If you say Y here, additional code will be inserted into the
767 kernel to track the life time of various objects and validate
768 the operations on those objects.
769
770config DEBUG_OBJECTS_SELFTEST
771 bool "Debug objects selftest"
772 depends on DEBUG_OBJECTS
773 help
774 This enables the selftest of the object debug code.
775
776config DEBUG_OBJECTS_FREE
777 bool "Debug objects in freed memory"
778 depends on DEBUG_OBJECTS
779 help
780 This enables checks whether a k/v free operation frees an area
781 which contains an object which has not been deactivated
782 properly. This can make kmalloc/kfree-intensive workloads
783 much slower.
784
785config DEBUG_OBJECTS_TIMERS
786 bool "Debug timer objects"
787 depends on DEBUG_OBJECTS
788 help
789 If you say Y here, additional code will be inserted into the
790 timer routines to track the life time of timer objects and
791 validate the timer operations.
792
793config DEBUG_OBJECTS_WORK
794 bool "Debug work objects"
795 depends on DEBUG_OBJECTS
796 help
797 If you say Y here, additional code will be inserted into the
798 work queue routines to track the life time of work objects and
799 validate the work operations.
800
801config DEBUG_OBJECTS_RCU_HEAD
802 bool "Debug RCU callbacks objects"
803 depends on DEBUG_OBJECTS
804 help
805 Enable this to turn on debugging of RCU list heads (call_rcu() usage).
806
807config DEBUG_OBJECTS_PERCPU_COUNTER
808 bool "Debug percpu counter objects"
809 depends on DEBUG_OBJECTS
810 help
811 If you say Y here, additional code will be inserted into the
812 percpu counter routines to track the life time of percpu counter
813 objects and validate the percpu counter operations.
814
815config DEBUG_OBJECTS_ENABLE_DEFAULT
816 int "debug_objects bootup default value (0-1)"
817 range 0 1
818 default "1"
819 depends on DEBUG_OBJECTS
820 help
821 Debug objects boot parameter default value
822
823config SHRINKER_DEBUG
824 bool "Enable shrinker debugging support"
825 depends on DEBUG_FS
826 help
827 Say Y to enable the shrinker debugfs interface which provides
828 visibility into the kernel memory shrinkers subsystem.
829 Disable it to avoid an extra memory footprint.
830
831config DEBUG_STACK_USAGE
832 bool "Stack utilization instrumentation"
833 depends on DEBUG_KERNEL
834 help
835 Enables the display of the minimum amount of free stack which each
836 task has ever had available in the sysrq-T and sysrq-P debug output.
837 Also emits a message to dmesg when a process exits if that process
838 used more stack space than previously exiting processes.
839
840 This option will slow down process creation somewhat.
841
842config SCHED_STACK_END_CHECK
843 bool "Detect stack corruption on calls to schedule()"
844 depends on DEBUG_KERNEL
845 default n
846 help
847 This option checks for a stack overrun on calls to schedule().
848 If the stack end location is found to be over written always panic as
849 the content of the corrupted region can no longer be trusted.
850 This is to ensure no erroneous behaviour occurs which could result in
851 data corruption or a sporadic crash at a later stage once the region
852 is examined. The runtime overhead introduced is minimal.
853
854config ARCH_HAS_DEBUG_VM_PGTABLE
855 bool
856 help
857 An architecture should select this when it can successfully
858 build and run DEBUG_VM_PGTABLE.
859
860config DEBUG_VFS
861 bool "Debug VFS"
862 depends on DEBUG_KERNEL
863 help
864 Enable this to turn on extended checks in the VFS layer that may impact
865 performance.
866
867 If unsure, say N.
868
869config DEBUG_VM_IRQSOFF
870 def_bool DEBUG_VM && !PREEMPT_RT
871
872config DEBUG_VM
873 bool "Debug VM"
874 depends on DEBUG_KERNEL
875 help
876 Enable this to turn on extended checks in the virtual-memory system
877 that may impact performance.
878
879 If unsure, say N.
880
881config DEBUG_VM_SHOOT_LAZIES
882 bool "Debug MMU_LAZY_TLB_SHOOTDOWN implementation"
883 depends on DEBUG_VM
884 depends on MMU_LAZY_TLB_SHOOTDOWN
885 help
886 Enable additional IPIs that ensure lazy tlb mm references are removed
887 before the mm is freed.
888
889 If unsure, say N.
890
891config DEBUG_VM_MAPLE_TREE
892 bool "Debug VM maple trees"
893 depends on DEBUG_VM
894 select DEBUG_MAPLE_TREE
895 help
896 Enable VM maple tree debugging information and extra validations.
897
898 If unsure, say N.
899
900config DEBUG_VM_RB
901 bool "Debug VM red-black trees"
902 depends on DEBUG_VM
903 help
904 Enable VM red-black tree debugging information and extra validations.
905
906 If unsure, say N.
907
908config DEBUG_VM_PGFLAGS
909 bool "Debug page-flags operations"
910 depends on DEBUG_VM
911 help
912 Enables extra validation on page flags operations.
913
914 If unsure, say N.
915
916config DEBUG_VM_PGTABLE
917 bool "Debug arch page table for semantics compliance"
918 depends on MMU
919 depends on ARCH_HAS_DEBUG_VM_PGTABLE
920 default y if DEBUG_VM
921 help
922 This option provides a debug method which can be used to test
923 architecture page table helper functions on various platforms in
924 verifying if they comply with expected generic MM semantics. This
925 will help architecture code in making sure that any changes or
926 new additions of these helpers still conform to expected
927 semantics of the generic MM. Platforms will have to opt in for
928 this through ARCH_HAS_DEBUG_VM_PGTABLE.
929
930 If unsure, say N.
931
932config ARCH_HAS_DEBUG_VIRTUAL
933 bool
934
935config DEBUG_VIRTUAL
936 bool "Debug VM translations"
937 depends on DEBUG_KERNEL && ARCH_HAS_DEBUG_VIRTUAL
938 help
939 Enable some costly sanity checks in virtual to page code. This can
940 catch mistakes with virt_to_page() and friends.
941
942 If unsure, say N.
943
944config DEBUG_NOMMU_REGIONS
945 bool "Debug the global anon/private NOMMU mapping region tree"
946 depends on DEBUG_KERNEL && !MMU
947 help
948 This option causes the global tree of anonymous and private mapping
949 regions to be regularly checked for invalid topology.
950
951config DEBUG_MEMORY_INIT
952 bool "Debug memory initialisation" if EXPERT
953 default !EXPERT
954 help
955 Enable this for additional checks during memory initialisation.
956 The sanity checks verify aspects of the VM such as the memory model
957 and other information provided by the architecture. Verbose
958 information will be printed at KERN_DEBUG loglevel depending
959 on the mminit_loglevel= command-line option.
960
961 If unsure, say Y
962
963config MEMORY_NOTIFIER_ERROR_INJECT
964 tristate "Memory hotplug notifier error injection module"
965 depends on MEMORY_HOTPLUG && NOTIFIER_ERROR_INJECTION
966 help
967 This option provides the ability to inject artificial errors to
968 memory hotplug notifier chain callbacks. It is controlled through
969 debugfs interface under /sys/kernel/debug/notifier-error-inject/memory
970
971 If the notifier call chain should be failed with some events
972 notified, write the error code to "actions/<notifier event>/error".
973
974 Example: Inject memory hotplug offline error (-12 == -ENOMEM)
975
976 # cd /sys/kernel/debug/notifier-error-inject/memory
977 # echo -12 > actions/MEM_GOING_OFFLINE/error
978 # echo offline > /sys/devices/system/memory/memoryXXX/state
979 bash: echo: write error: Cannot allocate memory
980
981 To compile this code as a module, choose M here: the module will
982 be called memory-notifier-error-inject.
983
984 If unsure, say N.
985
986config DEBUG_PER_CPU_MAPS
987 bool "Debug access to per_cpu maps"
988 depends on DEBUG_KERNEL
989 depends on SMP
990 help
991 Say Y to verify that the per_cpu map being accessed has
992 been set up. This adds a fair amount of code to kernel memory
993 and decreases performance.
994
995 Say N if unsure.
996
997config DEBUG_KMAP_LOCAL
998 bool "Debug kmap_local temporary mappings"
999 depends on DEBUG_KERNEL && KMAP_LOCAL
1000 help
1001 This option enables additional error checking for the kmap_local
1002 infrastructure. Disable for production use.
1003
1004config ARCH_SUPPORTS_KMAP_LOCAL_FORCE_MAP
1005 bool
1006
1007config DEBUG_KMAP_LOCAL_FORCE_MAP
1008 bool "Enforce kmap_local temporary mappings"
1009 depends on DEBUG_KERNEL && ARCH_SUPPORTS_KMAP_LOCAL_FORCE_MAP
1010 select KMAP_LOCAL
1011 select DEBUG_KMAP_LOCAL
1012 help
1013 This option enforces temporary mappings through the kmap_local
1014 mechanism for non-highmem pages and on non-highmem systems.
1015 Disable this for production systems!
1016
1017config DEBUG_HIGHMEM
1018 bool "Highmem debugging"
1019 depends on DEBUG_KERNEL && HIGHMEM
1020 select DEBUG_KMAP_LOCAL_FORCE_MAP if ARCH_SUPPORTS_KMAP_LOCAL_FORCE_MAP
1021 select DEBUG_KMAP_LOCAL
1022 help
1023 This option enables additional error checking for high memory
1024 systems. Disable for production systems.
1025
1026config HAVE_DEBUG_STACKOVERFLOW
1027 bool
1028
1029config DEBUG_STACKOVERFLOW
1030 bool "Check for stack overflows"
1031 depends on DEBUG_KERNEL && HAVE_DEBUG_STACKOVERFLOW
1032 help
1033 Say Y here if you want to check for overflows of kernel, IRQ
1034 and exception stacks (if your architecture uses them). This
1035 option will show detailed messages if free stack space drops
1036 below a certain limit.
1037
1038 These kinds of bugs usually occur when call-chains in the
1039 kernel get too deep, especially when interrupts are
1040 involved.
1041
1042 Use this in cases where you see apparently random memory
1043 corruption, especially if it appears in 'struct thread_info'
1044
1045 If in doubt, say "N".
1046
1047config CODE_TAGGING
1048 bool
1049 select KALLSYMS
1050
1051config MEM_ALLOC_PROFILING
1052 bool "Enable memory allocation profiling"
1053 default n
1054 depends on MMU
1055 depends on PROC_FS
1056 depends on !DEBUG_FORCE_WEAK_PER_CPU
1057 select CODE_TAGGING
1058 select PAGE_EXTENSION
1059 select SLAB_OBJ_EXT
1060 help
1061 Track allocation source code and record total allocation size
1062 initiated at that code location. The mechanism can be used to track
1063 memory leaks with a low performance and memory impact.
1064
1065config MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT
1066 bool "Enable memory allocation profiling by default"
1067 default y
1068 depends on MEM_ALLOC_PROFILING
1069
1070config MEM_ALLOC_PROFILING_DEBUG
1071 bool "Memory allocation profiler debugging"
1072 default n
1073 depends on MEM_ALLOC_PROFILING
1074 select MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT
1075 help
1076 Adds warnings with helpful error messages for memory allocation
1077 profiling.
1078
1079source "lib/Kconfig.kasan"
1080source "lib/Kconfig.kfence"
1081source "lib/Kconfig.kmsan"
1082
1083endmenu # "Memory Debugging"
1084
1085config DEBUG_SHIRQ
1086 bool "Debug shared IRQ handlers"
1087 depends on DEBUG_KERNEL
1088 help
1089 Enable this to generate a spurious interrupt just before a shared
1090 interrupt handler is deregistered (generating one when registering
1091 is currently disabled). Drivers need to handle this correctly. Some
1092 don't and need to be caught.
1093
1094menu "Debug Oops, Lockups and Hangs"
1095
1096config PANIC_ON_OOPS
1097 bool "Panic on Oops"
1098 help
1099 Say Y here to enable the kernel to panic when it oopses. This
1100 has the same effect as setting oops=panic on the kernel command
1101 line.
1102
1103 This feature is useful to ensure that the kernel does not do
1104 anything erroneous after an oops which could result in data
1105 corruption or other issues.
1106
1107 Say N if unsure.
1108
1109config PANIC_TIMEOUT
1110 int "panic timeout"
1111 default 0
1112 help
1113 Set the timeout value (in seconds) until a reboot occurs when
1114 the kernel panics. If n = 0, then we wait forever. A timeout
1115 value n > 0 will wait n seconds before rebooting, while a timeout
1116 value n < 0 will reboot immediately. This setting can be overridden
1117 with the kernel command line option panic=, and from userspace via
1118 /proc/sys/kernel/panic.
1119
1120config LOCKUP_DETECTOR
1121 bool
1122
1123config SOFTLOCKUP_DETECTOR
1124 bool "Detect Soft Lockups"
1125 depends on DEBUG_KERNEL && !S390
1126 select LOCKUP_DETECTOR
1127 help
1128 Say Y here to enable the kernel to act as a watchdog to detect
1129 soft lockups.
1130
1131 Softlockups are bugs that cause the kernel to loop in kernel
1132 mode for more than 20 seconds, without giving other tasks a
1133 chance to run. The current stack trace is displayed upon
1134 detection and the system will stay locked up.
1135
1136config SOFTLOCKUP_DETECTOR_INTR_STORM
1137 bool "Detect Interrupt Storm in Soft Lockups"
1138 depends on SOFTLOCKUP_DETECTOR && IRQ_TIME_ACCOUNTING
1139 select GENERIC_IRQ_STAT_SNAPSHOT
1140 default y if NR_CPUS <= 128
1141 help
1142 Say Y here to enable the kernel to detect interrupt storm
1143 during "soft lockups".
1144
1145 "soft lockups" can be caused by a variety of reasons. If one is
1146 caused by an interrupt storm, then the storming interrupts will not
1147 be on the callstack. To detect this case, it is necessary to report
1148 the CPU stats and the interrupt counts during the "soft lockups".
1149
1150config BOOTPARAM_SOFTLOCKUP_PANIC
1151 int "Panic (Reboot) On Soft Lockups"
1152 depends on SOFTLOCKUP_DETECTOR
1153 default 0
1154 help
1155 Set to a non-zero value N to enable the kernel to panic on "soft
1156 lockups", which are bugs that cause the kernel to loop in kernel
1157 mode for more than (N * 20 seconds) (configurable using the
1158 watchdog_thresh sysctl), without giving other tasks a chance to run.
1159
1160 The panic can be used in combination with panic_timeout,
1161 to cause the system to reboot automatically after a
1162 lockup has been detected. This feature is useful for
1163 high-availability systems that have uptime guarantees and
1164 where a lockup must be resolved ASAP.
1165
1166 Say 0 if unsure.
1167
1168config HAVE_HARDLOCKUP_DETECTOR_BUDDY
1169 bool
1170 depends on SMP
1171 default y
1172
1173#
1174# Global switch whether to build a hardlockup detector at all. It is available
1175# only when the architecture supports at least one implementation. There are
1176# two exceptions. The hardlockup detector is never enabled on:
1177#
1178# s390: it reported many false positives there
1179#
1180# sparc64: has a custom implementation which is not using the common
1181# hardlockup command line options and sysctl interface.
1182#
1183config HARDLOCKUP_DETECTOR
1184 bool "Detect Hard Lockups"
1185 depends on DEBUG_KERNEL && !S390 && !HARDLOCKUP_DETECTOR_SPARC64
1186 depends on HAVE_HARDLOCKUP_DETECTOR_PERF || HAVE_HARDLOCKUP_DETECTOR_BUDDY || HAVE_HARDLOCKUP_DETECTOR_ARCH
1187 imply HARDLOCKUP_DETECTOR_PERF
1188 imply HARDLOCKUP_DETECTOR_BUDDY
1189 imply HARDLOCKUP_DETECTOR_ARCH
1190 select LOCKUP_DETECTOR
1191
1192 help
1193 Say Y here to enable the kernel to act as a watchdog to detect
1194 hard lockups.
1195
1196 Hardlockups are bugs that cause the CPU to loop in kernel mode
1197 for more than 10 seconds, without letting other interrupts have a
1198 chance to run. The current stack trace is displayed upon detection
1199 and the system will stay locked up.
1200
1201#
1202# Note that arch-specific variants are always preferred.
1203#
1204config HARDLOCKUP_DETECTOR_PREFER_BUDDY
1205 bool "Prefer the buddy CPU hardlockup detector"
1206 depends on HARDLOCKUP_DETECTOR
1207 depends on HAVE_HARDLOCKUP_DETECTOR_PERF && HAVE_HARDLOCKUP_DETECTOR_BUDDY
1208 depends on !HAVE_HARDLOCKUP_DETECTOR_ARCH
1209 help
1210 Say Y here to prefer the buddy hardlockup detector over the perf one.
1211
1212 With the buddy detector, each CPU uses its softlockup hrtimer
1213 to check that the next CPU is processing hrtimer interrupts by
1214 verifying that a counter is increasing.
1215
1216 This hardlockup detector is useful on systems that don't have
1217 an arch-specific hardlockup detector or if resources needed
1218 for the hardlockup detector are better used for other things.
1219
1220config HARDLOCKUP_DETECTOR_PERF
1221 bool
1222 depends on HARDLOCKUP_DETECTOR
1223 depends on HAVE_HARDLOCKUP_DETECTOR_PERF && !HARDLOCKUP_DETECTOR_PREFER_BUDDY
1224 depends on !HAVE_HARDLOCKUP_DETECTOR_ARCH
1225 select HARDLOCKUP_DETECTOR_COUNTS_HRTIMER
1226
1227config HARDLOCKUP_DETECTOR_BUDDY
1228 bool
1229 depends on HARDLOCKUP_DETECTOR
1230 depends on HAVE_HARDLOCKUP_DETECTOR_BUDDY
1231 depends on !HAVE_HARDLOCKUP_DETECTOR_PERF || HARDLOCKUP_DETECTOR_PREFER_BUDDY
1232 depends on !HAVE_HARDLOCKUP_DETECTOR_ARCH
1233 select HARDLOCKUP_DETECTOR_COUNTS_HRTIMER
1234
1235config HARDLOCKUP_DETECTOR_ARCH
1236 bool
1237 depends on HARDLOCKUP_DETECTOR
1238 depends on HAVE_HARDLOCKUP_DETECTOR_ARCH
1239 help
1240 The arch-specific implementation of the hardlockup detector will
1241 be used.
1242
1243#
1244# Both the "perf" and "buddy" hardlockup detectors count hrtimer
1245# interrupts. This config enables functions managing this common code.
1246#
1247config HARDLOCKUP_DETECTOR_COUNTS_HRTIMER
1248 bool
1249 select SOFTLOCKUP_DETECTOR
1250
1251#
1252# Enables a timestamp based low pass filter to compensate for perf based
1253# hard lockup detection which runs too fast due to turbo modes.
1254#
1255config HARDLOCKUP_CHECK_TIMESTAMP
1256 bool
1257
1258config BOOTPARAM_HARDLOCKUP_PANIC
1259 bool "Panic (Reboot) On Hard Lockups"
1260 depends on HARDLOCKUP_DETECTOR
1261 help
1262 Say Y here to enable the kernel to panic on "hard lockups",
1263 which are bugs that cause the kernel to loop in kernel
1264 mode with interrupts disabled for more than 10 seconds (configurable
1265 using the watchdog_thresh sysctl).
1266
1267 Say N if unsure.
1268
1269config DETECT_HUNG_TASK
1270 bool "Detect Hung Tasks"
1271 depends on DEBUG_KERNEL
1272 default SOFTLOCKUP_DETECTOR
1273 help
1274 Say Y here to enable the kernel to detect "hung tasks",
1275 which are bugs that cause the task to be stuck in
1276 uninterruptible "D" state indefinitely.
1277
1278 When a hung task is detected, the kernel will print the
1279 current stack trace (which you should report), but the
1280 task will stay in uninterruptible state. If lockdep is
1281 enabled then all held locks will also be reported. This
1282 feature has negligible overhead.
1283
1284config DEFAULT_HUNG_TASK_TIMEOUT
1285 int "Default timeout for hung task detection (in seconds)"
1286 depends on DETECT_HUNG_TASK
1287 default 120
1288 help
1289 This option controls the default timeout (in seconds) used
1290 to determine when a task has become non-responsive and should
1291 be considered hung.
1292
1293 It can be adjusted at runtime via the kernel.hung_task_timeout_secs
1294 sysctl or by writing a value to
1295 /proc/sys/kernel/hung_task_timeout_secs.
1296
1297 A timeout of 0 disables the check. The default is two minutes.
1298 Keeping the default should be fine in most cases.
1299
1300config BOOTPARAM_HUNG_TASK_PANIC
1301 int "Number of hung tasks to trigger kernel panic"
1302 depends on DETECT_HUNG_TASK
1303 default 0
1304 help
1305 When set to a non-zero value, a kernel panic will be triggered
1306 if the number of hung tasks found during a single scan reaches
1307 this value.
1308
1309 The panic can be used in combination with panic_timeout,
1310 to cause the system to reboot automatically after a
1311 hung task has been detected. This feature is useful for
1312 high-availability systems that have uptime guarantees and
1313 where a hung tasks must be resolved ASAP.
1314
1315 Say 0 if unsure.
1316
1317config DETECT_HUNG_TASK_BLOCKER
1318 bool "Dump Hung Tasks Blocker"
1319 depends on DETECT_HUNG_TASK
1320 depends on !PREEMPT_RT
1321 default y
1322 help
1323 Say Y here to show the blocker task's stacktrace who acquires
1324 the mutex lock which "hung tasks" are waiting.
1325 This will add overhead a bit but shows suspicious tasks and
1326 call trace if it comes from waiting a mutex.
1327
1328config WQ_WATCHDOG
1329 bool "Detect Workqueue Stalls"
1330 depends on DEBUG_KERNEL
1331 help
1332 Say Y here to enable stall detection on workqueues. If a
1333 worker pool doesn't make forward progress on a pending work
1334 item for over a given amount of time, 30s by default, a
1335 warning message is printed along with dump of workqueue
1336 state. This can be configured through kernel parameter
1337 "workqueue.watchdog_thresh" and its sysfs counterpart.
1338
1339config BOOTPARAM_WQ_STALL_PANIC
1340 int "Panic on Nth workqueue stall"
1341 default 0
1342 range 0 100
1343 depends on WQ_WATCHDOG
1344 help
1345 Set the number of workqueue stalls to trigger a kernel panic.
1346 A workqueue stall occurs when a worker pool doesn't make forward
1347 progress on a pending work item for over 30 seconds (configurable
1348 using the workqueue.watchdog_thresh parameter).
1349
1350 If n = 0, the kernel will not panic on stall. If n > 0, the kernel
1351 will panic after n stall warnings.
1352
1353 The panic can be used in combination with panic_timeout,
1354 to cause the system to reboot automatically after a
1355 stall has been detected. This feature is useful for
1356 high-availability systems that have uptime guarantees and
1357 where a stall must be resolved ASAP.
1358
1359 This setting can be overridden at runtime via the
1360 workqueue.panic_on_stall kernel parameter.
1361
1362config WQ_CPU_INTENSIVE_REPORT
1363 bool "Report per-cpu work items which hog CPU for too long"
1364 depends on DEBUG_KERNEL
1365 help
1366 Say Y here to enable reporting of concurrency-managed per-cpu work
1367 items that hog CPUs for longer than
1368 workqueue.cpu_intensive_thresh_us. Workqueue automatically
1369 detects and excludes them from concurrency management to prevent
1370 them from stalling other per-cpu work items. Occassional
1371 triggering may not necessarily indicate a problem. Repeated
1372 triggering likely indicates that the work item should be switched
1373 to use an unbound workqueue.
1374
1375config TEST_LOCKUP
1376 tristate "Test module to generate lockups"
1377 depends on m
1378 help
1379 This builds the "test_lockup" module that helps to make sure
1380 that watchdogs and lockup detectors are working properly.
1381
1382 Depending on module parameters it could emulate soft or hard
1383 lockup, "hung task", or locking arbitrary lock for a long time.
1384 Also it could generate series of lockups with cooling-down periods.
1385
1386 If unsure, say N.
1387
1388endmenu # "Debug lockups and hangs"
1389
1390menu "Scheduler Debugging"
1391
1392config SCHED_INFO
1393 bool
1394 default n
1395
1396config SCHEDSTATS
1397 bool "Collect scheduler statistics"
1398 depends on PROC_FS
1399 select SCHED_INFO
1400 help
1401 If you say Y here, additional code will be inserted into the
1402 scheduler and related routines to collect statistics about
1403 scheduler behavior and provide them in /proc/schedstat. These
1404 stats may be useful for both tuning and debugging the scheduler
1405 If you aren't debugging the scheduler or trying to tune a specific
1406 application, you can say N to avoid the very slight overhead
1407 this adds.
1408
1409endmenu
1410
1411config DEBUG_PREEMPT
1412 bool "Debug preemptible kernel"
1413 depends on DEBUG_KERNEL && PREEMPTION && TRACE_IRQFLAGS_SUPPORT
1414 help
1415 If you say Y here then the kernel will use a debug variant of the
1416 commonly used smp_processor_id() function and will print warnings
1417 if kernel code uses it in a preemption-unsafe way. Also, the kernel
1418 will detect preemption count underflows.
1419
1420 This option has potential to introduce high runtime overhead,
1421 depending on workload as it triggers debugging routines for each
1422 this_cpu operation. It should only be used for debugging purposes.
1423
1424config DEBUG_ATOMIC
1425 bool "Debug atomic variables"
1426 depends on DEBUG_KERNEL
1427 help
1428 If you say Y here then the kernel will add a runtime alignment check
1429 to atomic accesses. Useful for architectures that do not have trap on
1430 mis-aligned access.
1431
1432 This option has potentially significant overhead.
1433
1434config DEBUG_ATOMIC_LARGEST_ALIGN
1435 bool "Check alignment only up to __aligned_largest"
1436 depends on DEBUG_ATOMIC
1437 help
1438 If you say Y here then the check for natural alignment of
1439 atomic accesses will be constrained to the compiler's largest
1440 alignment for scalar types.
1441
1442menu "Lock Debugging (spinlocks, mutexes, etc...)"
1443
1444config LOCK_DEBUGGING_SUPPORT
1445 bool
1446 depends on TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
1447 default y
1448
1449config PROVE_LOCKING
1450 bool "Lock debugging: prove locking correctness"
1451 depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
1452 select LOCKDEP
1453 select DEBUG_SPINLOCK
1454 select DEBUG_MUTEXES if !PREEMPT_RT
1455 select DEBUG_RT_MUTEXES if RT_MUTEXES
1456 select DEBUG_RWSEMS if !PREEMPT_RT
1457 select DEBUG_WW_MUTEX_SLOWPATH
1458 select DEBUG_LOCK_ALLOC
1459 select PREEMPT_COUNT if !ARCH_NO_PREEMPT
1460 select TRACE_IRQFLAGS
1461 default n
1462 help
1463 This feature enables the kernel to prove that all locking
1464 that occurs in the kernel runtime is mathematically
1465 correct: that under no circumstance could an arbitrary (and
1466 not yet triggered) combination of observed locking
1467 sequences (on an arbitrary number of CPUs, running an
1468 arbitrary number of tasks and interrupt contexts) cause a
1469 deadlock.
1470
1471 In short, this feature enables the kernel to report locking
1472 related deadlocks before they actually occur.
1473
1474 The proof does not depend on how hard and complex a
1475 deadlock scenario would be to trigger: how many
1476 participant CPUs, tasks and irq-contexts would be needed
1477 for it to trigger. The proof also does not depend on
1478 timing: if a race and a resulting deadlock is possible
1479 theoretically (no matter how unlikely the race scenario
1480 is), it will be proven so and will immediately be
1481 reported by the kernel (once the event is observed that
1482 makes the deadlock theoretically possible).
1483
1484 If a deadlock is impossible (i.e. the locking rules, as
1485 observed by the kernel, are mathematically correct), the
1486 kernel reports nothing.
1487
1488 NOTE: this feature can also be enabled for rwlocks, mutexes
1489 and rwsems - in which case all dependencies between these
1490 different locking variants are observed and mapped too, and
1491 the proof of observed correctness is also maintained for an
1492 arbitrary combination of these separate locking variants.
1493
1494 For more details, see Documentation/locking/lockdep-design.rst.
1495
1496config PROVE_RAW_LOCK_NESTING
1497 bool "Enable raw_spinlock - spinlock nesting checks" if !ARCH_SUPPORTS_RT
1498 depends on PROVE_LOCKING
1499 default y if ARCH_SUPPORTS_RT
1500 help
1501 Enable the raw_spinlock vs. spinlock nesting checks which ensure
1502 that the lock nesting rules for PREEMPT_RT enabled kernels are
1503 not violated.
1504
1505config LOCK_STAT
1506 bool "Lock usage statistics"
1507 depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
1508 select LOCKDEP
1509 select DEBUG_SPINLOCK
1510 select DEBUG_MUTEXES if !PREEMPT_RT
1511 select DEBUG_RT_MUTEXES if RT_MUTEXES
1512 select DEBUG_LOCK_ALLOC
1513 default n
1514 help
1515 This feature enables tracking lock contention points
1516
1517 For more details, see Documentation/locking/lockstat.rst
1518
1519 This also enables lock events required by "perf lock",
1520 subcommand of perf.
1521 If you want to use "perf lock", you also need to turn on
1522 CONFIG_EVENT_TRACING.
1523
1524 CONFIG_LOCK_STAT defines "contended" and "acquired" lock events.
1525 (CONFIG_LOCKDEP defines "acquire" and "release" events.)
1526
1527config DEBUG_RT_MUTEXES
1528 bool "RT Mutex debugging, deadlock detection"
1529 depends on DEBUG_KERNEL && RT_MUTEXES
1530 help
1531 This allows rt mutex semantics violations and rt mutex related
1532 deadlocks (lockups) to be detected and reported automatically.
1533
1534config DEBUG_SPINLOCK
1535 bool "Spinlock and rw-lock debugging: basic checks"
1536 depends on DEBUG_KERNEL
1537 select UNINLINE_SPIN_UNLOCK
1538 help
1539 Say Y here and build SMP to catch missing spinlock initialization
1540 and certain other kinds of spinlock errors commonly made. This is
1541 best used in conjunction with the NMI watchdog so that spinlock
1542 deadlocks are also debuggable.
1543
1544config DEBUG_MUTEXES
1545 bool "Mutex debugging: basic checks"
1546 depends on DEBUG_KERNEL && !PREEMPT_RT
1547 help
1548 This feature allows mutex semantics violations to be detected and
1549 reported.
1550
1551config DEBUG_WW_MUTEX_SLOWPATH
1552 bool "Wait/wound mutex debugging: Slowpath testing"
1553 depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
1554 select DEBUG_LOCK_ALLOC
1555 select DEBUG_SPINLOCK
1556 select DEBUG_MUTEXES if !PREEMPT_RT
1557 select DEBUG_RT_MUTEXES if PREEMPT_RT
1558 help
1559 This feature enables slowpath testing for w/w mutex users by
1560 injecting additional -EDEADLK wound/backoff cases. Together with
1561 the full mutex checks enabled with (CONFIG_PROVE_LOCKING) this
1562 will test all possible w/w mutex interface abuse with the
1563 exception of simply not acquiring all the required locks.
1564 Note that this feature can introduce significant overhead, so
1565 it really should not be enabled in a production or distro kernel,
1566 even a debug kernel. If you are a driver writer, enable it. If
1567 you are a distro, do not.
1568
1569config DEBUG_RWSEMS
1570 bool "RW Semaphore debugging: basic checks"
1571 depends on DEBUG_KERNEL && !PREEMPT_RT
1572 help
1573 This debugging feature allows mismatched rw semaphore locks
1574 and unlocks to be detected and reported.
1575
1576config DEBUG_LOCK_ALLOC
1577 bool "Lock debugging: detect incorrect freeing of live locks"
1578 depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
1579 select DEBUG_SPINLOCK
1580 select DEBUG_MUTEXES if !PREEMPT_RT
1581 select DEBUG_RT_MUTEXES if RT_MUTEXES
1582 select LOCKDEP
1583 help
1584 This feature will check whether any held lock (spinlock, rwlock,
1585 mutex or rwsem) is incorrectly freed by the kernel, via any of the
1586 memory-freeing routines (kfree(), kmem_cache_free(), free_pages(),
1587 vfree(), etc.), whether a live lock is incorrectly reinitialized via
1588 spin_lock_init()/mutex_init()/etc., or whether there is any lock
1589 held during task exit.
1590
1591config LOCKDEP
1592 bool
1593 depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
1594 select STACKTRACE
1595 select KALLSYMS
1596 select KALLSYMS_ALL
1597
1598config LOCKDEP_SMALL
1599 bool
1600
1601config LOCKDEP_BITS
1602 int "Size for MAX_LOCKDEP_ENTRIES (as Nth power of 2)"
1603 depends on LOCKDEP && !LOCKDEP_SMALL
1604 range 10 24
1605 default 15
1606 help
1607 Try increasing this value if you hit "BUG: MAX_LOCKDEP_ENTRIES too low!" message.
1608
1609config LOCKDEP_CHAINS_BITS
1610 int "Size for MAX_LOCKDEP_CHAINS (as Nth power of 2)"
1611 depends on LOCKDEP && !LOCKDEP_SMALL
1612 range 10 21
1613 default 16
1614 help
1615 Try increasing this value if you hit "BUG: MAX_LOCKDEP_CHAINS too low!" message.
1616
1617config LOCKDEP_STACK_TRACE_BITS
1618 int "Size for MAX_STACK_TRACE_ENTRIES (as Nth power of 2)"
1619 depends on LOCKDEP && !LOCKDEP_SMALL
1620 range 10 26
1621 default 19
1622 help
1623 Try increasing this value if you hit "BUG: MAX_STACK_TRACE_ENTRIES too low!" message.
1624
1625config LOCKDEP_STACK_TRACE_HASH_BITS
1626 int "Size for STACK_TRACE_HASH_SIZE (as Nth power of 2)"
1627 depends on LOCKDEP && !LOCKDEP_SMALL
1628 range 10 26
1629 default 14
1630 help
1631 Try increasing this value if you need large STACK_TRACE_HASH_SIZE.
1632
1633config LOCKDEP_CIRCULAR_QUEUE_BITS
1634 int "Size for elements in circular_queue struct (as Nth power of 2)"
1635 depends on LOCKDEP
1636 range 10 26
1637 default 12
1638 help
1639 Try increasing this value if you hit "lockdep bfs error:-1" warning due to __cq_enqueue() failure.
1640
1641config DEBUG_LOCKDEP
1642 bool "Lock dependency engine debugging"
1643 depends on DEBUG_KERNEL && LOCKDEP
1644 select DEBUG_IRQFLAGS
1645 help
1646 If you say Y here, the lock dependency engine will do
1647 additional runtime checks to debug itself, at the price
1648 of more runtime overhead.
1649
1650config DEBUG_ATOMIC_SLEEP
1651 bool "Sleep inside atomic section checking"
1652 select PREEMPT_COUNT
1653 depends on DEBUG_KERNEL
1654 depends on !ARCH_NO_PREEMPT
1655 help
1656 If you say Y here, various routines which may sleep will become very
1657 noisy if they are called inside atomic sections: when a spinlock is
1658 held, inside an rcu read side critical section, inside preempt disabled
1659 sections, inside an interrupt, etc...
1660
1661config DEBUG_LOCKING_API_SELFTESTS
1662 bool "Locking API boot-time self-tests"
1663 depends on DEBUG_KERNEL
1664 help
1665 Say Y here if you want the kernel to run a short self-test during
1666 bootup. The self-test checks whether common types of locking bugs
1667 are detected by debugging mechanisms or not. (if you disable
1668 lock debugging then those bugs won't be detected of course.)
1669 The following locking APIs are covered: spinlocks, rwlocks,
1670 mutexes and rwsems.
1671
1672config LOCK_TORTURE_TEST
1673 tristate "torture tests for locking"
1674 depends on DEBUG_KERNEL
1675 select TORTURE_TEST
1676 help
1677 This option provides a kernel module that runs torture tests
1678 on kernel locking primitives. The kernel module may be built
1679 after the fact on the running kernel to be tested, if desired.
1680
1681 Say Y here if you want kernel locking-primitive torture tests
1682 to be built into the kernel.
1683 Say M if you want these torture tests to build as a module.
1684 Say N if you are unsure.
1685
1686config WW_MUTEX_SELFTEST
1687 tristate "Wait/wound mutex selftests"
1688 help
1689 This option provides a kernel module that runs tests on the
1690 on the struct ww_mutex locking API.
1691
1692 It is recommended to enable DEBUG_WW_MUTEX_SLOWPATH in conjunction
1693 with this test harness.
1694
1695 Say M if you want these self tests to build as a module.
1696 Say N if you are unsure.
1697
1698config SCF_TORTURE_TEST
1699 tristate "torture tests for smp_call_function*()"
1700 depends on DEBUG_KERNEL
1701 select TORTURE_TEST
1702 help
1703 This option provides a kernel module that runs torture tests
1704 on the smp_call_function() family of primitives. The kernel
1705 module may be built after the fact on the running kernel to
1706 be tested, if desired.
1707
1708config CSD_LOCK_WAIT_DEBUG
1709 bool "Debugging for csd_lock_wait(), called from smp_call_function*()"
1710 depends on DEBUG_KERNEL
1711 depends on SMP
1712 depends on 64BIT
1713 default n
1714 help
1715 This option enables debug prints when CPUs are slow to respond
1716 to the smp_call_function*() IPI wrappers. These debug prints
1717 include the IPI handler function currently executing (if any)
1718 and relevant stack traces.
1719
1720config CSD_LOCK_WAIT_DEBUG_DEFAULT
1721 bool "Default csd_lock_wait() debugging on at boot time"
1722 depends on CSD_LOCK_WAIT_DEBUG
1723 depends on 64BIT
1724 default n
1725 help
1726 This option causes the csdlock_debug= kernel boot parameter to
1727 default to 1 (basic debugging) instead of 0 (no debugging).
1728
1729endmenu # lock debugging
1730
1731config TRACE_IRQFLAGS
1732 depends on TRACE_IRQFLAGS_SUPPORT
1733 bool
1734 help
1735 Enables hooks to interrupt enabling and disabling for
1736 either tracing or lock debugging.
1737
1738config TRACE_IRQFLAGS_NMI
1739 def_bool y
1740 depends on TRACE_IRQFLAGS
1741 depends on TRACE_IRQFLAGS_NMI_SUPPORT
1742
1743config NMI_CHECK_CPU
1744 bool "Debugging for CPUs failing to respond to backtrace requests"
1745 depends on DEBUG_KERNEL
1746 depends on X86
1747 default n
1748 help
1749 Enables debug prints when a CPU fails to respond to a given
1750 backtrace NMI. These prints provide some reasons why a CPU
1751 might legitimately be failing to respond, for example, if it
1752 is offline of if ignore_nmis is set.
1753
1754config DEBUG_IRQFLAGS
1755 bool "Debug IRQ flag manipulation"
1756 help
1757 Enables checks for potentially unsafe enabling or disabling of
1758 interrupts, such as calling raw_local_irq_restore() when interrupts
1759 are enabled.
1760
1761config STACKTRACE
1762 bool "Stack backtrace support"
1763 depends on STACKTRACE_SUPPORT
1764 help
1765 This option causes the kernel to create a /proc/pid/stack for
1766 every process, showing its current stack trace.
1767 It is also used by various kernel debugging features that require
1768 stack trace generation.
1769
1770config DEBUG_KOBJECT
1771 bool "kobject debugging"
1772 depends on DEBUG_KERNEL
1773 help
1774 If you say Y here, some extra kobject debugging messages will be sent
1775 to the syslog.
1776
1777config DEBUG_KOBJECT_RELEASE
1778 bool "kobject release debugging"
1779 depends on DEBUG_OBJECTS_TIMERS
1780 help
1781 kobjects are reference counted objects. This means that their
1782 last reference count put is not predictable, and the kobject can
1783 live on past the point at which a driver decides to drop its
1784 initial reference to the kobject gained on allocation. An
1785 example of this would be a struct device which has just been
1786 unregistered.
1787
1788 However, some buggy drivers assume that after such an operation,
1789 the memory backing the kobject can be immediately freed. This
1790 goes completely against the principles of a refcounted object.
1791
1792 If you say Y here, the kernel will delay the release of kobjects
1793 on the last reference count to improve the visibility of this
1794 kind of kobject release bug.
1795
1796config HAVE_DEBUG_BUGVERBOSE
1797 bool
1798
1799menu "Debug kernel data structures"
1800
1801config DEBUG_LIST
1802 bool "Debug linked list manipulation"
1803 depends on DEBUG_KERNEL
1804 select LIST_HARDENED
1805 help
1806 Enable this to turn on extended checks in the linked-list walking
1807 routines.
1808
1809 This option trades better quality error reports for performance, and
1810 is more suitable for kernel debugging. If you care about performance,
1811 you should only enable CONFIG_LIST_HARDENED instead.
1812
1813 If unsure, say N.
1814
1815config DEBUG_PLIST
1816 bool "Debug priority linked list manipulation"
1817 depends on DEBUG_KERNEL
1818 help
1819 Enable this to turn on extended checks in the priority-ordered
1820 linked-list (plist) walking routines. This checks the entire
1821 list multiple times during each manipulation.
1822
1823 If unsure, say N.
1824
1825config DEBUG_SG
1826 bool "Debug SG table operations"
1827 depends on DEBUG_KERNEL
1828 help
1829 Enable this to turn on checks on scatter-gather tables. This can
1830 help find problems with drivers that do not properly initialize
1831 their sg tables.
1832
1833 If unsure, say N.
1834
1835config DEBUG_NOTIFIERS
1836 bool "Debug notifier call chains"
1837 depends on DEBUG_KERNEL
1838 help
1839 Enable this to turn on sanity checking for notifier call chains.
1840 This is most useful for kernel developers to make sure that
1841 modules properly unregister themselves from notifier chains.
1842 This is a relatively cheap check but if you care about maximum
1843 performance, say N.
1844
1845config DEBUG_CLOSURES
1846 bool "Debug closures (bcache async widgits)"
1847 depends on CLOSURES
1848 select DEBUG_FS
1849 help
1850 Keeps all active closures in a linked list and provides a debugfs
1851 interface to list them, which makes it possible to see asynchronous
1852 operations that get stuck.
1853
1854config DEBUG_MAPLE_TREE
1855 bool "Debug maple trees"
1856 depends on DEBUG_KERNEL
1857 help
1858 Enable maple tree debugging information and extra validations.
1859
1860 If unsure, say N.
1861
1862endmenu
1863
1864source "kernel/rcu/Kconfig.debug"
1865
1866config DEBUG_WQ_FORCE_RR_CPU
1867 bool "Force round-robin CPU selection for unbound work items"
1868 depends on DEBUG_KERNEL
1869 default n
1870 help
1871 Workqueue used to implicitly guarantee that work items queued
1872 without explicit CPU specified are put on the local CPU. This
1873 guarantee is no longer true and while local CPU is still
1874 preferred work items may be put on foreign CPUs. Kernel
1875 parameter "workqueue.debug_force_rr_cpu" is added to force
1876 round-robin CPU selection to flush out usages which depend on the
1877 now broken guarantee. This config option enables the debug
1878 feature by default. When enabled, memory and cache locality will
1879 be impacted.
1880
1881config CPU_HOTPLUG_STATE_CONTROL
1882 bool "Enable CPU hotplug state control"
1883 depends on DEBUG_KERNEL
1884 depends on HOTPLUG_CPU
1885 default n
1886 help
1887 Allows to write steps between "offline" and "online" to the CPUs
1888 sysfs target file so states can be stepped granular. This is a debug
1889 option for now as the hotplug machinery cannot be stopped and
1890 restarted at arbitrary points yet.
1891
1892 Say N if your are unsure.
1893
1894config LATENCYTOP
1895 bool "Latency measuring infrastructure"
1896 depends on DEBUG_KERNEL
1897 depends on STACKTRACE_SUPPORT
1898 depends on PROC_FS
1899 depends on FRAME_POINTER || MIPS || PPC || S390 || MICROBLAZE || ARM || ARC || X86
1900 select KALLSYMS
1901 select KALLSYMS_ALL
1902 select STACKTRACE
1903 select SCHEDSTATS
1904 help
1905 Enable this option if you want to use the LatencyTOP tool
1906 to find out which userspace is blocking on what kernel operations.
1907
1908config DEBUG_CGROUP_REF
1909 bool "Disable inlining of cgroup css reference count functions"
1910 depends on DEBUG_KERNEL
1911 depends on CGROUPS
1912 depends on KPROBES
1913 default n
1914 help
1915 Force cgroup css reference count functions to not be inlined so
1916 that they can be kprobed for debugging.
1917
1918source "kernel/trace/Kconfig"
1919
1920config PROVIDE_OHCI1394_DMA_INIT
1921 bool "Remote debugging over FireWire early on boot"
1922 depends on PCI && X86
1923 help
1924 If you want to debug problems which hang or crash the kernel early
1925 on boot and the crashing machine has a FireWire port, you can use
1926 this feature to remotely access the memory of the crashed machine
1927 over FireWire. This employs remote DMA as part of the OHCI1394
1928 specification which is now the standard for FireWire controllers.
1929
1930 With remote DMA, you can monitor the printk buffer remotely using
1931 firescope and access all memory below 4GB using fireproxy from gdb.
1932 Even controlling a kernel debugger is possible using remote DMA.
1933
1934 Usage:
1935
1936 If ohci1394_dma=early is used as boot parameter, it will initialize
1937 all OHCI1394 controllers which are found in the PCI config space.
1938
1939 As all changes to the FireWire bus such as enabling and disabling
1940 devices cause a bus reset and thereby disable remote DMA for all
1941 devices, be sure to have the cable plugged and FireWire enabled on
1942 the debugging host before booting the debug target for debugging.
1943
1944 This code (~1k) is freed after boot. By then, the firewire stack
1945 in charge of the OHCI-1394 controllers should be used instead.
1946
1947 See Documentation/core-api/debugging-via-ohci1394.rst for more information.
1948
1949source "samples/Kconfig"
1950
1951config ARCH_HAS_DEVMEM_IS_ALLOWED
1952 bool
1953
1954config STRICT_DEVMEM
1955 bool "Filter access to /dev/mem"
1956 depends on MMU && DEVMEM
1957 depends on ARCH_HAS_DEVMEM_IS_ALLOWED || GENERIC_LIB_DEVMEM_IS_ALLOWED
1958 default y if PPC || X86 || ARM64 || S390
1959 help
1960 If this option is disabled, you allow userspace (root) access to all
1961 of memory, including kernel and userspace memory. Accidental
1962 access to this is obviously disastrous, but specific access can
1963 be used by people debugging the kernel. Note that with PAT support
1964 enabled, even in this case there are restrictions on /dev/mem
1965 use due to the cache aliasing requirements.
1966
1967 If this option is switched on, and IO_STRICT_DEVMEM=n, the /dev/mem
1968 file only allows userspace access to PCI space and the BIOS code and
1969 data regions. This is sufficient for dosemu and X and all common
1970 users of /dev/mem.
1971
1972 If in doubt, say Y.
1973
1974config IO_STRICT_DEVMEM
1975 bool "Filter I/O access to /dev/mem"
1976 depends on STRICT_DEVMEM
1977 help
1978 If this option is disabled, you allow userspace (root) access to all
1979 io-memory regardless of whether a driver is actively using that
1980 range. Accidental access to this is obviously disastrous, but
1981 specific access can be used by people debugging kernel drivers.
1982
1983 If this option is switched on, the /dev/mem file only allows
1984 userspace access to *idle* io-memory ranges (see /proc/iomem) This
1985 may break traditional users of /dev/mem (dosemu, legacy X, etc...)
1986 if the driver using a given range cannot be disabled.
1987
1988 If in doubt, say Y.
1989
1990menu "$(SRCARCH) Debugging"
1991
1992source "arch/$(SRCARCH)/Kconfig.debug"
1993
1994endmenu
1995
1996menu "Kernel Testing and Coverage"
1997
1998source "lib/kunit/Kconfig"
1999
2000config NOTIFIER_ERROR_INJECTION
2001 tristate "Notifier error injection"
2002 depends on DEBUG_KERNEL
2003 select DEBUG_FS
2004 help
2005 This option provides the ability to inject artificial errors to
2006 specified notifier chain callbacks. It is useful to test the error
2007 handling of notifier call chain failures.
2008
2009 Say N if unsure.
2010
2011config PM_NOTIFIER_ERROR_INJECT
2012 tristate "PM notifier error injection module"
2013 depends on PM && NOTIFIER_ERROR_INJECTION
2014 default m if PM_DEBUG
2015 help
2016 This option provides the ability to inject artificial errors to
2017 PM notifier chain callbacks. It is controlled through debugfs
2018 interface /sys/kernel/debug/notifier-error-inject/pm
2019
2020 If the notifier call chain should be failed with some events
2021 notified, write the error code to "actions/<notifier event>/error".
2022
2023 Example: Inject PM suspend error (-12 = -ENOMEM)
2024
2025 # cd /sys/kernel/debug/notifier-error-inject/pm/
2026 # echo -12 > actions/PM_SUSPEND_PREPARE/error
2027 # echo mem > /sys/power/state
2028 bash: echo: write error: Cannot allocate memory
2029
2030 To compile this code as a module, choose M here: the module will
2031 be called pm-notifier-error-inject.
2032
2033 If unsure, say N.
2034
2035config OF_RECONFIG_NOTIFIER_ERROR_INJECT
2036 tristate "OF reconfig notifier error injection module"
2037 depends on OF_DYNAMIC && NOTIFIER_ERROR_INJECTION
2038 help
2039 This option provides the ability to inject artificial errors to
2040 OF reconfig notifier chain callbacks. It is controlled
2041 through debugfs interface under
2042 /sys/kernel/debug/notifier-error-inject/OF-reconfig/
2043
2044 If the notifier call chain should be failed with some events
2045 notified, write the error code to "actions/<notifier event>/error".
2046
2047 To compile this code as a module, choose M here: the module will
2048 be called of-reconfig-notifier-error-inject.
2049
2050 If unsure, say N.
2051
2052config NETDEV_NOTIFIER_ERROR_INJECT
2053 tristate "Netdev notifier error injection module"
2054 depends on NET && NOTIFIER_ERROR_INJECTION
2055 help
2056 This option provides the ability to inject artificial errors to
2057 netdevice notifier chain callbacks. It is controlled through debugfs
2058 interface /sys/kernel/debug/notifier-error-inject/netdev
2059
2060 If the notifier call chain should be failed with some events
2061 notified, write the error code to "actions/<notifier event>/error".
2062
2063 Example: Inject netdevice mtu change error (-22 = -EINVAL)
2064
2065 # cd /sys/kernel/debug/notifier-error-inject/netdev
2066 # echo -22 > actions/NETDEV_CHANGEMTU/error
2067 # ip link set eth0 mtu 1024
2068 RTNETLINK answers: Invalid argument
2069
2070 To compile this code as a module, choose M here: the module will
2071 be called netdev-notifier-error-inject.
2072
2073 If unsure, say N.
2074
2075config FUNCTION_ERROR_INJECTION
2076 bool "Fault-injections of functions"
2077 depends on HAVE_FUNCTION_ERROR_INJECTION && KPROBES
2078 help
2079 Add fault injections into various functions that are annotated with
2080 ALLOW_ERROR_INJECTION() in the kernel. BPF may also modify the return
2081 value of these functions. This is useful to test error paths of code.
2082
2083 If unsure, say N
2084
2085config FAULT_INJECTION
2086 bool "Fault-injection framework"
2087 depends on DEBUG_KERNEL
2088 help
2089 Provide fault-injection framework.
2090 For more details, see Documentation/fault-injection/.
2091
2092config FAILSLAB
2093 bool "Fault-injection capability for kmalloc"
2094 depends on FAULT_INJECTION
2095 help
2096 Provide fault-injection capability for kmalloc.
2097
2098config FAIL_PAGE_ALLOC
2099 bool "Fault-injection capability for alloc_pages()"
2100 depends on FAULT_INJECTION
2101 help
2102 Provide fault-injection capability for alloc_pages().
2103
2104config FAULT_INJECTION_USERCOPY
2105 bool "Fault injection capability for usercopy functions"
2106 depends on FAULT_INJECTION
2107 help
2108 Provides fault-injection capability to inject failures
2109 in usercopy functions (copy_from_user(), get_user(), ...).
2110
2111config FAIL_MAKE_REQUEST
2112 bool "Fault-injection capability for disk IO"
2113 depends on FAULT_INJECTION && BLOCK
2114 help
2115 Provide fault-injection capability for disk IO.
2116
2117config FAIL_IO_TIMEOUT
2118 bool "Fault-injection capability for faking disk interrupts"
2119 depends on FAULT_INJECTION && BLOCK
2120 help
2121 Provide fault-injection capability on end IO handling. This
2122 will make the block layer "forget" an interrupt as configured,
2123 thus exercising the error handling.
2124
2125 Only works with drivers that use the generic timeout handling,
2126 for others it won't do anything.
2127
2128config FAIL_FUTEX
2129 bool "Fault-injection capability for futexes"
2130 select DEBUG_FS
2131 depends on FAULT_INJECTION && FUTEX
2132 help
2133 Provide fault-injection capability for futexes.
2134
2135config FAULT_INJECTION_DEBUG_FS
2136 bool "Debugfs entries for fault-injection capabilities"
2137 depends on FAULT_INJECTION && SYSFS && DEBUG_FS
2138 help
2139 Enable configuration of fault-injection capabilities via debugfs.
2140
2141config FAIL_FUNCTION
2142 bool "Fault-injection capability for functions"
2143 depends on FAULT_INJECTION_DEBUG_FS && FUNCTION_ERROR_INJECTION
2144 help
2145 Provide function-based fault-injection capability.
2146 This will allow you to override a specific function with a return
2147 with given return value. As a result, function caller will see
2148 an error value and have to handle it. This is useful to test the
2149 error handling in various subsystems.
2150
2151config FAIL_MMC_REQUEST
2152 bool "Fault-injection capability for MMC IO"
2153 depends on FAULT_INJECTION_DEBUG_FS && MMC
2154 help
2155 Provide fault-injection capability for MMC IO.
2156 This will make the mmc core return data errors. This is
2157 useful to test the error handling in the mmc block device
2158 and to test how the mmc host driver handles retries from
2159 the block device.
2160
2161config FAIL_SUNRPC
2162 bool "Fault-injection capability for SunRPC"
2163 depends on FAULT_INJECTION_DEBUG_FS && SUNRPC_DEBUG
2164 help
2165 Provide fault-injection capability for SunRPC and
2166 its consumers.
2167
2168config FAIL_SKB_REALLOC
2169 bool "Fault-injection capability forcing skb to reallocate"
2170 depends on FAULT_INJECTION_DEBUG_FS
2171 help
2172 Provide fault-injection capability that forces the skb to be
2173 reallocated, catching possible invalid pointers to the skb.
2174
2175 For more information, check
2176 Documentation/fault-injection/fault-injection.rst
2177
2178config FAULT_INJECTION_CONFIGFS
2179 bool "Configfs interface for fault-injection capabilities"
2180 depends on FAULT_INJECTION
2181 select CONFIGFS_FS
2182 help
2183 This option allows configfs-based drivers to dynamically configure
2184 fault-injection via configfs. Each parameter for driver-specific
2185 fault-injection can be made visible as a configfs attribute in a
2186 configfs group.
2187
2188
2189config FAULT_INJECTION_STACKTRACE_FILTER
2190 bool "stacktrace filter for fault-injection capabilities"
2191 depends on FAULT_INJECTION
2192 depends on (FAULT_INJECTION_DEBUG_FS || FAULT_INJECTION_CONFIGFS) && STACKTRACE_SUPPORT
2193 select STACKTRACE
2194 depends on FRAME_POINTER || MIPS || PPC || S390 || MICROBLAZE || ARM || ARC || X86
2195 help
2196 Provide stacktrace filter for fault-injection capabilities
2197
2198config ARCH_HAS_KCOV
2199 bool
2200 help
2201 An architecture should select this when it can successfully
2202 build and run with CONFIG_KCOV. This typically requires
2203 disabling instrumentation for some early boot code.
2204
2205config KCOV
2206 bool "Code coverage for fuzzing"
2207 depends on ARCH_HAS_KCOV
2208 depends on !ARCH_WANTS_NO_INSTR || HAVE_NOINSTR_HACK || \
2209 GCC_VERSION >= 120000 || CC_IS_CLANG
2210 select DEBUG_FS
2211 select OBJTOOL if HAVE_NOINSTR_HACK
2212 help
2213 KCOV exposes kernel code coverage information in a form suitable
2214 for coverage-guided fuzzing (randomized testing).
2215
2216 For more details, see Documentation/dev-tools/kcov.rst.
2217
2218config KCOV_ENABLE_COMPARISONS
2219 bool "Enable comparison operands collection by KCOV"
2220 depends on KCOV
2221 depends on $(cc-option,-fsanitize-coverage=trace-cmp)
2222 help
2223 KCOV also exposes operands of every comparison in the instrumented
2224 code along with operand sizes and PCs of the comparison instructions.
2225 These operands can be used by fuzzing engines to improve the quality
2226 of fuzzing coverage.
2227
2228config KCOV_INSTRUMENT_ALL
2229 bool "Instrument all code by default"
2230 depends on KCOV
2231 default y
2232 help
2233 If you are doing generic system call fuzzing (like e.g. syzkaller),
2234 then you will want to instrument the whole kernel and you should
2235 say y here. If you are doing more targeted fuzzing (like e.g.
2236 filesystem fuzzing with AFL) then you will want to enable coverage
2237 for more specific subsets of files, and should say n here.
2238
2239config KCOV_IRQ_AREA_SIZE
2240 hex "Size of interrupt coverage collection area in words"
2241 depends on KCOV
2242 default 0x40000
2243 help
2244 KCOV uses preallocated per-cpu areas to collect coverage from
2245 soft interrupts. This specifies the size of those areas in the
2246 number of unsigned long words.
2247
2248config KCOV_SELFTEST
2249 bool "Perform short selftests on boot"
2250 depends on KCOV
2251 help
2252 Run short KCOV coverage collection selftests on boot.
2253 On test failure, causes the kernel to panic. Recommended to be
2254 enabled, ensuring critical functionality works as intended.
2255
2256menuconfig RUNTIME_TESTING_MENU
2257 bool "Runtime Testing"
2258 default y
2259
2260if RUNTIME_TESTING_MENU
2261
2262config TEST_DHRY
2263 tristate "Dhrystone benchmark test"
2264 help
2265 Enable this to include the Dhrystone 2.1 benchmark. This test
2266 calculates the number of Dhrystones per second, and the number of
2267 DMIPS (Dhrystone MIPS) obtained when the Dhrystone score is divided
2268 by 1757 (the number of Dhrystones per second obtained on the VAX
2269 11/780, nominally a 1 MIPS machine).
2270
2271 To run the benchmark, it needs to be enabled explicitly, either from
2272 the kernel command line (when built-in), or from userspace (when
2273 built-in or modular).
2274
2275 Run once during kernel boot:
2276
2277 test_dhry.run
2278
2279 Set number of iterations from kernel command line:
2280
2281 test_dhry.iterations=<n>
2282
2283 Set number of iterations from userspace:
2284
2285 echo <n> > /sys/module/test_dhry/parameters/iterations
2286
2287 Trigger manual run from userspace:
2288
2289 echo y > /sys/module/test_dhry/parameters/run
2290
2291 If the number of iterations is <= 0, the test will devise a suitable
2292 number of iterations (test runs for at least 2s) automatically.
2293 This process takes ca. 4s.
2294
2295 If unsure, say N.
2296
2297config LKDTM
2298 tristate "Linux Kernel Dump Test Tool Module"
2299 depends on DEBUG_FS
2300 help
2301 This module enables testing of the different dumping mechanisms by
2302 inducing system failures at predefined crash points.
2303 If you don't need it: say N
2304 Choose M here to compile this code as a module. The module will be
2305 called lkdtm.
2306
2307 Documentation on how to use the module can be found in
2308 Documentation/fault-injection/provoke-crashes.rst
2309
2310config CPUMASK_KUNIT_TEST
2311 tristate "KUnit test for cpumask" if !KUNIT_ALL_TESTS
2312 depends on KUNIT
2313 default KUNIT_ALL_TESTS
2314 help
2315 Enable to turn on cpumask tests, running at boot or module load time.
2316
2317 For more information on KUnit and unit tests in general, please refer
2318 to the KUnit documentation in Documentation/dev-tools/kunit/.
2319
2320 If unsure, say N.
2321
2322config TEST_LIST_SORT
2323 tristate "Linked list sorting test" if !KUNIT_ALL_TESTS
2324 depends on KUNIT
2325 default KUNIT_ALL_TESTS
2326 help
2327 Enable this to turn on 'list_sort()' function test. This test is
2328 executed only once during system boot (so affects only boot time),
2329 or at module load time.
2330
2331 If unsure, say N.
2332
2333config TEST_SORT
2334 tristate "Array-based sort test" if !KUNIT_ALL_TESTS
2335 depends on KUNIT
2336 default KUNIT_ALL_TESTS
2337 help
2338 This option enables the self-test function of 'sort()' at boot,
2339 or at module load time.
2340
2341 If unsure, say N.
2342
2343config TEST_DIV64
2344 tristate "64bit/32bit division and modulo test"
2345 depends on DEBUG_KERNEL || m
2346 help
2347 Enable this to turn on 'do_div()' function test. This test is
2348 executed only once during system boot (so affects only boot time),
2349 or at module load time.
2350
2351 If unsure, say N.
2352
2353config TEST_MULDIV64
2354 tristate "mul_u64_u64_div_u64() test"
2355 depends on DEBUG_KERNEL || m
2356 help
2357 Enable this to turn on 'mul_u64_u64_div_u64()' function test.
2358 This test is executed only once during system boot (so affects
2359 only boot time), or at module load time.
2360
2361 If unsure, say N.
2362
2363config TEST_IOV_ITER
2364 tristate "Test iov_iter operation" if !KUNIT_ALL_TESTS
2365 depends on KUNIT
2366 depends on MMU
2367 default KUNIT_ALL_TESTS
2368 help
2369 Enable this to turn on testing of the operation of the I/O iterator
2370 (iov_iter). This test is executed only once during system boot (so
2371 affects only boot time), or at module load time.
2372
2373 If unsure, say N.
2374
2375config KPROBES_SANITY_TEST
2376 tristate "Kprobes sanity tests" if !KUNIT_ALL_TESTS
2377 depends on DEBUG_KERNEL
2378 depends on KPROBES
2379 depends on KUNIT
2380 select STACKTRACE if ARCH_CORRECT_STACKTRACE_ON_KRETPROBE
2381 default KUNIT_ALL_TESTS
2382 help
2383 This option provides for testing basic kprobes functionality on
2384 boot. Samples of kprobe and kretprobe are inserted and
2385 verified for functionality.
2386
2387 Say N if you are unsure.
2388
2389config FPROBE_SANITY_TEST
2390 bool "Self test for fprobe"
2391 depends on DEBUG_KERNEL
2392 depends on FPROBE
2393 depends on KUNIT=y
2394 help
2395 This option will enable testing the fprobe when the system boot.
2396 A series of tests are made to verify that the fprobe is functioning
2397 properly.
2398
2399 Say N if you are unsure.
2400
2401config BACKTRACE_SELF_TEST
2402 tristate "Self test for the backtrace code"
2403 depends on DEBUG_KERNEL
2404 help
2405 This option provides a kernel module that can be used to test
2406 the kernel stack backtrace code. This option is not useful
2407 for distributions or general kernels, but only for kernel
2408 developers working on architecture code.
2409
2410 Note that if you want to also test saved backtraces, you will
2411 have to enable STACKTRACE as well.
2412
2413 Say N if you are unsure.
2414
2415config TEST_REF_TRACKER
2416 tristate "Self test for reference tracker"
2417 depends on DEBUG_KERNEL && STACKTRACE_SUPPORT
2418 select REF_TRACKER
2419 help
2420 This option provides a kernel module performing tests
2421 using reference tracker infrastructure.
2422
2423 Say N if you are unsure.
2424
2425config RBTREE_TEST
2426 tristate "Red-Black tree test"
2427 depends on DEBUG_KERNEL
2428 help
2429 A benchmark measuring the performance of the rbtree library.
2430 Also includes rbtree invariant checks.
2431
2432config REED_SOLOMON_TEST
2433 tristate "Reed-Solomon library test"
2434 depends on DEBUG_KERNEL || m
2435 select REED_SOLOMON
2436 select REED_SOLOMON_ENC16
2437 select REED_SOLOMON_DEC16
2438 help
2439 This option enables the self-test function of rslib at boot,
2440 or at module load time.
2441
2442 If unsure, say N.
2443
2444config INTERVAL_TREE_TEST
2445 tristate "Interval tree test"
2446 depends on DEBUG_KERNEL
2447 select INTERVAL_TREE
2448 help
2449 A benchmark measuring the performance of the interval tree library
2450
2451config PERCPU_TEST
2452 tristate "Per cpu operations test"
2453 depends on m && DEBUG_KERNEL
2454 help
2455 Enable this option to build test module which validates per-cpu
2456 operations.
2457
2458 If unsure, say N.
2459
2460config ATOMIC64_SELFTEST
2461 tristate "Perform an atomic64_t self-test"
2462 help
2463 Enable this option to test the atomic64_t functions at boot or
2464 at module load time.
2465
2466 If unsure, say N.
2467
2468config ASYNC_RAID6_TEST
2469 tristate "Self test for hardware accelerated raid6 recovery"
2470 depends on ASYNC_RAID6_RECOV
2471 select ASYNC_MEMCPY
2472 help
2473 This is a one-shot self test that permutes through the
2474 recovery of all the possible two disk failure scenarios for a
2475 N-disk array. Recovery is performed with the asynchronous
2476 raid6 recovery routines, and will optionally use an offload
2477 engine if one is available.
2478
2479 If unsure, say N.
2480
2481config TEST_HEXDUMP
2482 tristate "Test functions located in the hexdump module at runtime"
2483
2484config PRINTF_KUNIT_TEST
2485 tristate "KUnit test printf() family of functions at runtime" if !KUNIT_ALL_TESTS
2486 depends on KUNIT
2487 default KUNIT_ALL_TESTS
2488 help
2489 Enable this option to test the printf functions at runtime.
2490
2491 If unsure, say N.
2492
2493config SCANF_KUNIT_TEST
2494 tristate "KUnit test scanf() family of functions at runtime" if !KUNIT_ALL_TESTS
2495 depends on KUNIT
2496 default KUNIT_ALL_TESTS
2497 help
2498 Enable this option to test the scanf functions at runtime.
2499
2500 If unsure, say N.
2501
2502config SEQ_BUF_KUNIT_TEST
2503 tristate "KUnit test for seq_buf" if !KUNIT_ALL_TESTS
2504 depends on KUNIT
2505 default KUNIT_ALL_TESTS
2506 help
2507 This builds unit tests for the seq_buf library.
2508
2509 If unsure, say N.
2510
2511config STRING_KUNIT_TEST
2512 tristate "KUnit test string functions at runtime" if !KUNIT_ALL_TESTS
2513 depends on KUNIT
2514 default KUNIT_ALL_TESTS
2515
2516config STRING_HELPERS_KUNIT_TEST
2517 tristate "KUnit test string helpers at runtime" if !KUNIT_ALL_TESTS
2518 depends on KUNIT
2519 default KUNIT_ALL_TESTS
2520
2521config FFS_KUNIT_TEST
2522 tristate "KUnit test ffs-family functions at runtime" if !KUNIT_ALL_TESTS
2523 depends on KUNIT
2524 default KUNIT_ALL_TESTS
2525 help
2526 This builds KUnit tests for ffs-family bit manipulation functions
2527 including ffs(), __ffs(), fls(), __fls(), fls64(), and __ffs64().
2528
2529 These tests validate mathematical correctness, edge case handling,
2530 and cross-architecture consistency of bit scanning functions.
2531
2532 For more information on KUnit and unit tests in general,
2533 please refer to Documentation/dev-tools/kunit/.
2534
2535config TEST_KSTRTOX
2536 tristate "Test kstrto*() family of functions at runtime"
2537
2538config TEST_BITMAP
2539 tristate "Test bitmap_*() family of functions at runtime"
2540 help
2541 Enable this option to test the bitmap functions at boot.
2542
2543 If unsure, say N.
2544
2545config TEST_XARRAY
2546 tristate "Test the XArray code at runtime"
2547
2548config TEST_MAPLE_TREE
2549 tristate "Test the Maple Tree code at runtime or module load"
2550 help
2551 Enable this option to test the maple tree code functions at boot, or
2552 when the module is loaded. Enable "Debug Maple Trees" will enable
2553 more verbose output on failures.
2554
2555 If unsure, say N.
2556
2557config TEST_RHASHTABLE
2558 tristate "Perform selftest on resizable hash table"
2559 help
2560 Enable this option to test the rhashtable functions at boot.
2561
2562 If unsure, say N.
2563
2564config TEST_IDA
2565 tristate "Perform selftest on IDA functions"
2566
2567config TEST_MISC_MINOR
2568 bool "miscdevice KUnit test" if !KUNIT_ALL_TESTS
2569 depends on KUNIT=y
2570 default KUNIT_ALL_TESTS
2571 help
2572 Kunit test for miscdevice API, specially its behavior in respect to
2573 static and dynamic minor numbers.
2574
2575 KUnit tests run during boot and output the results to the debug log
2576 in TAP format (https://testanything.org/). Only useful for kernel devs
2577 running the KUnit test harness, and not intended for inclusion into a
2578 production build.
2579
2580 For more information on KUnit and unit tests in general please refer
2581 to the KUnit documentation in Documentation/dev-tools/kunit/.
2582
2583 If unsure, say N.
2584
2585config TEST_PARMAN
2586 tristate "Perform selftest on priority array manager"
2587 depends on PARMAN
2588 help
2589 Enable this option to test priority array manager on boot
2590 (or module load).
2591
2592 If unsure, say N.
2593
2594config TEST_LKM
2595 tristate "Test module loading with 'hello world' module"
2596 depends on m
2597 help
2598 This builds the "test_module" module that emits "Hello, world"
2599 on printk when loaded. It is designed to be used for basic
2600 evaluation of the module loading subsystem (for example when
2601 validating module verification). It lacks any extra dependencies,
2602 and will not normally be loaded by the system unless explicitly
2603 requested by name.
2604
2605 If unsure, say N.
2606
2607config TEST_BITOPS
2608 tristate "Test module for compilation of bitops operations"
2609 help
2610 This builds the "test_bitops" module that is much like the
2611 TEST_LKM module except that it does a basic exercise of the
2612 set/clear_bit macros and get_count_order/long to make sure there are
2613 no compiler warnings from C=1 sparse checker or -Wextra
2614 compilations. It has no dependencies and doesn't run or load unless
2615 explicitly requested by name. for example: modprobe test_bitops.
2616
2617 If unsure, say N.
2618
2619config TEST_VMALLOC
2620 tristate "Test module for stress/performance analysis of vmalloc allocator"
2621 default n
2622 depends on MMU
2623 help
2624 This builds the "test_vmalloc" module that should be used for
2625 stress and performance analysis. So, any new change for vmalloc
2626 subsystem can be evaluated from performance and stability point
2627 of view.
2628
2629 If unsure, say N.
2630
2631config TEST_BPF
2632 tristate "Test BPF filter functionality"
2633 depends on m && NET
2634 help
2635 This builds the "test_bpf" module that runs various test vectors
2636 against the BPF interpreter or BPF JIT compiler depending on the
2637 current setting. This is in particular useful for BPF JIT compiler
2638 development, but also to run regression tests against changes in
2639 the interpreter code. It also enables test stubs for eBPF maps and
2640 verifier used by user space verifier testsuite.
2641
2642 If unsure, say N.
2643
2644config FIND_BIT_BENCHMARK
2645 tristate "Test find_bit functions"
2646 help
2647 This builds the "test_find_bit" module that measure find_*_bit()
2648 functions performance.
2649
2650 If unsure, say N.
2651
2652config FIND_BIT_BENCHMARK_RUST
2653 tristate "Test find_bit functions in Rust"
2654 depends on RUST
2655 help
2656 This builds the "find_bit_benchmark_rust" module. It is a micro
2657 benchmark that measures the performance of Rust functions that
2658 correspond to the find_*_bit() operations in C. It follows the
2659 FIND_BIT_BENCHMARK closely but will in general not yield same
2660 numbers due to extra bounds checks and overhead of foreign
2661 function calls.
2662
2663 If unsure, say N.
2664
2665config TEST_FIRMWARE
2666 tristate "Test firmware loading via userspace interface"
2667 depends on FW_LOADER
2668 help
2669 This builds the "test_firmware" module that creates a userspace
2670 interface for testing firmware loading. This can be used to
2671 control the triggering of firmware loading without needing an
2672 actual firmware-using device. The contents can be rechecked by
2673 userspace.
2674
2675 If unsure, say N.
2676
2677config TEST_SYSCTL
2678 tristate "sysctl test driver"
2679 depends on PROC_SYSCTL
2680 help
2681 This builds the "test_sysctl" module. This driver enables to test the
2682 proc sysctl interfaces available to drivers safely without affecting
2683 production knobs which might alter system functionality.
2684
2685 If unsure, say N.
2686
2687config BITOPS_KUNIT
2688 tristate "KUnit test for bitops" if !KUNIT_ALL_TESTS
2689 depends on KUNIT
2690 default KUNIT_ALL_TESTS
2691 help
2692 This option enables the KUnit test for the bitops library
2693 which provides functions for bit operations.
2694
2695 Note that this is derived from the original test_bitops module.
2696 For micro-benchmarks and compiler warning checks, enable TEST_BITOPS.
2697
2698 If unsure, say N.
2699
2700config BITFIELD_KUNIT
2701 tristate "KUnit test bitfield functions at runtime" if !KUNIT_ALL_TESTS
2702 depends on KUNIT
2703 default KUNIT_ALL_TESTS
2704 help
2705 Enable this option to test the bitfield functions at boot.
2706
2707 KUnit tests run during boot and output the results to the debug log
2708 in TAP format (http://testanything.org/). Only useful for kernel devs
2709 running the KUnit test harness, and not intended for inclusion into a
2710 production build.
2711
2712 For more information on KUnit and unit tests in general please refer
2713 to the KUnit documentation in Documentation/dev-tools/kunit/.
2714
2715 If unsure, say N.
2716
2717config CHECKSUM_KUNIT
2718 tristate "KUnit test checksum functions at runtime" if !KUNIT_ALL_TESTS
2719 depends on KUNIT
2720 default KUNIT_ALL_TESTS
2721 help
2722 Enable this option to test the checksum functions at boot.
2723
2724 KUnit tests run during boot and output the results to the debug log
2725 in TAP format (http://testanything.org/). Only useful for kernel devs
2726 running the KUnit test harness, and not intended for inclusion into a
2727 production build.
2728
2729 For more information on KUnit and unit tests in general please refer
2730 to the KUnit documentation in Documentation/dev-tools/kunit/.
2731
2732 If unsure, say N.
2733
2734config UTIL_MACROS_KUNIT
2735 tristate "KUnit test util_macros.h functions at runtime" if !KUNIT_ALL_TESTS
2736 depends on KUNIT
2737 default KUNIT_ALL_TESTS
2738 help
2739 Enable this option to test the util_macros.h function at boot.
2740
2741 KUnit tests run during boot and output the results to the debug log
2742 in TAP format (http://testanything.org/). Only useful for kernel devs
2743 running the KUnit test harness, and not intended for inclusion into a
2744 production build.
2745
2746 For more information on KUnit and unit tests in general please refer
2747 to the KUnit documentation in Documentation/dev-tools/kunit/.
2748
2749 If unsure, say N.
2750
2751config HASH_KUNIT_TEST
2752 tristate "KUnit Test for integer hash functions" if !KUNIT_ALL_TESTS
2753 depends on KUNIT
2754 default KUNIT_ALL_TESTS
2755 help
2756 Enable this option to test the kernel's string (<linux/stringhash.h>), and
2757 integer (<linux/hash.h>) hash functions on boot.
2758
2759 KUnit tests run during boot and output the results to the debug log
2760 in TAP format (https://testanything.org/). Only useful for kernel devs
2761 running the KUnit test harness, and not intended for inclusion into a
2762 production build.
2763
2764 For more information on KUnit and unit tests in general please refer
2765 to the KUnit documentation in Documentation/dev-tools/kunit/.
2766
2767 This is intended to help people writing architecture-specific
2768 optimized versions. If unsure, say N.
2769
2770config RESOURCE_KUNIT_TEST
2771 tristate "KUnit test for resource API" if !KUNIT_ALL_TESTS
2772 depends on KUNIT
2773 default KUNIT_ALL_TESTS
2774 select GET_FREE_REGION
2775 help
2776 This builds the resource API unit test.
2777 Tests the logic of API provided by resource.c and ioport.h.
2778 For more information on KUnit and unit tests in general please refer
2779 to the KUnit documentation in Documentation/dev-tools/kunit/.
2780
2781 If unsure, say N.
2782
2783config SYSCTL_KUNIT_TEST
2784 tristate "KUnit test for sysctl" if !KUNIT_ALL_TESTS
2785 depends on KUNIT
2786 default KUNIT_ALL_TESTS
2787 help
2788 This builds the proc sysctl unit test, which runs on boot.
2789 Tests the API contract and implementation correctness of sysctl.
2790 For more information on KUnit and unit tests in general please refer
2791 to the KUnit documentation in Documentation/dev-tools/kunit/.
2792
2793 If unsure, say N.
2794
2795config KFIFO_KUNIT_TEST
2796 tristate "KUnit Test for the generic kernel FIFO implementation" if !KUNIT_ALL_TESTS
2797 depends on KUNIT
2798 default KUNIT_ALL_TESTS
2799 help
2800 This builds the generic FIFO implementation KUnit test suite.
2801 It tests that the API and basic functionality of the kfifo type
2802 and associated macros.
2803
2804 For more information on KUnit and unit tests in general please refer
2805 to the KUnit documentation in Documentation/dev-tools/kunit/.
2806
2807 If unsure, say N.
2808
2809config LIST_KUNIT_TEST
2810 tristate "KUnit Test for Kernel Linked-list structures" if !KUNIT_ALL_TESTS
2811 depends on KUNIT
2812 default KUNIT_ALL_TESTS
2813 help
2814 This builds the linked list KUnit test suite.
2815 It tests that the API and basic functionality of the list_head type
2816 and associated macros.
2817
2818 KUnit tests run during boot and output the results to the debug log
2819 in TAP format (https://testanything.org/). Only useful for kernel devs
2820 running the KUnit test harness, and not intended for inclusion into a
2821 production build.
2822
2823 For more information on KUnit and unit tests in general please refer
2824 to the KUnit documentation in Documentation/dev-tools/kunit/.
2825
2826 If unsure, say N.
2827
2828config LIST_PRIVATE_KUNIT_TEST
2829 tristate "KUnit Test for Kernel Private Linked-list structures" if !KUNIT_ALL_TESTS
2830 depends on KUNIT
2831 default KUNIT_ALL_TESTS
2832 help
2833 This builds the KUnit test for the private linked-list primitives
2834 defined in include/linux/list_private.h.
2835
2836 These primitives allow manipulation of list_head members that are
2837 marked as private and require special accessors (ACCESS_PRIVATE)
2838 to strip qualifiers or handle encapsulation.
2839
2840 If unsure, say N.
2841
2842config HASHTABLE_KUNIT_TEST
2843 tristate "KUnit Test for Kernel Hashtable structures" if !KUNIT_ALL_TESTS
2844 depends on KUNIT
2845 default KUNIT_ALL_TESTS
2846 help
2847 This builds the hashtable KUnit test suite.
2848 It tests the basic functionality of the API defined in
2849 include/linux/hashtable.h. For more information on KUnit and
2850 unit tests in general please refer to the KUnit documentation
2851 in Documentation/dev-tools/kunit/.
2852
2853 If unsure, say N.
2854
2855config LINEAR_RANGES_TEST
2856 tristate "KUnit test for linear_ranges"
2857 depends on KUNIT
2858 select LINEAR_RANGES
2859 help
2860 This builds the linear_ranges unit test, which runs on boot.
2861 Tests the linear_ranges logic correctness.
2862 For more information on KUnit and unit tests in general please refer
2863 to the KUnit documentation in Documentation/dev-tools/kunit/.
2864
2865 If unsure, say N.
2866
2867config CONTEXT_ANALYSIS_TEST
2868 bool "Compiler context-analysis warnings test"
2869 depends on EXPERT
2870 help
2871 This builds the test for compiler-based context analysis. The test
2872 does not add executable code to the kernel, but is meant to test that
2873 common patterns supported by the analysis do not result in false
2874 positive warnings.
2875
2876 When adding support for new context locks, it is strongly recommended
2877 to add supported patterns to this test.
2878
2879 If unsure, say N.
2880
2881config LIVEUPDATE_TEST
2882 bool "Live Update Kernel Test"
2883 default n
2884 depends on LIVEUPDATE
2885 help
2886 Enable a built-in kernel test module for the Live Update
2887 Orchestrator.
2888
2889 This module validates the File-Lifecycle-Bound subsystem by
2890 registering a set of mock FLB objects with any real file handlers
2891 that support live update (such as the memfd handler).
2892
2893 When live update operations are performed, this test module will
2894 output messages to the kernel log (dmesg), confirming that its
2895 registration and various callback functions (preserve, retrieve,
2896 finish, etc.) are being invoked correctly.
2897
2898 This is a debugging and regression testing tool for developers
2899 working on the Live Update subsystem. It should not be enabled in
2900 production kernels.
2901
2902 If unsure, say N
2903
2904config CMDLINE_KUNIT_TEST
2905 tristate "KUnit test for cmdline API" if !KUNIT_ALL_TESTS
2906 depends on KUNIT
2907 default KUNIT_ALL_TESTS
2908 help
2909 This builds the cmdline API unit test.
2910 Tests the logic of API provided by cmdline.c.
2911 For more information on KUnit and unit tests in general please refer
2912 to the KUnit documentation in Documentation/dev-tools/kunit/.
2913
2914 If unsure, say N.
2915
2916config BASE64_KUNIT
2917 tristate "KUnit test for base64 decoding and encoding" if !KUNIT_ALL_TESTS
2918 depends on KUNIT
2919 default KUNIT_ALL_TESTS
2920 help
2921 This builds the base64 unit tests.
2922
2923 The tests cover the encoding and decoding logic of Base64 functions
2924 in the kernel.
2925 In addition to correctness checks, simple performance benchmarks
2926 for both encoding and decoding are also included.
2927
2928 For more information on KUnit and unit tests in general please refer
2929 to the KUnit documentation in Documentation/dev-tools/kunit/.
2930
2931 If unsure, say N.
2932
2933config BITS_TEST
2934 tristate "KUnit test for bit functions and macros" if !KUNIT_ALL_TESTS
2935 depends on KUNIT
2936 default KUNIT_ALL_TESTS
2937 help
2938 This builds the bits unit test.
2939 Tests the logic of macros defined in bits.h.
2940 For more information on KUnit and unit tests in general please refer
2941 to the KUnit documentation in Documentation/dev-tools/kunit/.
2942
2943 If unsure, say N.
2944
2945config SLUB_KUNIT_TEST
2946 tristate "KUnit test for SLUB cache error detection" if !KUNIT_ALL_TESTS
2947 depends on SLUB_DEBUG && KUNIT
2948 default KUNIT_ALL_TESTS
2949 help
2950 This builds SLUB allocator unit test.
2951 Tests SLUB cache debugging functionality.
2952 For more information on KUnit and unit tests in general please refer
2953 to the KUnit documentation in Documentation/dev-tools/kunit/.
2954
2955 If unsure, say N.
2956
2957config RATIONAL_KUNIT_TEST
2958 tristate "KUnit test for rational.c" if !KUNIT_ALL_TESTS
2959 depends on KUNIT && RATIONAL
2960 default KUNIT_ALL_TESTS
2961 help
2962 This builds the rational math unit test.
2963 For more information on KUnit and unit tests in general please refer
2964 to the KUnit documentation in Documentation/dev-tools/kunit/.
2965
2966 If unsure, say N.
2967
2968config MEMCPY_KUNIT_TEST
2969 tristate "Test memcpy(), memmove(), and memset() functions at runtime" if !KUNIT_ALL_TESTS
2970 depends on KUNIT
2971 default KUNIT_ALL_TESTS
2972 help
2973 Builds unit tests for memcpy(), memmove(), and memset() functions.
2974 For more information on KUnit and unit tests in general please refer
2975 to the KUnit documentation in Documentation/dev-tools/kunit/.
2976
2977 If unsure, say N.
2978
2979config MIN_HEAP_KUNIT_TEST
2980 tristate "Min heap test" if !KUNIT_ALL_TESTS
2981 depends on KUNIT
2982 default KUNIT_ALL_TESTS
2983 help
2984 This option enables the KUnit test suite for the min heap library
2985 which provides functions for creating and managing min heaps.
2986 The test suite checks the functionality of the min heap library.
2987
2988 If unsure, say N
2989
2990config IS_SIGNED_TYPE_KUNIT_TEST
2991 tristate "Test is_signed_type() macro" if !KUNIT_ALL_TESTS
2992 depends on KUNIT
2993 default KUNIT_ALL_TESTS
2994 help
2995 Builds unit tests for the is_signed_type() macro.
2996
2997 For more information on KUnit and unit tests in general please refer
2998 to the KUnit documentation in Documentation/dev-tools/kunit/.
2999
3000 If unsure, say N.
3001
3002config OVERFLOW_KUNIT_TEST
3003 tristate "Test check_*_overflow() functions at runtime" if !KUNIT_ALL_TESTS
3004 depends on KUNIT
3005 default KUNIT_ALL_TESTS
3006 help
3007 Builds unit tests for the check_*_overflow(), size_*(), allocation, and
3008 related functions.
3009
3010 For more information on KUnit and unit tests in general please refer
3011 to the KUnit documentation in Documentation/dev-tools/kunit/.
3012
3013 If unsure, say N.
3014
3015config RANDSTRUCT_KUNIT_TEST
3016 tristate "Test randstruct structure layout randomization at runtime" if !KUNIT_ALL_TESTS
3017 depends on KUNIT
3018 default KUNIT_ALL_TESTS
3019 help
3020 Builds unit tests for the checking CONFIG_RANDSTRUCT=y, which
3021 randomizes structure layouts.
3022
3023config STACKINIT_KUNIT_TEST
3024 tristate "Test level of stack variable initialization" if !KUNIT_ALL_TESTS
3025 depends on KUNIT
3026 default KUNIT_ALL_TESTS
3027 help
3028 Test if the kernel is zero-initializing stack variables and
3029 padding. Coverage is controlled by compiler flags,
3030 CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_ALL_ZERO.
3031
3032config FORTIFY_KUNIT_TEST
3033 tristate "Test fortified str*() and mem*() function internals at runtime" if !KUNIT_ALL_TESTS
3034 depends on KUNIT
3035 default KUNIT_ALL_TESTS
3036 help
3037 Builds unit tests for checking internals of FORTIFY_SOURCE as used
3038 by the str*() and mem*() family of functions. For testing runtime
3039 traps of FORTIFY_SOURCE, see LKDTM's "FORTIFY_*" tests.
3040
3041config LONGEST_SYM_KUNIT_TEST
3042 tristate "Test the longest symbol possible" if !KUNIT_ALL_TESTS
3043 depends on KUNIT && KPROBES
3044 depends on !PREFIX_SYMBOLS && !CFI && !GCOV_KERNEL
3045 default KUNIT_ALL_TESTS
3046 help
3047 Tests the longest symbol possible
3048
3049 If unsure, say N.
3050
3051config HW_BREAKPOINT_KUNIT_TEST
3052 bool "Test hw_breakpoint constraints accounting" if !KUNIT_ALL_TESTS
3053 depends on HAVE_HW_BREAKPOINT
3054 depends on KUNIT=y
3055 default KUNIT_ALL_TESTS
3056 help
3057 Tests for hw_breakpoint constraints accounting.
3058
3059 If unsure, say N.
3060
3061config SIPHASH_KUNIT_TEST
3062 tristate "Perform selftest on siphash functions" if !KUNIT_ALL_TESTS
3063 depends on KUNIT
3064 default KUNIT_ALL_TESTS
3065 help
3066 Enable this option to test the kernel's siphash (<linux/siphash.h>) hash
3067 functions on boot (or module load).
3068
3069 This is intended to help people writing architecture-specific
3070 optimized versions. If unsure, say N.
3071
3072config USERCOPY_KUNIT_TEST
3073 tristate "KUnit Test for user/kernel boundary protections"
3074 depends on KUNIT
3075 default KUNIT_ALL_TESTS
3076 help
3077 This builds the "usercopy_kunit" module that runs sanity checks
3078 on the copy_to/from_user infrastructure, making sure basic
3079 user/kernel boundary testing is working.
3080
3081config BLACKHOLE_DEV_KUNIT_TEST
3082 tristate "Test blackhole netdev functionality" if !KUNIT_ALL_TESTS
3083 depends on NET
3084 depends on KUNIT
3085 default KUNIT_ALL_TESTS
3086 help
3087 This builds the "blackhole_dev_kunit" module that validates the
3088 data path through this blackhole netdev.
3089
3090 If unsure, say N.
3091
3092config TEST_UDELAY
3093 tristate "udelay test driver"
3094 help
3095 This builds the "udelay_test" module that helps to make sure
3096 that udelay() is working properly.
3097
3098 If unsure, say N.
3099
3100config TEST_STATIC_KEYS
3101 tristate "Test static keys"
3102 depends on m
3103 help
3104 Test the static key interfaces.
3105
3106 If unsure, say N.
3107
3108config TEST_DYNAMIC_DEBUG
3109 tristate "Test DYNAMIC_DEBUG"
3110 depends on DYNAMIC_DEBUG
3111 help
3112 This module registers a tracer callback to count enabled
3113 pr_debugs in a 'do_debugging' function, then alters their
3114 enablements, calls the function, and compares counts.
3115
3116 If unsure, say N.
3117
3118config TEST_KMOD
3119 tristate "kmod stress tester"
3120 depends on m
3121 select TEST_LKM
3122 help
3123 Test the kernel's module loading mechanism: kmod. kmod implements
3124 support to load modules using the Linux kernel's usermode helper.
3125 This test provides a series of tests against kmod.
3126
3127 Although technically you can either build test_kmod as a module or
3128 into the kernel we disallow building it into the kernel since
3129 it stress tests request_module() and this will very likely cause
3130 some issues by taking over precious threads available from other
3131 module load requests, ultimately this could be fatal.
3132
3133 To run tests run:
3134
3135 tools/testing/selftests/kmod/kmod.sh --help
3136
3137 If unsure, say N.
3138
3139config TEST_RUNTIME
3140 bool
3141
3142config TEST_RUNTIME_MODULE
3143 bool
3144
3145config TEST_KALLSYMS
3146 tristate "module kallsyms find_symbol() test"
3147 depends on m
3148 select TEST_RUNTIME
3149 select TEST_RUNTIME_MODULE
3150 select TEST_KALLSYMS_A
3151 select TEST_KALLSYMS_B
3152 select TEST_KALLSYMS_C
3153 select TEST_KALLSYMS_D
3154 help
3155 This allows us to stress test find_symbol() through the kallsyms
3156 used to place symbols on the kernel ELF kallsyms and modules kallsyms
3157 where we place kernel symbols such as exported symbols.
3158
3159 We have four test modules:
3160
3161 A: has KALLSYSMS_NUMSYMS exported symbols
3162 B: uses one of A's symbols
3163 C: adds KALLSYMS_SCALE_FACTOR * KALLSYSMS_NUMSYMS exported
3164 D: adds 2 * the symbols than C
3165
3166 We stress test find_symbol() through two means:
3167
3168 1) Upon load of B it will trigger simplify_symbols() to look for the
3169 one symbol it uses from the module A with tons of symbols. This is an
3170 indirect way for us to have B call resolve_symbol_wait() upon module
3171 load. This will eventually call find_symbol() which will eventually
3172 try to find the symbols used with find_exported_symbol_in_section().
3173 find_exported_symbol_in_section() uses bsearch() so a binary search
3174 for each symbol. Binary search will at worst be O(log(n)) so the
3175 larger TEST_MODULE_KALLSYSMS the worse the search.
3176
3177 2) The selftests should load C first, before B. Upon B's load towards
3178 the end right before we call module B's init routine we get
3179 complete_formation() called on the module. That will first check
3180 for duplicate symbols with the call to verify_exported_symbols().
3181 That is when we'll force iteration on module C's insane symbol list.
3182 Since it has 10 * KALLSYMS_NUMSYMS it means we can first test
3183 just loading B without C. The amount of time it takes to load C Vs
3184 B can give us an idea of the impact growth of the symbol space and
3185 give us projection. Module A only uses one symbol from B so to allow
3186 this scaling in module C to be proportional, if it used more symbols
3187 then the first test would be doing more and increasing just the
3188 search space would be slightly different. The last module, module D
3189 will just increase the search space by twice the number of symbols in
3190 C so to allow for full projects.
3191
3192 tools/testing/selftests/module/find_symbol.sh
3193
3194 The current defaults will incur a build delay of about 7 minutes
3195 on an x86_64 with only 8 cores. Enable this only if you want to
3196 stress test find_symbol() with thousands of symbols. At the same
3197 time this is also useful to test building modules with thousands of
3198 symbols, and if BTF is enabled this also stress tests adding BTF
3199 information for each module. Currently enabling many more symbols
3200 will segfault the build system.
3201
3202 If unsure, say N.
3203
3204if TEST_KALLSYMS
3205
3206config TEST_KALLSYMS_A
3207 tristate
3208 depends on m
3209
3210config TEST_KALLSYMS_B
3211 tristate
3212 depends on m
3213
3214config TEST_KALLSYMS_C
3215 tristate
3216 depends on m
3217
3218config TEST_KALLSYMS_D
3219 tristate
3220 depends on m
3221
3222choice
3223 prompt "Kallsym test range"
3224 default TEST_KALLSYMS_LARGE
3225 help
3226 Selecting something other than "Fast" will enable tests which slow
3227 down the build and may crash your build.
3228
3229config TEST_KALLSYMS_FAST
3230 bool "Fast builds"
3231 help
3232 You won't really be testing kallsysms, so this just helps fast builds
3233 when allmodconfig is used..
3234
3235config TEST_KALLSYMS_LARGE
3236 bool "Enable testing kallsyms with large exports"
3237 help
3238 This will enable larger number of symbols. This will slow down
3239 your build considerably.
3240
3241config TEST_KALLSYMS_MAX
3242 bool "Known kallsysms limits"
3243 help
3244 This will enable exports to the point we know we'll start crashing
3245 builds.
3246
3247endchoice
3248
3249config TEST_KALLSYMS_NUMSYMS
3250 int "test kallsyms number of symbols"
3251 range 2 10000
3252 default 2 if TEST_KALLSYMS_FAST
3253 default 100 if TEST_KALLSYMS_LARGE
3254 default 10000 if TEST_KALLSYMS_MAX
3255 help
3256 The number of symbols to create on TEST_KALLSYMS_A, only one of which
3257 module TEST_KALLSYMS_B will use. This also will be used
3258 for how many symbols TEST_KALLSYMS_C will have, scaled up by
3259 TEST_KALLSYMS_SCALE_FACTOR. Note that setting this to 10,000 will
3260 trigger a segfault today, don't use anything close to it unless
3261 you are aware that this should not be used for automated build tests.
3262
3263config TEST_KALLSYMS_SCALE_FACTOR
3264 int "test kallsyms scale factor"
3265 default 8
3266 help
3267 How many more unusued symbols will TEST_KALLSYSMS_C have than
3268 TEST_KALLSYMS_A. If 8, then module C will have 8 * syms
3269 than module A. Then TEST_KALLSYMS_D will have double the amount
3270 of symbols than C so to allow projections.
3271
3272endif # TEST_KALLSYMS
3273
3274config TEST_DEBUG_VIRTUAL
3275 tristate "Test CONFIG_DEBUG_VIRTUAL feature"
3276 depends on DEBUG_VIRTUAL
3277 help
3278 Test the kernel's ability to detect incorrect calls to
3279 virt_to_phys() done against the non-linear part of the
3280 kernel's virtual address map.
3281
3282 If unsure, say N.
3283
3284config TEST_MEMCAT_P
3285 tristate "Test memcat_p() helper function"
3286 help
3287 Test the memcat_p() helper for correctly merging two
3288 pointer arrays together.
3289
3290 If unsure, say N.
3291
3292config TEST_OBJAGG
3293 tristate "Perform selftest on object aggreration manager"
3294 default n
3295 depends on OBJAGG
3296 help
3297 Enable this option to test object aggregation manager on boot
3298 (or module load).
3299
3300config TEST_MEMINIT
3301 tristate "Test heap/page initialization"
3302 help
3303 Test if the kernel is zero-initializing heap and page allocations.
3304 This can be useful to test init_on_alloc and init_on_free features.
3305
3306 If unsure, say N.
3307
3308config TEST_HMM
3309 tristate "Test HMM (Heterogeneous Memory Management)"
3310 depends on TRANSPARENT_HUGEPAGE
3311 depends on DEVICE_PRIVATE
3312 select HMM_MIRROR
3313 select MMU_NOTIFIER
3314 help
3315 This is a pseudo device driver solely for testing HMM.
3316 Say M here if you want to build the HMM test module.
3317 Doing so will allow you to run tools/testing/selftest/vm/hmm-tests.
3318
3319 If unsure, say N.
3320
3321config TEST_FREE_PAGES
3322 tristate "Test freeing pages"
3323 help
3324 Test that a memory leak does not occur due to a race between
3325 freeing a block of pages and a speculative page reference.
3326 Loading this module is safe if your kernel has the bug fixed.
3327 If the bug is not fixed, it will leak gigabytes of memory and
3328 probably OOM your system.
3329
3330config TEST_FPU
3331 tristate "Test floating point operations in kernel space"
3332 depends on ARCH_HAS_KERNEL_FPU_SUPPORT && !KCOV_INSTRUMENT_ALL
3333 help
3334 Enable this option to add /sys/kernel/debug/selftest_helpers/test_fpu
3335 which will trigger a sequence of floating point operations. This is used
3336 for self-testing floating point control register setting in
3337 kernel_fpu_begin().
3338
3339 If unsure, say N.
3340
3341config TEST_CLOCKSOURCE_WATCHDOG
3342 tristate "Test clocksource watchdog in kernel space"
3343 depends on CLOCKSOURCE_WATCHDOG
3344 help
3345 Enable this option to create a kernel module that will trigger
3346 a test of the clocksource watchdog. This module may be loaded
3347 via modprobe or insmod in which case it will run upon being
3348 loaded, or it may be built in, in which case it will run
3349 shortly after boot.
3350
3351 If unsure, say N.
3352
3353config TEST_OBJPOOL
3354 tristate "Test module for correctness and stress of objpool"
3355 default n
3356 depends on m && DEBUG_KERNEL
3357 help
3358 This builds the "test_objpool" module that should be used for
3359 correctness verification and concurrent testings of objects
3360 allocation and reclamation.
3361
3362 If unsure, say N.
3363
3364config TEST_KEXEC_HANDOVER
3365 bool "Test for Kexec HandOver"
3366 default n
3367 depends on KEXEC_HANDOVER
3368 help
3369 This option enables test for Kexec HandOver (KHO).
3370 The test consists of two parts: saving kernel data before kexec and
3371 restoring the data after kexec and verifying that it was properly
3372 handed over. This test module creates and saves data on the boot of
3373 the first kernel and restores and verifies the data on the boot of
3374 kexec'ed kernel.
3375
3376 For detailed documentation about KHO, see Documentation/core-api/kho.
3377
3378 To run the test run:
3379
3380 tools/testing/selftests/kho/vmtest.sh -h
3381
3382 If unsure, say N.
3383
3384config RATELIMIT_KUNIT_TEST
3385 tristate "KUnit Test for correctness and stress of ratelimit" if !KUNIT_ALL_TESTS
3386 depends on KUNIT
3387 default KUNIT_ALL_TESTS
3388 help
3389 This builds the "test_ratelimit" module that should be used
3390 for correctness verification and concurrent testings of rate
3391 limiting.
3392
3393 If unsure, say N.
3394
3395config UUID_KUNIT_TEST
3396 tristate "KUnit test for UUID" if !KUNIT_ALL_TESTS
3397 depends on KUNIT
3398 default KUNIT_ALL_TESTS
3399 help
3400 This option enables the KUnit test suite for the uuid library,
3401 which provides functions for generating and parsing UUID and GUID.
3402 The test suite checks parsing of UUID and GUID strings.
3403
3404 If unsure, say N.
3405
3406config INT_POW_KUNIT_TEST
3407 tristate "Integer exponentiation (int_pow) test" if !KUNIT_ALL_TESTS
3408 depends on KUNIT
3409 default KUNIT_ALL_TESTS
3410 help
3411 This option enables the KUnit test suite for the int_pow function,
3412 which performs integer exponentiation. The test suite is designed to
3413 verify that the implementation of int_pow correctly computes the power
3414 of a given base raised to a given exponent.
3415
3416 Enabling this option will include tests that check various scenarios
3417 and edge cases to ensure the accuracy and reliability of the exponentiation
3418 function.
3419
3420 If unsure, say N
3421
3422config INT_SQRT_KUNIT_TEST
3423 tristate "Integer square root test" if !KUNIT_ALL_TESTS
3424 depends on KUNIT
3425 default KUNIT_ALL_TESTS
3426 help
3427 This option enables the KUnit test suite for the int_sqrt() function,
3428 which performs square root calculation. The test suite checks
3429 various scenarios, including edge cases, to ensure correctness.
3430
3431 Enabling this option will include tests that check various scenarios
3432 and edge cases to ensure the accuracy and reliability of the square root
3433 function.
3434
3435 If unsure, say N
3436
3437config INT_LOG_KUNIT_TEST
3438 tristate "Integer log (int_log) test" if !KUNIT_ALL_TESTS
3439 depends on KUNIT
3440 default KUNIT_ALL_TESTS
3441 help
3442 This option enables the KUnit test suite for the int_log library, which
3443 provides two functions to compute the integer logarithm in base 2 and
3444 base 10, called respectively as intlog2 and intlog10.
3445
3446 If unsure, say N
3447
3448config GCD_KUNIT_TEST
3449 tristate "Greatest common divisor test" if !KUNIT_ALL_TESTS
3450 depends on KUNIT
3451 default KUNIT_ALL_TESTS
3452 help
3453 This option enables the KUnit test suite for the gcd() function,
3454 which computes the greatest common divisor of two numbers.
3455
3456 This test suite verifies the correctness of gcd() across various
3457 scenarios, including edge cases.
3458
3459 If unsure, say N
3460
3461config PRIME_NUMBERS_KUNIT_TEST
3462 tristate "Prime number generator test" if !KUNIT_ALL_TESTS
3463 depends on KUNIT
3464 depends on PRIME_NUMBERS
3465 default KUNIT_ALL_TESTS
3466 help
3467 This option enables the KUnit test suite for the {is,next}_prime_number
3468 functions.
3469
3470 Enabling this option will include tests that compare the prime number
3471 generator functions against a brute force implementation.
3472
3473 If unsure, say N
3474
3475config GLOB_KUNIT_TEST
3476 tristate "Glob matching test" if !KUNIT_ALL_TESTS
3477 depends on GLOB
3478 depends on KUNIT
3479 default KUNIT_ALL_TESTS
3480 help
3481 Enable this option to test the glob functions at runtime.
3482
3483 This test suite verifies the correctness of glob_match() across various
3484 scenarios, including edge cases.
3485
3486 If unsure, say N
3487
3488endif # RUNTIME_TESTING_MENU
3489
3490config ARCH_USE_MEMTEST
3491 bool
3492 help
3493 An architecture should select this when it uses early_memtest()
3494 during boot process.
3495
3496config MEMTEST
3497 bool "Memtest"
3498 depends on ARCH_USE_MEMTEST
3499 help
3500 This option adds a kernel parameter 'memtest', which allows memtest
3501 to be set and executed.
3502 memtest=0, mean disabled; -- default
3503 memtest=1, mean do 1 test pattern;
3504 ...
3505 memtest=17, mean do 17 test patterns.
3506 If you are unsure how to answer this question, answer N.
3507
3508
3509
3510config HYPERV_TESTING
3511 bool "Microsoft Hyper-V driver testing"
3512 default n
3513 depends on HYPERV && DEBUG_FS
3514 help
3515 Select this option to enable Hyper-V vmbus testing.
3516
3517endmenu # "Kernel Testing and Coverage"
3518
3519menu "Rust hacking"
3520
3521config RUST_DEBUG_ASSERTIONS
3522 bool "Debug assertions"
3523 depends on RUST
3524 help
3525 Enables rustc's `-Cdebug-assertions` codegen option.
3526
3527 This flag lets you turn `cfg(debug_assertions)` conditional
3528 compilation on or off. This can be used to enable extra debugging
3529 code in development but not in production. For example, it controls
3530 the behavior of the standard library's `debug_assert!` macro.
3531
3532 Note that this will apply to all Rust code, including `core`.
3533
3534 If unsure, say N.
3535
3536config RUST_OVERFLOW_CHECKS
3537 bool "Overflow checks"
3538 default y
3539 depends on RUST
3540 help
3541 Enables rustc's `-Coverflow-checks` codegen option.
3542
3543 This flag allows you to control the behavior of runtime integer
3544 overflow. When overflow-checks are enabled, a Rust panic will occur
3545 on overflow.
3546
3547 Note that this will apply to all Rust code, including `core`.
3548
3549 If unsure, say Y.
3550
3551config RUST_BUILD_ASSERT_ALLOW
3552 bool "Allow unoptimized build-time assertions"
3553 depends on RUST
3554 help
3555 Controls how `build_error!` and `build_assert!` are handled during the build.
3556
3557 If calls to them exist in the binary, it may indicate a violated invariant
3558 or that the optimizer failed to verify the invariant during compilation.
3559
3560 This should not happen, thus by default the build is aborted. However,
3561 as an escape hatch, you can choose Y here to ignore them during build
3562 and let the check be carried at runtime (with `panic!` being called if
3563 the check fails).
3564
3565 If unsure, say N.
3566
3567config RUST_KERNEL_DOCTESTS
3568 bool "Doctests for the `kernel` crate" if !KUNIT_ALL_TESTS
3569 depends on RUST && KUNIT=y
3570 default KUNIT_ALL_TESTS
3571 help
3572 This builds the documentation tests of the `kernel` crate
3573 as KUnit tests.
3574
3575 For more information on KUnit and unit tests in general,
3576 please refer to the KUnit documentation in Documentation/dev-tools/kunit/.
3577
3578 If unsure, say N.
3579
3580endmenu # "Rust"
3581
3582endmenu # Kernel hacking