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 21 if KASAN
1622 default 19
1623 help
1624 Try increasing this value if you hit "BUG: MAX_STACK_TRACE_ENTRIES too low!" message.
1625
1626 KASAN significantly increases stack trace consumption because its
1627 slab tracking interacts with lockdep's dependency validation under
1628 PREEMPT_FULL, creating a feedback loop. The higher default when
1629 KASAN is enabled costs ~12MB extra, which is negligible compared to
1630 KASAN's own shadow memory overhead.
1631
1632config LOCKDEP_STACK_TRACE_HASH_BITS
1633 int "Size for STACK_TRACE_HASH_SIZE (as Nth power of 2)"
1634 depends on LOCKDEP && !LOCKDEP_SMALL
1635 range 10 26
1636 default 16 if KASAN
1637 default 14
1638 help
1639 Try increasing this value if you need large STACK_TRACE_HASH_SIZE.
1640
1641config LOCKDEP_CIRCULAR_QUEUE_BITS
1642 int "Size for elements in circular_queue struct (as Nth power of 2)"
1643 depends on LOCKDEP
1644 range 10 26
1645 default 12
1646 help
1647 Try increasing this value if you hit "lockdep bfs error:-1" warning due to __cq_enqueue() failure.
1648
1649config DEBUG_LOCKDEP
1650 bool "Lock dependency engine debugging"
1651 depends on DEBUG_KERNEL && LOCKDEP
1652 select DEBUG_IRQFLAGS
1653 help
1654 If you say Y here, the lock dependency engine will do
1655 additional runtime checks to debug itself, at the price
1656 of more runtime overhead.
1657
1658config DEBUG_ATOMIC_SLEEP
1659 bool "Sleep inside atomic section checking"
1660 select PREEMPT_COUNT
1661 depends on DEBUG_KERNEL
1662 depends on !ARCH_NO_PREEMPT
1663 help
1664 If you say Y here, various routines which may sleep will become very
1665 noisy if they are called inside atomic sections: when a spinlock is
1666 held, inside an rcu read side critical section, inside preempt disabled
1667 sections, inside an interrupt, etc...
1668
1669config DEBUG_LOCKING_API_SELFTESTS
1670 bool "Locking API boot-time self-tests"
1671 depends on DEBUG_KERNEL
1672 help
1673 Say Y here if you want the kernel to run a short self-test during
1674 bootup. The self-test checks whether common types of locking bugs
1675 are detected by debugging mechanisms or not. (if you disable
1676 lock debugging then those bugs won't be detected of course.)
1677 The following locking APIs are covered: spinlocks, rwlocks,
1678 mutexes and rwsems.
1679
1680config LOCK_TORTURE_TEST
1681 tristate "torture tests for locking"
1682 depends on DEBUG_KERNEL
1683 select TORTURE_TEST
1684 help
1685 This option provides a kernel module that runs torture tests
1686 on kernel locking primitives. The kernel module may be built
1687 after the fact on the running kernel to be tested, if desired.
1688
1689 Say Y here if you want kernel locking-primitive torture tests
1690 to be built into the kernel.
1691 Say M if you want these torture tests to build as a module.
1692 Say N if you are unsure.
1693
1694config WW_MUTEX_SELFTEST
1695 tristate "Wait/wound mutex selftests"
1696 help
1697 This option provides a kernel module that runs tests on the
1698 on the struct ww_mutex locking API.
1699
1700 It is recommended to enable DEBUG_WW_MUTEX_SLOWPATH in conjunction
1701 with this test harness.
1702
1703 Say M if you want these self tests to build as a module.
1704 Say N if you are unsure.
1705
1706config SCF_TORTURE_TEST
1707 tristate "torture tests for smp_call_function*()"
1708 depends on DEBUG_KERNEL
1709 select TORTURE_TEST
1710 help
1711 This option provides a kernel module that runs torture tests
1712 on the smp_call_function() family of primitives. The kernel
1713 module may be built after the fact on the running kernel to
1714 be tested, if desired.
1715
1716config CSD_LOCK_WAIT_DEBUG
1717 bool "Debugging for csd_lock_wait(), called from smp_call_function*()"
1718 depends on DEBUG_KERNEL
1719 depends on SMP
1720 depends on 64BIT
1721 default n
1722 help
1723 This option enables debug prints when CPUs are slow to respond
1724 to the smp_call_function*() IPI wrappers. These debug prints
1725 include the IPI handler function currently executing (if any)
1726 and relevant stack traces.
1727
1728config CSD_LOCK_WAIT_DEBUG_DEFAULT
1729 bool "Default csd_lock_wait() debugging on at boot time"
1730 depends on CSD_LOCK_WAIT_DEBUG
1731 depends on 64BIT
1732 default n
1733 help
1734 This option causes the csdlock_debug= kernel boot parameter to
1735 default to 1 (basic debugging) instead of 0 (no debugging).
1736
1737endmenu # lock debugging
1738
1739config TRACE_IRQFLAGS
1740 depends on TRACE_IRQFLAGS_SUPPORT
1741 bool
1742 help
1743 Enables hooks to interrupt enabling and disabling for
1744 either tracing or lock debugging.
1745
1746config TRACE_IRQFLAGS_NMI
1747 def_bool y
1748 depends on TRACE_IRQFLAGS
1749 depends on TRACE_IRQFLAGS_NMI_SUPPORT
1750
1751config NMI_CHECK_CPU
1752 bool "Debugging for CPUs failing to respond to backtrace requests"
1753 depends on DEBUG_KERNEL
1754 depends on X86
1755 default n
1756 help
1757 Enables debug prints when a CPU fails to respond to a given
1758 backtrace NMI. These prints provide some reasons why a CPU
1759 might legitimately be failing to respond, for example, if it
1760 is offline of if ignore_nmis is set.
1761
1762config DEBUG_IRQFLAGS
1763 bool "Debug IRQ flag manipulation"
1764 help
1765 Enables checks for potentially unsafe enabling or disabling of
1766 interrupts, such as calling raw_local_irq_restore() when interrupts
1767 are enabled.
1768
1769config STACKTRACE
1770 bool "Stack backtrace support"
1771 depends on STACKTRACE_SUPPORT
1772 help
1773 This option causes the kernel to create a /proc/pid/stack for
1774 every process, showing its current stack trace.
1775 It is also used by various kernel debugging features that require
1776 stack trace generation.
1777
1778config DEBUG_KOBJECT
1779 bool "kobject debugging"
1780 depends on DEBUG_KERNEL
1781 help
1782 If you say Y here, some extra kobject debugging messages will be sent
1783 to the syslog.
1784
1785config DEBUG_KOBJECT_RELEASE
1786 bool "kobject release debugging"
1787 depends on DEBUG_OBJECTS_TIMERS
1788 help
1789 kobjects are reference counted objects. This means that their
1790 last reference count put is not predictable, and the kobject can
1791 live on past the point at which a driver decides to drop its
1792 initial reference to the kobject gained on allocation. An
1793 example of this would be a struct device which has just been
1794 unregistered.
1795
1796 However, some buggy drivers assume that after such an operation,
1797 the memory backing the kobject can be immediately freed. This
1798 goes completely against the principles of a refcounted object.
1799
1800 If you say Y here, the kernel will delay the release of kobjects
1801 on the last reference count to improve the visibility of this
1802 kind of kobject release bug.
1803
1804config HAVE_DEBUG_BUGVERBOSE
1805 bool
1806
1807menu "Debug kernel data structures"
1808
1809config DEBUG_LIST
1810 bool "Debug linked list manipulation"
1811 depends on DEBUG_KERNEL
1812 select LIST_HARDENED
1813 help
1814 Enable this to turn on extended checks in the linked-list walking
1815 routines.
1816
1817 This option trades better quality error reports for performance, and
1818 is more suitable for kernel debugging. If you care about performance,
1819 you should only enable CONFIG_LIST_HARDENED instead.
1820
1821 If unsure, say N.
1822
1823config DEBUG_PLIST
1824 bool "Debug priority linked list manipulation"
1825 depends on DEBUG_KERNEL
1826 help
1827 Enable this to turn on extended checks in the priority-ordered
1828 linked-list (plist) walking routines. This checks the entire
1829 list multiple times during each manipulation.
1830
1831 If unsure, say N.
1832
1833config DEBUG_SG
1834 bool "Debug SG table operations"
1835 depends on DEBUG_KERNEL
1836 help
1837 Enable this to turn on checks on scatter-gather tables. This can
1838 help find problems with drivers that do not properly initialize
1839 their sg tables.
1840
1841 If unsure, say N.
1842
1843config DEBUG_NOTIFIERS
1844 bool "Debug notifier call chains"
1845 depends on DEBUG_KERNEL
1846 help
1847 Enable this to turn on sanity checking for notifier call chains.
1848 This is most useful for kernel developers to make sure that
1849 modules properly unregister themselves from notifier chains.
1850 This is a relatively cheap check but if you care about maximum
1851 performance, say N.
1852
1853config DEBUG_CLOSURES
1854 bool "Debug closures (bcache async widgits)"
1855 depends on CLOSURES
1856 select DEBUG_FS
1857 help
1858 Keeps all active closures in a linked list and provides a debugfs
1859 interface to list them, which makes it possible to see asynchronous
1860 operations that get stuck.
1861
1862config DEBUG_MAPLE_TREE
1863 bool "Debug maple trees"
1864 depends on DEBUG_KERNEL
1865 help
1866 Enable maple tree debugging information and extra validations.
1867
1868 If unsure, say N.
1869
1870endmenu
1871
1872source "kernel/rcu/Kconfig.debug"
1873
1874config DEBUG_WQ_FORCE_RR_CPU
1875 bool "Force round-robin CPU selection for unbound work items"
1876 depends on DEBUG_KERNEL
1877 default n
1878 help
1879 Workqueue used to implicitly guarantee that work items queued
1880 without explicit CPU specified are put on the local CPU. This
1881 guarantee is no longer true and while local CPU is still
1882 preferred work items may be put on foreign CPUs. Kernel
1883 parameter "workqueue.debug_force_rr_cpu" is added to force
1884 round-robin CPU selection to flush out usages which depend on the
1885 now broken guarantee. This config option enables the debug
1886 feature by default. When enabled, memory and cache locality will
1887 be impacted.
1888
1889config CPU_HOTPLUG_STATE_CONTROL
1890 bool "Enable CPU hotplug state control"
1891 depends on DEBUG_KERNEL
1892 depends on HOTPLUG_CPU
1893 default n
1894 help
1895 Allows to write steps between "offline" and "online" to the CPUs
1896 sysfs target file so states can be stepped granular. This is a debug
1897 option for now as the hotplug machinery cannot be stopped and
1898 restarted at arbitrary points yet.
1899
1900 Say N if your are unsure.
1901
1902config LATENCYTOP
1903 bool "Latency measuring infrastructure"
1904 depends on DEBUG_KERNEL
1905 depends on STACKTRACE_SUPPORT
1906 depends on PROC_FS
1907 depends on FRAME_POINTER || MIPS || PPC || S390 || MICROBLAZE || ARM || ARC || X86
1908 select KALLSYMS
1909 select KALLSYMS_ALL
1910 select STACKTRACE
1911 select SCHEDSTATS
1912 help
1913 Enable this option if you want to use the LatencyTOP tool
1914 to find out which userspace is blocking on what kernel operations.
1915
1916config DEBUG_CGROUP_REF
1917 bool "Disable inlining of cgroup css reference count functions"
1918 depends on DEBUG_KERNEL
1919 depends on CGROUPS
1920 depends on KPROBES
1921 default n
1922 help
1923 Force cgroup css reference count functions to not be inlined so
1924 that they can be kprobed for debugging.
1925
1926source "kernel/trace/Kconfig"
1927
1928config PROVIDE_OHCI1394_DMA_INIT
1929 bool "Remote debugging over FireWire early on boot"
1930 depends on PCI && X86
1931 help
1932 If you want to debug problems which hang or crash the kernel early
1933 on boot and the crashing machine has a FireWire port, you can use
1934 this feature to remotely access the memory of the crashed machine
1935 over FireWire. This employs remote DMA as part of the OHCI1394
1936 specification which is now the standard for FireWire controllers.
1937
1938 With remote DMA, you can monitor the printk buffer remotely using
1939 firescope and access all memory below 4GB using fireproxy from gdb.
1940 Even controlling a kernel debugger is possible using remote DMA.
1941
1942 Usage:
1943
1944 If ohci1394_dma=early is used as boot parameter, it will initialize
1945 all OHCI1394 controllers which are found in the PCI config space.
1946
1947 As all changes to the FireWire bus such as enabling and disabling
1948 devices cause a bus reset and thereby disable remote DMA for all
1949 devices, be sure to have the cable plugged and FireWire enabled on
1950 the debugging host before booting the debug target for debugging.
1951
1952 This code (~1k) is freed after boot. By then, the firewire stack
1953 in charge of the OHCI-1394 controllers should be used instead.
1954
1955 See Documentation/core-api/debugging-via-ohci1394.rst for more information.
1956
1957source "samples/Kconfig"
1958
1959config ARCH_HAS_DEVMEM_IS_ALLOWED
1960 bool
1961
1962config STRICT_DEVMEM
1963 bool "Filter access to /dev/mem"
1964 depends on MMU && DEVMEM
1965 depends on ARCH_HAS_DEVMEM_IS_ALLOWED || GENERIC_LIB_DEVMEM_IS_ALLOWED
1966 default y if PPC || X86 || ARM64 || S390
1967 help
1968 If this option is disabled, you allow userspace (root) access to all
1969 of memory, including kernel and userspace memory. Accidental
1970 access to this is obviously disastrous, but specific access can
1971 be used by people debugging the kernel. Note that with PAT support
1972 enabled, even in this case there are restrictions on /dev/mem
1973 use due to the cache aliasing requirements.
1974
1975 If this option is switched on, and IO_STRICT_DEVMEM=n, the /dev/mem
1976 file only allows userspace access to PCI space and the BIOS code and
1977 data regions. This is sufficient for dosemu and X and all common
1978 users of /dev/mem.
1979
1980 If in doubt, say Y.
1981
1982config IO_STRICT_DEVMEM
1983 bool "Filter I/O access to /dev/mem"
1984 depends on STRICT_DEVMEM
1985 help
1986 If this option is disabled, you allow userspace (root) access to all
1987 io-memory regardless of whether a driver is actively using that
1988 range. Accidental access to this is obviously disastrous, but
1989 specific access can be used by people debugging kernel drivers.
1990
1991 If this option is switched on, the /dev/mem file only allows
1992 userspace access to *idle* io-memory ranges (see /proc/iomem) This
1993 may break traditional users of /dev/mem (dosemu, legacy X, etc...)
1994 if the driver using a given range cannot be disabled.
1995
1996 If in doubt, say Y.
1997
1998menu "$(SRCARCH) Debugging"
1999
2000source "arch/$(SRCARCH)/Kconfig.debug"
2001
2002endmenu
2003
2004menu "Kernel Testing and Coverage"
2005
2006source "lib/kunit/Kconfig"
2007
2008config NOTIFIER_ERROR_INJECTION
2009 tristate "Notifier error injection"
2010 depends on DEBUG_KERNEL
2011 select DEBUG_FS
2012 help
2013 This option provides the ability to inject artificial errors to
2014 specified notifier chain callbacks. It is useful to test the error
2015 handling of notifier call chain failures.
2016
2017 Say N if unsure.
2018
2019config PM_NOTIFIER_ERROR_INJECT
2020 tristate "PM notifier error injection module"
2021 depends on PM && NOTIFIER_ERROR_INJECTION
2022 default m if PM_DEBUG
2023 help
2024 This option provides the ability to inject artificial errors to
2025 PM notifier chain callbacks. It is controlled through debugfs
2026 interface /sys/kernel/debug/notifier-error-inject/pm
2027
2028 If the notifier call chain should be failed with some events
2029 notified, write the error code to "actions/<notifier event>/error".
2030
2031 Example: Inject PM suspend error (-12 = -ENOMEM)
2032
2033 # cd /sys/kernel/debug/notifier-error-inject/pm/
2034 # echo -12 > actions/PM_SUSPEND_PREPARE/error
2035 # echo mem > /sys/power/state
2036 bash: echo: write error: Cannot allocate memory
2037
2038 To compile this code as a module, choose M here: the module will
2039 be called pm-notifier-error-inject.
2040
2041 If unsure, say N.
2042
2043config OF_RECONFIG_NOTIFIER_ERROR_INJECT
2044 tristate "OF reconfig notifier error injection module"
2045 depends on OF_DYNAMIC && NOTIFIER_ERROR_INJECTION
2046 help
2047 This option provides the ability to inject artificial errors to
2048 OF reconfig notifier chain callbacks. It is controlled
2049 through debugfs interface under
2050 /sys/kernel/debug/notifier-error-inject/OF-reconfig/
2051
2052 If the notifier call chain should be failed with some events
2053 notified, write the error code to "actions/<notifier event>/error".
2054
2055 To compile this code as a module, choose M here: the module will
2056 be called of-reconfig-notifier-error-inject.
2057
2058 If unsure, say N.
2059
2060config NETDEV_NOTIFIER_ERROR_INJECT
2061 tristate "Netdev notifier error injection module"
2062 depends on NET && NOTIFIER_ERROR_INJECTION
2063 help
2064 This option provides the ability to inject artificial errors to
2065 netdevice notifier chain callbacks. It is controlled through debugfs
2066 interface /sys/kernel/debug/notifier-error-inject/netdev
2067
2068 If the notifier call chain should be failed with some events
2069 notified, write the error code to "actions/<notifier event>/error".
2070
2071 Example: Inject netdevice mtu change error (-22 = -EINVAL)
2072
2073 # cd /sys/kernel/debug/notifier-error-inject/netdev
2074 # echo -22 > actions/NETDEV_CHANGEMTU/error
2075 # ip link set eth0 mtu 1024
2076 RTNETLINK answers: Invalid argument
2077
2078 To compile this code as a module, choose M here: the module will
2079 be called netdev-notifier-error-inject.
2080
2081 If unsure, say N.
2082
2083config FUNCTION_ERROR_INJECTION
2084 bool "Fault-injections of functions"
2085 depends on HAVE_FUNCTION_ERROR_INJECTION && KPROBES
2086 help
2087 Add fault injections into various functions that are annotated with
2088 ALLOW_ERROR_INJECTION() in the kernel. BPF may also modify the return
2089 value of these functions. This is useful to test error paths of code.
2090
2091 If unsure, say N
2092
2093config FAULT_INJECTION
2094 bool "Fault-injection framework"
2095 depends on DEBUG_KERNEL
2096 help
2097 Provide fault-injection framework.
2098 For more details, see Documentation/fault-injection/.
2099
2100config FAILSLAB
2101 bool "Fault-injection capability for kmalloc"
2102 depends on FAULT_INJECTION
2103 help
2104 Provide fault-injection capability for kmalloc.
2105
2106config FAIL_PAGE_ALLOC
2107 bool "Fault-injection capability for alloc_pages()"
2108 depends on FAULT_INJECTION
2109 help
2110 Provide fault-injection capability for alloc_pages().
2111
2112config FAULT_INJECTION_USERCOPY
2113 bool "Fault injection capability for usercopy functions"
2114 depends on FAULT_INJECTION
2115 help
2116 Provides fault-injection capability to inject failures
2117 in usercopy functions (copy_from_user(), get_user(), ...).
2118
2119config FAIL_MAKE_REQUEST
2120 bool "Fault-injection capability for disk IO"
2121 depends on FAULT_INJECTION && BLOCK
2122 help
2123 Provide fault-injection capability for disk IO.
2124
2125config FAIL_IO_TIMEOUT
2126 bool "Fault-injection capability for faking disk interrupts"
2127 depends on FAULT_INJECTION && BLOCK
2128 help
2129 Provide fault-injection capability on end IO handling. This
2130 will make the block layer "forget" an interrupt as configured,
2131 thus exercising the error handling.
2132
2133 Only works with drivers that use the generic timeout handling,
2134 for others it won't do anything.
2135
2136config FAIL_FUTEX
2137 bool "Fault-injection capability for futexes"
2138 select DEBUG_FS
2139 depends on FAULT_INJECTION && FUTEX
2140 help
2141 Provide fault-injection capability for futexes.
2142
2143config FAULT_INJECTION_DEBUG_FS
2144 bool "Debugfs entries for fault-injection capabilities"
2145 depends on FAULT_INJECTION && SYSFS && DEBUG_FS
2146 help
2147 Enable configuration of fault-injection capabilities via debugfs.
2148
2149config FAIL_FUNCTION
2150 bool "Fault-injection capability for functions"
2151 depends on FAULT_INJECTION_DEBUG_FS && FUNCTION_ERROR_INJECTION
2152 help
2153 Provide function-based fault-injection capability.
2154 This will allow you to override a specific function with a return
2155 with given return value. As a result, function caller will see
2156 an error value and have to handle it. This is useful to test the
2157 error handling in various subsystems.
2158
2159config FAIL_MMC_REQUEST
2160 bool "Fault-injection capability for MMC IO"
2161 depends on FAULT_INJECTION_DEBUG_FS && MMC
2162 help
2163 Provide fault-injection capability for MMC IO.
2164 This will make the mmc core return data errors. This is
2165 useful to test the error handling in the mmc block device
2166 and to test how the mmc host driver handles retries from
2167 the block device.
2168
2169config FAIL_SUNRPC
2170 bool "Fault-injection capability for SunRPC"
2171 depends on FAULT_INJECTION_DEBUG_FS && SUNRPC_DEBUG
2172 help
2173 Provide fault-injection capability for SunRPC and
2174 its consumers.
2175
2176config FAIL_SKB_REALLOC
2177 bool "Fault-injection capability forcing skb to reallocate"
2178 depends on FAULT_INJECTION_DEBUG_FS
2179 help
2180 Provide fault-injection capability that forces the skb to be
2181 reallocated, catching possible invalid pointers to the skb.
2182
2183 For more information, check
2184 Documentation/fault-injection/fault-injection.rst
2185
2186config FAULT_INJECTION_CONFIGFS
2187 bool "Configfs interface for fault-injection capabilities"
2188 depends on FAULT_INJECTION
2189 select CONFIGFS_FS
2190 help
2191 This option allows configfs-based drivers to dynamically configure
2192 fault-injection via configfs. Each parameter for driver-specific
2193 fault-injection can be made visible as a configfs attribute in a
2194 configfs group.
2195
2196
2197config FAULT_INJECTION_STACKTRACE_FILTER
2198 bool "stacktrace filter for fault-injection capabilities"
2199 depends on FAULT_INJECTION
2200 depends on (FAULT_INJECTION_DEBUG_FS || FAULT_INJECTION_CONFIGFS) && STACKTRACE_SUPPORT
2201 select STACKTRACE
2202 depends on FRAME_POINTER || MIPS || PPC || S390 || MICROBLAZE || ARM || ARC || X86
2203 help
2204 Provide stacktrace filter for fault-injection capabilities
2205
2206config ARCH_HAS_KCOV
2207 bool
2208 help
2209 An architecture should select this when it can successfully
2210 build and run with CONFIG_KCOV. This typically requires
2211 disabling instrumentation for some early boot code.
2212
2213config KCOV
2214 bool "Code coverage for fuzzing"
2215 depends on ARCH_HAS_KCOV
2216 depends on !ARCH_WANTS_NO_INSTR || HAVE_NOINSTR_HACK || \
2217 GCC_VERSION >= 120000 || CC_IS_CLANG
2218 select DEBUG_FS
2219 select OBJTOOL if HAVE_NOINSTR_HACK
2220 help
2221 KCOV exposes kernel code coverage information in a form suitable
2222 for coverage-guided fuzzing (randomized testing).
2223
2224 For more details, see Documentation/dev-tools/kcov.rst.
2225
2226config KCOV_ENABLE_COMPARISONS
2227 bool "Enable comparison operands collection by KCOV"
2228 depends on KCOV
2229 depends on $(cc-option,-fsanitize-coverage=trace-cmp)
2230 help
2231 KCOV also exposes operands of every comparison in the instrumented
2232 code along with operand sizes and PCs of the comparison instructions.
2233 These operands can be used by fuzzing engines to improve the quality
2234 of fuzzing coverage.
2235
2236config KCOV_INSTRUMENT_ALL
2237 bool "Instrument all code by default"
2238 depends on KCOV
2239 default y
2240 help
2241 If you are doing generic system call fuzzing (like e.g. syzkaller),
2242 then you will want to instrument the whole kernel and you should
2243 say y here. If you are doing more targeted fuzzing (like e.g.
2244 filesystem fuzzing with AFL) then you will want to enable coverage
2245 for more specific subsets of files, and should say n here.
2246
2247config KCOV_IRQ_AREA_SIZE
2248 hex "Size of interrupt coverage collection area in words"
2249 depends on KCOV
2250 default 0x40000
2251 help
2252 KCOV uses preallocated per-cpu areas to collect coverage from
2253 soft interrupts. This specifies the size of those areas in the
2254 number of unsigned long words.
2255
2256config KCOV_SELFTEST
2257 bool "Perform short selftests on boot"
2258 depends on KCOV
2259 help
2260 Run short KCOV coverage collection selftests on boot.
2261 On test failure, causes the kernel to panic. Recommended to be
2262 enabled, ensuring critical functionality works as intended.
2263
2264menuconfig RUNTIME_TESTING_MENU
2265 bool "Runtime Testing"
2266 default y
2267
2268if RUNTIME_TESTING_MENU
2269
2270config TEST_DHRY
2271 tristate "Dhrystone benchmark test"
2272 help
2273 Enable this to include the Dhrystone 2.1 benchmark. This test
2274 calculates the number of Dhrystones per second, and the number of
2275 DMIPS (Dhrystone MIPS) obtained when the Dhrystone score is divided
2276 by 1757 (the number of Dhrystones per second obtained on the VAX
2277 11/780, nominally a 1 MIPS machine).
2278
2279 To run the benchmark, it needs to be enabled explicitly, either from
2280 the kernel command line (when built-in), or from userspace (when
2281 built-in or modular).
2282
2283 Run once during kernel boot:
2284
2285 test_dhry.run
2286
2287 Set number of iterations from kernel command line:
2288
2289 test_dhry.iterations=<n>
2290
2291 Set number of iterations from userspace:
2292
2293 echo <n> > /sys/module/test_dhry/parameters/iterations
2294
2295 Trigger manual run from userspace:
2296
2297 echo y > /sys/module/test_dhry/parameters/run
2298
2299 If the number of iterations is <= 0, the test will devise a suitable
2300 number of iterations (test runs for at least 2s) automatically.
2301 This process takes ca. 4s.
2302
2303 If unsure, say N.
2304
2305config LKDTM
2306 tristate "Linux Kernel Dump Test Tool Module"
2307 depends on DEBUG_FS
2308 help
2309 This module enables testing of the different dumping mechanisms by
2310 inducing system failures at predefined crash points.
2311 If you don't need it: say N
2312 Choose M here to compile this code as a module. The module will be
2313 called lkdtm.
2314
2315 Documentation on how to use the module can be found in
2316 Documentation/fault-injection/provoke-crashes.rst
2317
2318config CPUMASK_KUNIT_TEST
2319 tristate "KUnit test for cpumask" if !KUNIT_ALL_TESTS
2320 depends on KUNIT
2321 default KUNIT_ALL_TESTS
2322 help
2323 Enable to turn on cpumask tests, running at boot or module load time.
2324
2325 For more information on KUnit and unit tests in general, please refer
2326 to the KUnit documentation in Documentation/dev-tools/kunit/.
2327
2328 If unsure, say N.
2329
2330config TEST_LIST_SORT
2331 tristate "Linked list sorting test" if !KUNIT_ALL_TESTS
2332 depends on KUNIT
2333 default KUNIT_ALL_TESTS
2334 help
2335 Enable this to turn on 'list_sort()' function test. This test is
2336 executed only once during system boot (so affects only boot time),
2337 or at module load time.
2338
2339 If unsure, say N.
2340
2341config TEST_SORT
2342 tristate "Array-based sort test" if !KUNIT_ALL_TESTS
2343 depends on KUNIT
2344 default KUNIT_ALL_TESTS
2345 help
2346 This option enables the self-test function of 'sort()' at boot,
2347 or at module load time.
2348
2349 If unsure, say N.
2350
2351config TEST_DIV64
2352 tristate "64bit/32bit division and modulo test"
2353 depends on DEBUG_KERNEL || m
2354 help
2355 Enable this to turn on 'do_div()' function test. This test is
2356 executed only once during system boot (so affects only boot time),
2357 or at module load time.
2358
2359 If unsure, say N.
2360
2361config TEST_MULDIV64
2362 tristate "mul_u64_u64_div_u64() test"
2363 depends on DEBUG_KERNEL || m
2364 help
2365 Enable this to turn on 'mul_u64_u64_div_u64()' function test.
2366 This test is executed only once during system boot (so affects
2367 only boot time), or at module load time.
2368
2369 If unsure, say N.
2370
2371config TEST_IOV_ITER
2372 tristate "Test iov_iter operation" if !KUNIT_ALL_TESTS
2373 depends on KUNIT
2374 depends on MMU
2375 default KUNIT_ALL_TESTS
2376 help
2377 Enable this to turn on testing of the operation of the I/O iterator
2378 (iov_iter). This test is executed only once during system boot (so
2379 affects only boot time), or at module load time.
2380
2381 If unsure, say N.
2382
2383config KPROBES_SANITY_TEST
2384 tristate "Kprobes sanity tests" if !KUNIT_ALL_TESTS
2385 depends on DEBUG_KERNEL
2386 depends on KPROBES
2387 depends on KUNIT
2388 select STACKTRACE if ARCH_CORRECT_STACKTRACE_ON_KRETPROBE
2389 default KUNIT_ALL_TESTS
2390 help
2391 This option provides for testing basic kprobes functionality on
2392 boot. Samples of kprobe and kretprobe are inserted and
2393 verified for functionality.
2394
2395 Say N if you are unsure.
2396
2397config FPROBE_SANITY_TEST
2398 bool "Self test for fprobe"
2399 depends on DEBUG_KERNEL
2400 depends on FPROBE
2401 depends on KUNIT=y
2402 help
2403 This option will enable testing the fprobe when the system boot.
2404 A series of tests are made to verify that the fprobe is functioning
2405 properly.
2406
2407 Say N if you are unsure.
2408
2409config BACKTRACE_SELF_TEST
2410 tristate "Self test for the backtrace code"
2411 depends on DEBUG_KERNEL
2412 help
2413 This option provides a kernel module that can be used to test
2414 the kernel stack backtrace code. This option is not useful
2415 for distributions or general kernels, but only for kernel
2416 developers working on architecture code.
2417
2418 Note that if you want to also test saved backtraces, you will
2419 have to enable STACKTRACE as well.
2420
2421 Say N if you are unsure.
2422
2423config TEST_REF_TRACKER
2424 tristate "Self test for reference tracker"
2425 depends on DEBUG_KERNEL && STACKTRACE_SUPPORT
2426 select REF_TRACKER
2427 help
2428 This option provides a kernel module performing tests
2429 using reference tracker infrastructure.
2430
2431 Say N if you are unsure.
2432
2433config RBTREE_TEST
2434 tristate "Red-Black tree test"
2435 depends on DEBUG_KERNEL
2436 help
2437 A benchmark measuring the performance of the rbtree library.
2438 Also includes rbtree invariant checks.
2439
2440config REED_SOLOMON_TEST
2441 tristate "Reed-Solomon library test"
2442 depends on DEBUG_KERNEL || m
2443 select REED_SOLOMON
2444 select REED_SOLOMON_ENC16
2445 select REED_SOLOMON_DEC16
2446 help
2447 This option enables the self-test function of rslib at boot,
2448 or at module load time.
2449
2450 If unsure, say N.
2451
2452config INTERVAL_TREE_TEST
2453 tristate "Interval tree test"
2454 depends on DEBUG_KERNEL
2455 select INTERVAL_TREE
2456 help
2457 A benchmark measuring the performance of the interval tree library
2458
2459config PERCPU_TEST
2460 tristate "Per cpu operations test"
2461 depends on m && DEBUG_KERNEL
2462 help
2463 Enable this option to build test module which validates per-cpu
2464 operations.
2465
2466 If unsure, say N.
2467
2468config ATOMIC64_SELFTEST
2469 tristate "Perform an atomic64_t self-test"
2470 help
2471 Enable this option to test the atomic64_t functions at boot or
2472 at module load time.
2473
2474 If unsure, say N.
2475
2476config ASYNC_RAID6_TEST
2477 tristate "Self test for hardware accelerated raid6 recovery"
2478 depends on ASYNC_RAID6_RECOV
2479 select ASYNC_MEMCPY
2480 help
2481 This is a one-shot self test that permutes through the
2482 recovery of all the possible two disk failure scenarios for a
2483 N-disk array. Recovery is performed with the asynchronous
2484 raid6 recovery routines, and will optionally use an offload
2485 engine if one is available.
2486
2487 If unsure, say N.
2488
2489config TEST_HEXDUMP
2490 tristate "Test functions located in the hexdump module at runtime"
2491
2492config PRINTF_KUNIT_TEST
2493 tristate "KUnit test printf() family of functions at runtime" if !KUNIT_ALL_TESTS
2494 depends on KUNIT
2495 default KUNIT_ALL_TESTS
2496 help
2497 Enable this option to test the printf functions at runtime.
2498
2499 If unsure, say N.
2500
2501config SCANF_KUNIT_TEST
2502 tristate "KUnit test scanf() family of functions at runtime" if !KUNIT_ALL_TESTS
2503 depends on KUNIT
2504 default KUNIT_ALL_TESTS
2505 help
2506 Enable this option to test the scanf functions at runtime.
2507
2508 If unsure, say N.
2509
2510config SEQ_BUF_KUNIT_TEST
2511 tristate "KUnit test for seq_buf" if !KUNIT_ALL_TESTS
2512 depends on KUNIT
2513 default KUNIT_ALL_TESTS
2514 help
2515 This builds unit tests for the seq_buf library.
2516
2517 If unsure, say N.
2518
2519config STRING_KUNIT_TEST
2520 tristate "KUnit test string functions at runtime" if !KUNIT_ALL_TESTS
2521 depends on KUNIT
2522 default KUNIT_ALL_TESTS
2523
2524config STRING_HELPERS_KUNIT_TEST
2525 tristate "KUnit test string helpers at runtime" if !KUNIT_ALL_TESTS
2526 depends on KUNIT
2527 default KUNIT_ALL_TESTS
2528
2529config STRING_KUNIT_BENCH
2530 bool "Benchmark string functions at runtime"
2531 depends on STRING_KUNIT_TEST
2532 help
2533 Enable performance measurement for string functions.
2534
2535 This measures the execution efficiency of string functions
2536 during the KUnit test run.
2537
2538 If unsure, say N.
2539
2540config FFS_KUNIT_TEST
2541 tristate "KUnit test ffs-family functions at runtime" if !KUNIT_ALL_TESTS
2542 depends on KUNIT
2543 default KUNIT_ALL_TESTS
2544 help
2545 This builds KUnit tests for ffs-family bit manipulation functions
2546 including ffs(), __ffs(), fls(), __fls(), fls64(), and __ffs64().
2547
2548 These tests validate mathematical correctness, edge case handling,
2549 and cross-architecture consistency of bit scanning functions.
2550
2551 For more information on KUnit and unit tests in general,
2552 please refer to Documentation/dev-tools/kunit/.
2553
2554config TEST_KSTRTOX
2555 tristate "Test kstrto*() family of functions at runtime"
2556
2557config TEST_BITMAP
2558 tristate "Test bitmap_*() family of functions at runtime"
2559 help
2560 Enable this option to test the bitmap functions at boot.
2561
2562 If unsure, say N.
2563
2564config TEST_XARRAY
2565 tristate "Test the XArray code at runtime"
2566
2567config TEST_MAPLE_TREE
2568 tristate "Test the Maple Tree code at runtime or module load"
2569 help
2570 Enable this option to test the maple tree code functions at boot, or
2571 when the module is loaded. Enable "Debug Maple Trees" will enable
2572 more verbose output on failures.
2573
2574 If unsure, say N.
2575
2576config TEST_RHASHTABLE
2577 tristate "Perform selftest on resizable hash table"
2578 help
2579 Enable this option to test the rhashtable functions at boot.
2580
2581 If unsure, say N.
2582
2583config TEST_IDA
2584 tristate "Perform selftest on IDA functions"
2585
2586config TEST_MISC_MINOR
2587 bool "miscdevice KUnit test" if !KUNIT_ALL_TESTS
2588 depends on KUNIT=y
2589 default KUNIT_ALL_TESTS
2590 help
2591 Kunit test for miscdevice API, specially its behavior in respect to
2592 static and dynamic minor numbers.
2593
2594 KUnit tests run during boot and output the results to the debug log
2595 in TAP format (https://testanything.org/). Only useful for kernel devs
2596 running the KUnit test harness, and not intended for inclusion into a
2597 production build.
2598
2599 For more information on KUnit and unit tests in general please refer
2600 to the KUnit documentation in Documentation/dev-tools/kunit/.
2601
2602 If unsure, say N.
2603
2604config TEST_PARMAN
2605 tristate "Perform selftest on priority array manager"
2606 depends on PARMAN
2607 help
2608 Enable this option to test priority array manager on boot
2609 (or module load).
2610
2611 If unsure, say N.
2612
2613config TEST_LKM
2614 tristate "Test module loading with 'hello world' module"
2615 depends on m
2616 help
2617 This builds the "test_module" module that emits "Hello, world"
2618 on printk when loaded. It is designed to be used for basic
2619 evaluation of the module loading subsystem (for example when
2620 validating module verification). It lacks any extra dependencies,
2621 and will not normally be loaded by the system unless explicitly
2622 requested by name.
2623
2624 If unsure, say N.
2625
2626config TEST_BITOPS
2627 tristate "Test module for compilation of bitops operations"
2628 help
2629 This builds the "test_bitops" module that is much like the
2630 TEST_LKM module except that it does a basic exercise of the
2631 set/clear_bit macros and get_count_order/long to make sure there are
2632 no compiler warnings from C=1 sparse checker or -Wextra
2633 compilations. It has no dependencies and doesn't run or load unless
2634 explicitly requested by name. for example: modprobe test_bitops.
2635
2636 If unsure, say N.
2637
2638config TEST_VMALLOC
2639 tristate "Test module for stress/performance analysis of vmalloc allocator"
2640 default n
2641 depends on MMU
2642 help
2643 This builds the "test_vmalloc" module that should be used for
2644 stress and performance analysis. So, any new change for vmalloc
2645 subsystem can be evaluated from performance and stability point
2646 of view.
2647
2648 If unsure, say N.
2649
2650config TEST_WORKQUEUE
2651 tristate "Test module for stress/performance analysis of workqueue"
2652 default n
2653 help
2654 This builds the "test_workqueue" module for benchmarking
2655 workqueue throughput under contention. Useful for evaluating
2656 affinity scope changes (e.g., cache_shard vs cache).
2657
2658 If unsure, say N.
2659
2660config TEST_BPF
2661 tristate "Test BPF filter functionality"
2662 depends on m && NET
2663 help
2664 This builds the "test_bpf" module that runs various test vectors
2665 against the BPF interpreter or BPF JIT compiler depending on the
2666 current setting. This is in particular useful for BPF JIT compiler
2667 development, but also to run regression tests against changes in
2668 the interpreter code. It also enables test stubs for eBPF maps and
2669 verifier used by user space verifier testsuite.
2670
2671 If unsure, say N.
2672
2673config FIND_BIT_BENCHMARK
2674 tristate "Test find_bit functions"
2675 help
2676 This builds the "test_find_bit" module that measure find_*_bit()
2677 functions performance.
2678
2679 If unsure, say N.
2680
2681config FIND_BIT_BENCHMARK_RUST
2682 tristate "Test find_bit functions in Rust"
2683 depends on RUST
2684 help
2685 This builds the "find_bit_benchmark_rust" module. It is a micro
2686 benchmark that measures the performance of Rust functions that
2687 correspond to the find_*_bit() operations in C. It follows the
2688 FIND_BIT_BENCHMARK closely but will in general not yield same
2689 numbers due to extra bounds checks and overhead of foreign
2690 function calls.
2691
2692 If unsure, say N.
2693
2694config TEST_FIRMWARE
2695 tristate "Test firmware loading via userspace interface"
2696 depends on FW_LOADER
2697 help
2698 This builds the "test_firmware" module that creates a userspace
2699 interface for testing firmware loading. This can be used to
2700 control the triggering of firmware loading without needing an
2701 actual firmware-using device. The contents can be rechecked by
2702 userspace.
2703
2704 If unsure, say N.
2705
2706config TEST_SYSCTL
2707 tristate "sysctl test driver"
2708 depends on PROC_SYSCTL
2709 help
2710 This builds the "test_sysctl" module. This driver enables to test the
2711 proc sysctl interfaces available to drivers safely without affecting
2712 production knobs which might alter system functionality.
2713
2714 If unsure, say N.
2715
2716config BITOPS_KUNIT
2717 tristate "KUnit test for bitops" if !KUNIT_ALL_TESTS
2718 depends on KUNIT
2719 default KUNIT_ALL_TESTS
2720 help
2721 This option enables the KUnit test for the bitops library
2722 which provides functions for bit operations.
2723
2724 Note that this is derived from the original test_bitops module.
2725 For micro-benchmarks and compiler warning checks, enable TEST_BITOPS.
2726
2727 If unsure, say N.
2728
2729config BITFIELD_KUNIT
2730 tristate "KUnit test bitfield functions at runtime" if !KUNIT_ALL_TESTS
2731 depends on KUNIT
2732 default KUNIT_ALL_TESTS
2733 help
2734 Enable this option to test the bitfield functions at boot.
2735
2736 KUnit tests run during boot and output the results to the debug log
2737 in TAP format (http://testanything.org/). Only useful for kernel devs
2738 running the KUnit test harness, and not intended for inclusion into a
2739 production build.
2740
2741 For more information on KUnit and unit tests in general please refer
2742 to the KUnit documentation in Documentation/dev-tools/kunit/.
2743
2744 If unsure, say N.
2745
2746config CHECKSUM_KUNIT
2747 tristate "KUnit test checksum functions at runtime" if !KUNIT_ALL_TESTS
2748 depends on KUNIT
2749 default KUNIT_ALL_TESTS
2750 help
2751 Enable this option to test the checksum functions at boot.
2752
2753 KUnit tests run during boot and output the results to the debug log
2754 in TAP format (http://testanything.org/). Only useful for kernel devs
2755 running the KUnit test harness, and not intended for inclusion into a
2756 production build.
2757
2758 For more information on KUnit and unit tests in general please refer
2759 to the KUnit documentation in Documentation/dev-tools/kunit/.
2760
2761 If unsure, say N.
2762
2763config UTIL_MACROS_KUNIT
2764 tristate "KUnit test util_macros.h functions at runtime" if !KUNIT_ALL_TESTS
2765 depends on KUNIT
2766 default KUNIT_ALL_TESTS
2767 help
2768 Enable this option to test the util_macros.h function at boot.
2769
2770 KUnit tests run during boot and output the results to the debug log
2771 in TAP format (http://testanything.org/). Only useful for kernel devs
2772 running the KUnit test harness, and not intended for inclusion into a
2773 production build.
2774
2775 For more information on KUnit and unit tests in general please refer
2776 to the KUnit documentation in Documentation/dev-tools/kunit/.
2777
2778 If unsure, say N.
2779
2780config HASH_KUNIT_TEST
2781 tristate "KUnit Test for integer hash functions" if !KUNIT_ALL_TESTS
2782 depends on KUNIT
2783 default KUNIT_ALL_TESTS
2784 help
2785 Enable this option to test the kernel's string (<linux/stringhash.h>), and
2786 integer (<linux/hash.h>) hash functions on boot.
2787
2788 KUnit tests run during boot and output the results to the debug log
2789 in TAP format (https://testanything.org/). Only useful for kernel devs
2790 running the KUnit test harness, and not intended for inclusion into a
2791 production build.
2792
2793 For more information on KUnit and unit tests in general please refer
2794 to the KUnit documentation in Documentation/dev-tools/kunit/.
2795
2796 This is intended to help people writing architecture-specific
2797 optimized versions. If unsure, say N.
2798
2799config RESOURCE_KUNIT_TEST
2800 tristate "KUnit test for resource API" if !KUNIT_ALL_TESTS
2801 depends on KUNIT
2802 default KUNIT_ALL_TESTS
2803 select GET_FREE_REGION
2804 help
2805 This builds the resource API unit test.
2806 Tests the logic of API provided by resource.c and ioport.h.
2807 For more information on KUnit and unit tests in general please refer
2808 to the KUnit documentation in Documentation/dev-tools/kunit/.
2809
2810 If unsure, say N.
2811
2812config SYSCTL_KUNIT_TEST
2813 tristate "KUnit test for sysctl" if !KUNIT_ALL_TESTS
2814 depends on KUNIT
2815 default KUNIT_ALL_TESTS
2816 help
2817 This builds the proc sysctl unit test, which runs on boot.
2818 Tests the API contract and implementation correctness of sysctl.
2819 For more information on KUnit and unit tests in general please refer
2820 to the KUnit documentation in Documentation/dev-tools/kunit/.
2821
2822 If unsure, say N.
2823
2824config KFIFO_KUNIT_TEST
2825 tristate "KUnit Test for the generic kernel FIFO implementation" if !KUNIT_ALL_TESTS
2826 depends on KUNIT
2827 default KUNIT_ALL_TESTS
2828 help
2829 This builds the generic FIFO implementation KUnit test suite.
2830 It tests that the API and basic functionality of the kfifo type
2831 and associated macros.
2832
2833 For more information on KUnit and unit tests in general please refer
2834 to the KUnit documentation in Documentation/dev-tools/kunit/.
2835
2836 If unsure, say N.
2837
2838config LIST_KUNIT_TEST
2839 tristate "KUnit Test for Kernel Linked-list structures" if !KUNIT_ALL_TESTS
2840 depends on KUNIT
2841 default KUNIT_ALL_TESTS
2842 help
2843 This builds the linked list KUnit test suite.
2844 It tests that the API and basic functionality of the list_head type
2845 and associated macros.
2846
2847 KUnit tests run during boot and output the results to the debug log
2848 in TAP format (https://testanything.org/). Only useful for kernel devs
2849 running the KUnit test harness, and not intended for inclusion into a
2850 production build.
2851
2852 For more information on KUnit and unit tests in general please refer
2853 to the KUnit documentation in Documentation/dev-tools/kunit/.
2854
2855 If unsure, say N.
2856
2857config LIST_PRIVATE_KUNIT_TEST
2858 tristate "KUnit Test for Kernel Private Linked-list structures" if !KUNIT_ALL_TESTS
2859 depends on KUNIT
2860 default KUNIT_ALL_TESTS
2861 help
2862 This builds the KUnit test for the private linked-list primitives
2863 defined in include/linux/list_private.h.
2864
2865 These primitives allow manipulation of list_head members that are
2866 marked as private and require special accessors (ACCESS_PRIVATE)
2867 to strip qualifiers or handle encapsulation.
2868
2869 If unsure, say N.
2870
2871config HASHTABLE_KUNIT_TEST
2872 tristate "KUnit Test for Kernel Hashtable structures" if !KUNIT_ALL_TESTS
2873 depends on KUNIT
2874 default KUNIT_ALL_TESTS
2875 help
2876 This builds the hashtable KUnit test suite.
2877 It tests the basic functionality of the API defined in
2878 include/linux/hashtable.h. For more information on KUnit and
2879 unit tests in general please refer to the KUnit documentation
2880 in Documentation/dev-tools/kunit/.
2881
2882 If unsure, say N.
2883
2884config LINEAR_RANGES_TEST
2885 tristate "KUnit test for linear_ranges"
2886 depends on KUNIT
2887 select LINEAR_RANGES
2888 help
2889 This builds the linear_ranges unit test, which runs on boot.
2890 Tests the linear_ranges logic correctness.
2891 For more information on KUnit and unit tests in general please refer
2892 to the KUnit documentation in Documentation/dev-tools/kunit/.
2893
2894 If unsure, say N.
2895
2896config CONTEXT_ANALYSIS_TEST
2897 bool "Compiler context-analysis warnings test"
2898 depends on EXPERT
2899 help
2900 This builds the test for compiler-based context analysis. The test
2901 does not add executable code to the kernel, but is meant to test that
2902 common patterns supported by the analysis do not result in false
2903 positive warnings.
2904
2905 When adding support for new context locks, it is strongly recommended
2906 to add supported patterns to this test.
2907
2908 If unsure, say N.
2909
2910config LIVEUPDATE_TEST
2911 bool "Live Update Kernel Test"
2912 default n
2913 depends on LIVEUPDATE
2914 help
2915 Enable a built-in kernel test module for the Live Update
2916 Orchestrator.
2917
2918 This module validates the File-Lifecycle-Bound subsystem by
2919 registering a set of mock FLB objects with any real file handlers
2920 that support live update (such as the memfd handler).
2921
2922 When live update operations are performed, this test module will
2923 output messages to the kernel log (dmesg), confirming that its
2924 registration and various callback functions (preserve, retrieve,
2925 finish, etc.) are being invoked correctly.
2926
2927 This is a debugging and regression testing tool for developers
2928 working on the Live Update subsystem. It should not be enabled in
2929 production kernels.
2930
2931 If unsure, say N
2932
2933config CMDLINE_KUNIT_TEST
2934 tristate "KUnit test for cmdline API" if !KUNIT_ALL_TESTS
2935 depends on KUNIT
2936 default KUNIT_ALL_TESTS
2937 help
2938 This builds the cmdline API unit test.
2939 Tests the logic of API provided by cmdline.c.
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 BASE64_KUNIT
2946 tristate "KUnit test for base64 decoding and encoding" if !KUNIT_ALL_TESTS
2947 depends on KUNIT
2948 default KUNIT_ALL_TESTS
2949 help
2950 This builds the base64 unit tests.
2951
2952 The tests cover the encoding and decoding logic of Base64 functions
2953 in the kernel.
2954 In addition to correctness checks, simple performance benchmarks
2955 for both encoding and decoding are also included.
2956
2957 For more information on KUnit and unit tests in general please refer
2958 to the KUnit documentation in Documentation/dev-tools/kunit/.
2959
2960 If unsure, say N.
2961
2962config BITS_TEST
2963 tristate "KUnit test for bit functions and macros" if !KUNIT_ALL_TESTS
2964 depends on KUNIT
2965 default KUNIT_ALL_TESTS
2966 help
2967 This builds the bits unit test.
2968 Tests the logic of macros defined in bits.h.
2969 For more information on KUnit and unit tests in general please refer
2970 to the KUnit documentation in Documentation/dev-tools/kunit/.
2971
2972 If unsure, say N.
2973
2974config SLUB_KUNIT_TEST
2975 tristate "KUnit test for SLUB cache error detection" if !KUNIT_ALL_TESTS
2976 depends on SLUB_DEBUG && KUNIT
2977 default KUNIT_ALL_TESTS
2978 help
2979 This builds SLUB allocator unit test.
2980 Tests SLUB cache debugging functionality.
2981 For more information on KUnit and unit tests in general please refer
2982 to the KUnit documentation in Documentation/dev-tools/kunit/.
2983
2984 If unsure, say N.
2985
2986config RATIONAL_KUNIT_TEST
2987 tristate "KUnit test for rational.c" if !KUNIT_ALL_TESTS
2988 depends on KUNIT && RATIONAL
2989 default KUNIT_ALL_TESTS
2990 help
2991 This builds the rational math unit test.
2992 For more information on KUnit and unit tests in general please refer
2993 to the KUnit documentation in Documentation/dev-tools/kunit/.
2994
2995 If unsure, say N.
2996
2997config MEMCPY_KUNIT_TEST
2998 tristate "Test memcpy(), memmove(), and memset() functions at runtime" if !KUNIT_ALL_TESTS
2999 depends on KUNIT
3000 default KUNIT_ALL_TESTS
3001 help
3002 Builds unit tests for memcpy(), memmove(), and memset() functions.
3003 For more information on KUnit and unit tests in general please refer
3004 to the KUnit documentation in Documentation/dev-tools/kunit/.
3005
3006 If unsure, say N.
3007
3008config MIN_HEAP_KUNIT_TEST
3009 tristate "Min heap test" if !KUNIT_ALL_TESTS
3010 depends on KUNIT
3011 default KUNIT_ALL_TESTS
3012 help
3013 This option enables the KUnit test suite for the min heap library
3014 which provides functions for creating and managing min heaps.
3015 The test suite checks the functionality of the min heap library.
3016
3017 If unsure, say N
3018
3019config IS_SIGNED_TYPE_KUNIT_TEST
3020 tristate "Test is_signed_type() macro" if !KUNIT_ALL_TESTS
3021 depends on KUNIT
3022 default KUNIT_ALL_TESTS
3023 help
3024 Builds unit tests for the is_signed_type() macro.
3025
3026 For more information on KUnit and unit tests in general please refer
3027 to the KUnit documentation in Documentation/dev-tools/kunit/.
3028
3029 If unsure, say N.
3030
3031config OVERFLOW_KUNIT_TEST
3032 tristate "Test check_*_overflow() functions at runtime" if !KUNIT_ALL_TESTS
3033 depends on KUNIT
3034 default KUNIT_ALL_TESTS
3035 help
3036 Builds unit tests for the check_*_overflow(), size_*(), allocation, and
3037 related functions.
3038
3039 For more information on KUnit and unit tests in general please refer
3040 to the KUnit documentation in Documentation/dev-tools/kunit/.
3041
3042 If unsure, say N.
3043
3044config RANDSTRUCT_KUNIT_TEST
3045 tristate "Test randstruct structure layout randomization at runtime" if !KUNIT_ALL_TESTS
3046 depends on KUNIT
3047 default KUNIT_ALL_TESTS
3048 help
3049 Builds unit tests for the checking CONFIG_RANDSTRUCT=y, which
3050 randomizes structure layouts.
3051
3052config STACKINIT_KUNIT_TEST
3053 tristate "Test level of stack variable initialization" if !KUNIT_ALL_TESTS
3054 depends on KUNIT
3055 default KUNIT_ALL_TESTS
3056 help
3057 Test if the kernel is zero-initializing stack variables and
3058 padding. Coverage is controlled by compiler flags,
3059 CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_ALL_ZERO.
3060
3061config FORTIFY_KUNIT_TEST
3062 tristate "Test fortified str*() and mem*() function internals at runtime" if !KUNIT_ALL_TESTS
3063 depends on KUNIT
3064 default KUNIT_ALL_TESTS
3065 help
3066 Builds unit tests for checking internals of FORTIFY_SOURCE as used
3067 by the str*() and mem*() family of functions. For testing runtime
3068 traps of FORTIFY_SOURCE, see LKDTM's "FORTIFY_*" tests.
3069
3070config LONGEST_SYM_KUNIT_TEST
3071 tristate "Test the longest symbol possible" if !KUNIT_ALL_TESTS
3072 depends on KUNIT && KPROBES
3073 depends on !PREFIX_SYMBOLS && !CFI && !GCOV_KERNEL
3074 default KUNIT_ALL_TESTS
3075 help
3076 Tests the longest symbol possible
3077
3078 If unsure, say N.
3079
3080config HW_BREAKPOINT_KUNIT_TEST
3081 bool "Test hw_breakpoint constraints accounting" if !KUNIT_ALL_TESTS
3082 depends on HAVE_HW_BREAKPOINT
3083 depends on KUNIT=y
3084 default KUNIT_ALL_TESTS
3085 help
3086 Tests for hw_breakpoint constraints accounting.
3087
3088 If unsure, say N.
3089
3090source "lib/crypto/tests/Kconfig"
3091
3092config SIPHASH_KUNIT_TEST
3093 tristate "Perform selftest on siphash functions" if !KUNIT_ALL_TESTS
3094 depends on KUNIT
3095 default KUNIT_ALL_TESTS
3096 help
3097 Enable this option to test the kernel's siphash (<linux/siphash.h>) hash
3098 functions on boot (or module load).
3099
3100 This is intended to help people writing architecture-specific
3101 optimized versions. If unsure, say N.
3102
3103config USERCOPY_KUNIT_TEST
3104 tristate "KUnit Test for user/kernel boundary protections"
3105 depends on KUNIT
3106 default KUNIT_ALL_TESTS
3107 help
3108 This builds the "usercopy_kunit" module that runs sanity checks
3109 on the copy_to/from_user infrastructure, making sure basic
3110 user/kernel boundary testing is working.
3111
3112config BLACKHOLE_DEV_KUNIT_TEST
3113 tristate "Test blackhole netdev functionality" if !KUNIT_ALL_TESTS
3114 depends on NET
3115 depends on KUNIT
3116 default KUNIT_ALL_TESTS
3117 help
3118 This builds the "blackhole_dev_kunit" module that validates the
3119 data path through this blackhole netdev.
3120
3121 If unsure, say N.
3122
3123config TEST_UDELAY
3124 tristate "udelay test driver"
3125 help
3126 This builds the "udelay_test" module that helps to make sure
3127 that udelay() is working properly.
3128
3129 If unsure, say N.
3130
3131config TEST_STATIC_KEYS
3132 tristate "Test static keys"
3133 depends on m
3134 help
3135 Test the static key interfaces.
3136
3137 If unsure, say N.
3138
3139config TEST_DYNAMIC_DEBUG
3140 tristate "Test DYNAMIC_DEBUG"
3141 depends on DYNAMIC_DEBUG
3142 help
3143 This module registers a tracer callback to count enabled
3144 pr_debugs in a 'do_debugging' function, then alters their
3145 enablements, calls the function, and compares counts.
3146
3147 If unsure, say N.
3148
3149config TEST_KMOD
3150 tristate "kmod stress tester"
3151 depends on m
3152 select TEST_LKM
3153 help
3154 Test the kernel's module loading mechanism: kmod. kmod implements
3155 support to load modules using the Linux kernel's usermode helper.
3156 This test provides a series of tests against kmod.
3157
3158 Although technically you can either build test_kmod as a module or
3159 into the kernel we disallow building it into the kernel since
3160 it stress tests request_module() and this will very likely cause
3161 some issues by taking over precious threads available from other
3162 module load requests, ultimately this could be fatal.
3163
3164 To run tests run:
3165
3166 tools/testing/selftests/kmod/kmod.sh --help
3167
3168 If unsure, say N.
3169
3170config TEST_RUNTIME
3171 bool
3172
3173config TEST_RUNTIME_MODULE
3174 bool
3175
3176config TEST_KALLSYMS
3177 tristate "module kallsyms find_symbol() test"
3178 depends on m
3179 select TEST_RUNTIME
3180 select TEST_RUNTIME_MODULE
3181 select TEST_KALLSYMS_A
3182 select TEST_KALLSYMS_B
3183 select TEST_KALLSYMS_C
3184 select TEST_KALLSYMS_D
3185 help
3186 This allows us to stress test find_symbol() through the kallsyms
3187 used to place symbols on the kernel ELF kallsyms and modules kallsyms
3188 where we place kernel symbols such as exported symbols.
3189
3190 We have four test modules:
3191
3192 A: has KALLSYSMS_NUMSYMS exported symbols
3193 B: uses one of A's symbols
3194 C: adds KALLSYMS_SCALE_FACTOR * KALLSYSMS_NUMSYMS exported
3195 D: adds 2 * the symbols than C
3196
3197 We stress test find_symbol() through two means:
3198
3199 1) Upon load of B it will trigger simplify_symbols() to look for the
3200 one symbol it uses from the module A with tons of symbols. This is an
3201 indirect way for us to have B call resolve_symbol_wait() upon module
3202 load. This will eventually call find_symbol() which will eventually
3203 try to find the symbols used with find_exported_symbol_in_section().
3204 find_exported_symbol_in_section() uses bsearch() so a binary search
3205 for each symbol. Binary search will at worst be O(log(n)) so the
3206 larger TEST_MODULE_KALLSYSMS the worse the search.
3207
3208 2) The selftests should load C first, before B. Upon B's load towards
3209 the end right before we call module B's init routine we get
3210 complete_formation() called on the module. That will first check
3211 for duplicate symbols with the call to verify_exported_symbols().
3212 That is when we'll force iteration on module C's insane symbol list.
3213 Since it has 10 * KALLSYMS_NUMSYMS it means we can first test
3214 just loading B without C. The amount of time it takes to load C Vs
3215 B can give us an idea of the impact growth of the symbol space and
3216 give us projection. Module A only uses one symbol from B so to allow
3217 this scaling in module C to be proportional, if it used more symbols
3218 then the first test would be doing more and increasing just the
3219 search space would be slightly different. The last module, module D
3220 will just increase the search space by twice the number of symbols in
3221 C so to allow for full projects.
3222
3223 tools/testing/selftests/module/find_symbol.sh
3224
3225 The current defaults will incur a build delay of about 7 minutes
3226 on an x86_64 with only 8 cores. Enable this only if you want to
3227 stress test find_symbol() with thousands of symbols. At the same
3228 time this is also useful to test building modules with thousands of
3229 symbols, and if BTF is enabled this also stress tests adding BTF
3230 information for each module. Currently enabling many more symbols
3231 will segfault the build system.
3232
3233 If unsure, say N.
3234
3235if TEST_KALLSYMS
3236
3237config TEST_KALLSYMS_A
3238 tristate
3239 depends on m
3240
3241config TEST_KALLSYMS_B
3242 tristate
3243 depends on m
3244
3245config TEST_KALLSYMS_C
3246 tristate
3247 depends on m
3248
3249config TEST_KALLSYMS_D
3250 tristate
3251 depends on m
3252
3253choice
3254 prompt "Kallsym test range"
3255 default TEST_KALLSYMS_LARGE
3256 help
3257 Selecting something other than "Fast" will enable tests which slow
3258 down the build and may crash your build.
3259
3260config TEST_KALLSYMS_FAST
3261 bool "Fast builds"
3262 help
3263 You won't really be testing kallsysms, so this just helps fast builds
3264 when allmodconfig is used..
3265
3266config TEST_KALLSYMS_LARGE
3267 bool "Enable testing kallsyms with large exports"
3268 help
3269 This will enable larger number of symbols. This will slow down
3270 your build considerably.
3271
3272config TEST_KALLSYMS_MAX
3273 bool "Known kallsysms limits"
3274 help
3275 This will enable exports to the point we know we'll start crashing
3276 builds.
3277
3278endchoice
3279
3280config TEST_KALLSYMS_NUMSYMS
3281 int "test kallsyms number of symbols"
3282 range 2 10000
3283 default 2 if TEST_KALLSYMS_FAST
3284 default 100 if TEST_KALLSYMS_LARGE
3285 default 10000 if TEST_KALLSYMS_MAX
3286 help
3287 The number of symbols to create on TEST_KALLSYMS_A, only one of which
3288 module TEST_KALLSYMS_B will use. This also will be used
3289 for how many symbols TEST_KALLSYMS_C will have, scaled up by
3290 TEST_KALLSYMS_SCALE_FACTOR. Note that setting this to 10,000 will
3291 trigger a segfault today, don't use anything close to it unless
3292 you are aware that this should not be used for automated build tests.
3293
3294config TEST_KALLSYMS_SCALE_FACTOR
3295 int "test kallsyms scale factor"
3296 default 8
3297 help
3298 How many more unusued symbols will TEST_KALLSYSMS_C have than
3299 TEST_KALLSYMS_A. If 8, then module C will have 8 * syms
3300 than module A. Then TEST_KALLSYMS_D will have double the amount
3301 of symbols than C so to allow projections.
3302
3303endif # TEST_KALLSYMS
3304
3305config TEST_DEBUG_VIRTUAL
3306 tristate "Test CONFIG_DEBUG_VIRTUAL feature"
3307 depends on DEBUG_VIRTUAL
3308 help
3309 Test the kernel's ability to detect incorrect calls to
3310 virt_to_phys() done against the non-linear part of the
3311 kernel's virtual address map.
3312
3313 If unsure, say N.
3314
3315config TEST_MEMCAT_P
3316 tristate "Test memcat_p() helper function"
3317 help
3318 Test the memcat_p() helper for correctly merging two
3319 pointer arrays together.
3320
3321 If unsure, say N.
3322
3323config TEST_OBJAGG
3324 tristate "Perform selftest on object aggreration manager"
3325 default n
3326 depends on OBJAGG
3327 help
3328 Enable this option to test object aggregation manager on boot
3329 (or module load).
3330
3331config TEST_MEMINIT
3332 tristate "Test heap/page initialization"
3333 help
3334 Test if the kernel is zero-initializing heap and page allocations.
3335 This can be useful to test init_on_alloc and init_on_free features.
3336
3337 If unsure, say N.
3338
3339config TEST_HMM
3340 tristate "Test HMM (Heterogeneous Memory Management)"
3341 depends on TRANSPARENT_HUGEPAGE
3342 depends on DEVICE_PRIVATE
3343 select HMM_MIRROR
3344 select MMU_NOTIFIER
3345 help
3346 This is a pseudo device driver solely for testing HMM.
3347 Say M here if you want to build the HMM test module.
3348 Doing so will allow you to run tools/testing/selftest/vm/hmm-tests.
3349
3350 If unsure, say N.
3351
3352config TEST_FREE_PAGES
3353 tristate "Test freeing pages"
3354 help
3355 Test that a memory leak does not occur due to a race between
3356 freeing a block of pages and a speculative page reference.
3357 Loading this module is safe if your kernel has the bug fixed.
3358 If the bug is not fixed, it will leak gigabytes of memory and
3359 probably OOM your system.
3360
3361config TEST_FPU
3362 tristate "Test floating point operations in kernel space"
3363 depends on ARCH_HAS_KERNEL_FPU_SUPPORT && !KCOV_INSTRUMENT_ALL
3364 help
3365 Enable this option to add /sys/kernel/debug/selftest_helpers/test_fpu
3366 which will trigger a sequence of floating point operations. This is used
3367 for self-testing floating point control register setting in
3368 kernel_fpu_begin().
3369
3370 If unsure, say N.
3371
3372config TEST_CLOCKSOURCE_WATCHDOG
3373 tristate "Test clocksource watchdog in kernel space"
3374 depends on CLOCKSOURCE_WATCHDOG
3375 help
3376 Enable this option to create a kernel module that will trigger
3377 a test of the clocksource watchdog. This module may be loaded
3378 via modprobe or insmod in which case it will run upon being
3379 loaded, or it may be built in, in which case it will run
3380 shortly after boot.
3381
3382 If unsure, say N.
3383
3384config TEST_OBJPOOL
3385 tristate "Test module for correctness and stress of objpool"
3386 default n
3387 depends on m && DEBUG_KERNEL
3388 help
3389 This builds the "test_objpool" module that should be used for
3390 correctness verification and concurrent testings of objects
3391 allocation and reclamation.
3392
3393 If unsure, say N.
3394
3395config TEST_KEXEC_HANDOVER
3396 bool "Test for Kexec HandOver"
3397 default n
3398 depends on KEXEC_HANDOVER
3399 help
3400 This option enables test for Kexec HandOver (KHO).
3401 The test consists of two parts: saving kernel data before kexec and
3402 restoring the data after kexec and verifying that it was properly
3403 handed over. This test module creates and saves data on the boot of
3404 the first kernel and restores and verifies the data on the boot of
3405 kexec'ed kernel.
3406
3407 For detailed documentation about KHO, see Documentation/core-api/kho.
3408
3409 To run the test run:
3410
3411 tools/testing/selftests/kho/vmtest.sh -h
3412
3413 If unsure, say N.
3414
3415config RATELIMIT_KUNIT_TEST
3416 tristate "KUnit Test for correctness and stress of ratelimit" if !KUNIT_ALL_TESTS
3417 depends on KUNIT
3418 default KUNIT_ALL_TESTS
3419 help
3420 This builds the "test_ratelimit" module that should be used
3421 for correctness verification and concurrent testings of rate
3422 limiting.
3423
3424 If unsure, say N.
3425
3426config UUID_KUNIT_TEST
3427 tristate "KUnit test for UUID" if !KUNIT_ALL_TESTS
3428 depends on KUNIT
3429 default KUNIT_ALL_TESTS
3430 help
3431 This option enables the KUnit test suite for the uuid library,
3432 which provides functions for generating and parsing UUID and GUID.
3433 The test suite checks parsing of UUID and GUID strings.
3434
3435 If unsure, say N.
3436
3437config INT_POW_KUNIT_TEST
3438 tristate "Integer exponentiation (int_pow) 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_pow function,
3443 which performs integer exponentiation. The test suite is designed to
3444 verify that the implementation of int_pow correctly computes the power
3445 of a given base raised to a given exponent.
3446
3447 Enabling this option will include tests that check various scenarios
3448 and edge cases to ensure the accuracy and reliability of the exponentiation
3449 function.
3450
3451 If unsure, say N
3452
3453config INT_SQRT_KUNIT_TEST
3454 tristate "Integer square root test" if !KUNIT_ALL_TESTS
3455 depends on KUNIT
3456 default KUNIT_ALL_TESTS
3457 help
3458 This option enables the KUnit test suite for the int_sqrt() function,
3459 which performs square root calculation. The test suite checks
3460 various scenarios, including edge cases, to ensure correctness.
3461
3462 Enabling this option will include tests that check various scenarios
3463 and edge cases to ensure the accuracy and reliability of the square root
3464 function.
3465
3466 If unsure, say N
3467
3468config INT_LOG_KUNIT_TEST
3469 tristate "Integer log (int_log) test" if !KUNIT_ALL_TESTS
3470 depends on KUNIT
3471 default KUNIT_ALL_TESTS
3472 help
3473 This option enables the KUnit test suite for the int_log library, which
3474 provides two functions to compute the integer logarithm in base 2 and
3475 base 10, called respectively as intlog2 and intlog10.
3476
3477 If unsure, say N
3478
3479config GCD_KUNIT_TEST
3480 tristate "Greatest common divisor test" if !KUNIT_ALL_TESTS
3481 depends on KUNIT
3482 default KUNIT_ALL_TESTS
3483 help
3484 This option enables the KUnit test suite for the gcd() function,
3485 which computes the greatest common divisor of two numbers.
3486
3487 This test suite verifies the correctness of gcd() across various
3488 scenarios, including edge cases.
3489
3490 If unsure, say N
3491
3492config PRIME_NUMBERS_KUNIT_TEST
3493 tristate "Prime number generator test" if !KUNIT_ALL_TESTS
3494 depends on KUNIT
3495 depends on PRIME_NUMBERS
3496 default KUNIT_ALL_TESTS
3497 help
3498 This option enables the KUnit test suite for the {is,next}_prime_number
3499 functions.
3500
3501 Enabling this option will include tests that compare the prime number
3502 generator functions against a brute force implementation.
3503
3504 If unsure, say N
3505
3506config GLOB_KUNIT_TEST
3507 tristate "Glob matching test" if !KUNIT_ALL_TESTS
3508 depends on GLOB
3509 depends on KUNIT
3510 default KUNIT_ALL_TESTS
3511 help
3512 Enable this option to test the glob functions at runtime.
3513
3514 This test suite verifies the correctness of glob_match() across various
3515 scenarios, including edge cases.
3516
3517 If unsure, say N
3518
3519endif # RUNTIME_TESTING_MENU
3520
3521config ARCH_USE_MEMTEST
3522 bool
3523 help
3524 An architecture should select this when it uses early_memtest()
3525 during boot process.
3526
3527config MEMTEST
3528 bool "Memtest"
3529 depends on ARCH_USE_MEMTEST
3530 help
3531 This option adds a kernel parameter 'memtest', which allows memtest
3532 to be set and executed.
3533 memtest=0, mean disabled; -- default
3534 memtest=1, mean do 1 test pattern;
3535 ...
3536 memtest=17, mean do 17 test patterns.
3537 If you are unsure how to answer this question, answer N.
3538
3539
3540
3541config HYPERV_TESTING
3542 bool "Microsoft Hyper-V driver testing"
3543 default n
3544 depends on HYPERV && DEBUG_FS
3545 help
3546 Select this option to enable Hyper-V vmbus testing.
3547
3548endmenu # "Kernel Testing and Coverage"
3549
3550menu "Rust hacking"
3551
3552config RUST_DEBUG_ASSERTIONS
3553 bool "Debug assertions"
3554 depends on RUST
3555 help
3556 Enables rustc's `-Cdebug-assertions` codegen option.
3557
3558 This flag lets you turn `cfg(debug_assertions)` conditional
3559 compilation on or off. This can be used to enable extra debugging
3560 code in development but not in production. For example, it controls
3561 the behavior of the standard library's `debug_assert!` macro.
3562
3563 Note that this will apply to all Rust code, including `core`.
3564
3565 If unsure, say N.
3566
3567config RUST_OVERFLOW_CHECKS
3568 bool "Overflow checks"
3569 default y
3570 depends on RUST
3571 help
3572 Enables rustc's `-Coverflow-checks` codegen option.
3573
3574 This flag allows you to control the behavior of runtime integer
3575 overflow. When overflow-checks are enabled, a Rust panic will occur
3576 on overflow.
3577
3578 Note that this will apply to all Rust code, including `core`.
3579
3580 If unsure, say Y.
3581
3582config RUST_BUILD_ASSERT_ALLOW
3583 bool "Allow unoptimized build-time assertions"
3584 depends on RUST
3585 help
3586 Controls how `build_error!` and `build_assert!` are handled during the build.
3587
3588 If calls to them exist in the binary, it may indicate a violated invariant
3589 or that the optimizer failed to verify the invariant during compilation.
3590
3591 This should not happen, thus by default the build is aborted. However,
3592 as an escape hatch, you can choose Y here to ignore them during build
3593 and let the check be carried at runtime (with `panic!` being called if
3594 the check fails).
3595
3596 If unsure, say N.
3597
3598config RUST_KERNEL_DOCTESTS
3599 bool "Doctests for the `kernel` crate" if !KUNIT_ALL_TESTS
3600 depends on RUST && KUNIT=y
3601 default KUNIT_ALL_TESTS
3602 help
3603 This builds the documentation tests of the `kernel` crate
3604 as KUnit tests.
3605
3606 For more information on KUnit and unit tests in general,
3607 please refer to the KUnit documentation in Documentation/dev-tools/kunit/.
3608
3609 If unsure, say N.
3610
3611config RUST_INLINE_HELPERS
3612 bool "Inline C helpers into Rust code (EXPERIMENTAL)"
3613 depends on RUST && RUSTC_CLANG_LLVM_COMPATIBLE
3614 depends on EXPERT
3615 depends on ARM64 || X86_64
3616 depends on !UML
3617 help
3618 Inlines C helpers into Rust code using Link Time Optimization.
3619
3620 If this option is enabled, C helper functions declared in
3621 rust/helpers/ are inlined into Rust code, which is helpful for
3622 performance of Rust code. This requires a matching LLVM version for
3623 Clang and rustc.
3624
3625 If you are sure that you're using Clang and rustc with matching LLVM
3626 versions, say Y. Otherwise say N.
3627
3628endmenu # "Rust"
3629
3630endmenu # Kernel hacking