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 >= 220000
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 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 DEBUG_KERNEL
764 help
765 If you say Y here, additional code will be inserted into the
766 kernel to track the life time of various objects and validate
767 the operations on those objects.
768
769config DEBUG_OBJECTS_SELFTEST
770 bool "Debug objects selftest"
771 depends on DEBUG_OBJECTS
772 help
773 This enables the selftest of the object debug code.
774
775config DEBUG_OBJECTS_FREE
776 bool "Debug objects in freed memory"
777 depends on DEBUG_OBJECTS
778 help
779 This enables checks whether a k/v free operation frees an area
780 which contains an object which has not been deactivated
781 properly. This can make kmalloc/kfree-intensive workloads
782 much slower.
783
784config DEBUG_OBJECTS_TIMERS
785 bool "Debug timer objects"
786 depends on DEBUG_OBJECTS
787 help
788 If you say Y here, additional code will be inserted into the
789 timer routines to track the life time of timer objects and
790 validate the timer operations.
791
792config DEBUG_OBJECTS_WORK
793 bool "Debug work objects"
794 depends on DEBUG_OBJECTS
795 help
796 If you say Y here, additional code will be inserted into the
797 work queue routines to track the life time of work objects and
798 validate the work operations.
799
800config DEBUG_OBJECTS_RCU_HEAD
801 bool "Debug RCU callbacks objects"
802 depends on DEBUG_OBJECTS
803 help
804 Enable this to turn on debugging of RCU list heads (call_rcu() usage).
805
806config DEBUG_OBJECTS_PERCPU_COUNTER
807 bool "Debug percpu counter objects"
808 depends on DEBUG_OBJECTS
809 help
810 If you say Y here, additional code will be inserted into the
811 percpu counter routines to track the life time of percpu counter
812 objects and validate the percpu counter operations.
813
814config DEBUG_OBJECTS_ENABLE_DEFAULT
815 int "debug_objects bootup default value (0-1)"
816 range 0 1
817 default "1"
818 depends on DEBUG_OBJECTS
819 help
820 Debug objects boot parameter default value
821
822config SHRINKER_DEBUG
823 bool "Enable shrinker debugging support"
824 depends on DEBUG_FS
825 help
826 Say Y to enable the shrinker debugfs interface which provides
827 visibility into the kernel memory shrinkers subsystem.
828 Disable it to avoid an extra memory footprint.
829
830config DEBUG_STACK_USAGE
831 bool "Stack utilization instrumentation"
832 depends on DEBUG_KERNEL
833 help
834 Enables the display of the minimum amount of free stack which each
835 task has ever had available in the sysrq-T and sysrq-P debug output.
836 Also emits a message to dmesg when a process exits if that process
837 used more stack space than previously exiting processes.
838
839 This option will slow down process creation somewhat.
840
841config SCHED_STACK_END_CHECK
842 bool "Detect stack corruption on calls to schedule()"
843 depends on DEBUG_KERNEL
844 default n
845 help
846 This option checks for a stack overrun on calls to schedule().
847 If the stack end location is found to be over written always panic as
848 the content of the corrupted region can no longer be trusted.
849 This is to ensure no erroneous behaviour occurs which could result in
850 data corruption or a sporadic crash at a later stage once the region
851 is examined. The runtime overhead introduced is minimal.
852
853config ARCH_HAS_DEBUG_VM_PGTABLE
854 bool
855 help
856 An architecture should select this when it can successfully
857 build and run DEBUG_VM_PGTABLE.
858
859config DEBUG_VFS
860 bool "Debug VFS"
861 depends on DEBUG_KERNEL
862 help
863 Enable this to turn on extended checks in the VFS layer that may impact
864 performance.
865
866 If unsure, say N.
867
868config DEBUG_VM_IRQSOFF
869 def_bool DEBUG_VM && !PREEMPT_RT
870
871config DEBUG_VM
872 bool "Debug VM"
873 depends on DEBUG_KERNEL
874 help
875 Enable this to turn on extended checks in the virtual-memory system
876 that may impact performance.
877
878 If unsure, say N.
879
880config DEBUG_VM_SHOOT_LAZIES
881 bool "Debug MMU_LAZY_TLB_SHOOTDOWN implementation"
882 depends on DEBUG_VM
883 depends on MMU_LAZY_TLB_SHOOTDOWN
884 help
885 Enable additional IPIs that ensure lazy tlb mm references are removed
886 before the mm is freed.
887
888 If unsure, say N.
889
890config DEBUG_VM_MAPLE_TREE
891 bool "Debug VM maple trees"
892 depends on DEBUG_VM
893 select DEBUG_MAPLE_TREE
894 help
895 Enable VM maple tree debugging information and extra validations.
896
897 If unsure, say N.
898
899config DEBUG_VM_RB
900 bool "Debug VM red-black trees"
901 depends on DEBUG_VM
902 help
903 Enable VM red-black tree debugging information and extra validations.
904
905 If unsure, say N.
906
907config DEBUG_VM_PGFLAGS
908 bool "Debug page-flags operations"
909 depends on DEBUG_VM
910 help
911 Enables extra validation on page flags operations.
912
913 If unsure, say N.
914
915config DEBUG_VM_PGTABLE
916 bool "Debug arch page table for semantics compliance"
917 depends on MMU
918 depends on ARCH_HAS_DEBUG_VM_PGTABLE
919 default y if DEBUG_VM
920 help
921 This option provides a debug method which can be used to test
922 architecture page table helper functions on various platforms in
923 verifying if they comply with expected generic MM semantics. This
924 will help architecture code in making sure that any changes or
925 new additions of these helpers still conform to expected
926 semantics of the generic MM. Platforms will have to opt in for
927 this through ARCH_HAS_DEBUG_VM_PGTABLE.
928
929 If unsure, say N.
930
931config ARCH_HAS_DEBUG_VIRTUAL
932 bool
933
934config DEBUG_VIRTUAL
935 bool "Debug VM translations"
936 depends on DEBUG_KERNEL && ARCH_HAS_DEBUG_VIRTUAL
937 help
938 Enable some costly sanity checks in virtual to page code. This can
939 catch mistakes with virt_to_page() and friends.
940
941 If unsure, say N.
942
943config DEBUG_NOMMU_REGIONS
944 bool "Debug the global anon/private NOMMU mapping region tree"
945 depends on DEBUG_KERNEL && !MMU
946 help
947 This option causes the global tree of anonymous and private mapping
948 regions to be regularly checked for invalid topology.
949
950config DEBUG_MEMORY_INIT
951 bool "Debug memory initialisation" if EXPERT
952 default !EXPERT
953 help
954 Enable this for additional checks during memory initialisation.
955 The sanity checks verify aspects of the VM such as the memory model
956 and other information provided by the architecture. Verbose
957 information will be printed at KERN_DEBUG loglevel depending
958 on the mminit_loglevel= command-line option.
959
960 If unsure, say Y
961
962config MEMORY_NOTIFIER_ERROR_INJECT
963 tristate "Memory hotplug notifier error injection module"
964 depends on MEMORY_HOTPLUG && NOTIFIER_ERROR_INJECTION
965 help
966 This option provides the ability to inject artificial errors to
967 memory hotplug notifier chain callbacks. It is controlled through
968 debugfs interface under /sys/kernel/debug/notifier-error-inject/memory
969
970 If the notifier call chain should be failed with some events
971 notified, write the error code to "actions/<notifier event>/error".
972
973 Example: Inject memory hotplug offline error (-12 == -ENOMEM)
974
975 # cd /sys/kernel/debug/notifier-error-inject/memory
976 # echo -12 > actions/MEM_GOING_OFFLINE/error
977 # echo offline > /sys/devices/system/memory/memoryXXX/state
978 bash: echo: write error: Cannot allocate memory
979
980 To compile this code as a module, choose M here: the module will
981 be called memory-notifier-error-inject.
982
983 If unsure, say N.
984
985config DEBUG_PER_CPU_MAPS
986 bool "Debug access to per_cpu maps"
987 depends on DEBUG_KERNEL
988 depends on SMP
989 help
990 Say Y to verify that the per_cpu map being accessed has
991 been set up. This adds a fair amount of code to kernel memory
992 and decreases performance.
993
994 Say N if unsure.
995
996config DEBUG_KMAP_LOCAL
997 bool "Debug kmap_local temporary mappings"
998 depends on DEBUG_KERNEL && KMAP_LOCAL
999 help
1000 This option enables additional error checking for the kmap_local
1001 infrastructure. Disable for production use.
1002
1003config ARCH_SUPPORTS_KMAP_LOCAL_FORCE_MAP
1004 bool
1005
1006config DEBUG_KMAP_LOCAL_FORCE_MAP
1007 bool "Enforce kmap_local temporary mappings"
1008 depends on DEBUG_KERNEL && ARCH_SUPPORTS_KMAP_LOCAL_FORCE_MAP
1009 select KMAP_LOCAL
1010 select DEBUG_KMAP_LOCAL
1011 help
1012 This option enforces temporary mappings through the kmap_local
1013 mechanism for non-highmem pages and on non-highmem systems.
1014 Disable this for production systems!
1015
1016config DEBUG_HIGHMEM
1017 bool "Highmem debugging"
1018 depends on DEBUG_KERNEL && HIGHMEM
1019 select DEBUG_KMAP_LOCAL_FORCE_MAP if ARCH_SUPPORTS_KMAP_LOCAL_FORCE_MAP
1020 select DEBUG_KMAP_LOCAL
1021 help
1022 This option enables additional error checking for high memory
1023 systems. Disable for production systems.
1024
1025config HAVE_DEBUG_STACKOVERFLOW
1026 bool
1027
1028config DEBUG_STACKOVERFLOW
1029 bool "Check for stack overflows"
1030 depends on DEBUG_KERNEL && HAVE_DEBUG_STACKOVERFLOW
1031 help
1032 Say Y here if you want to check for overflows of kernel, IRQ
1033 and exception stacks (if your architecture uses them). This
1034 option will show detailed messages if free stack space drops
1035 below a certain limit.
1036
1037 These kinds of bugs usually occur when call-chains in the
1038 kernel get too deep, especially when interrupts are
1039 involved.
1040
1041 Use this in cases where you see apparently random memory
1042 corruption, especially if it appears in 'struct thread_info'
1043
1044 If in doubt, say "N".
1045
1046config CODE_TAGGING
1047 bool
1048 select KALLSYMS
1049
1050config MEM_ALLOC_PROFILING
1051 bool "Enable memory allocation profiling"
1052 default n
1053 depends on MMU
1054 depends on PROC_FS
1055 depends on !DEBUG_FORCE_WEAK_PER_CPU
1056 select CODE_TAGGING
1057 select PAGE_EXTENSION
1058 select SLAB_OBJ_EXT
1059 help
1060 Track allocation source code and record total allocation size
1061 initiated at that code location. The mechanism can be used to track
1062 memory leaks with a low performance and memory impact.
1063
1064config MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT
1065 bool "Enable memory allocation profiling by default"
1066 default y
1067 depends on MEM_ALLOC_PROFILING
1068
1069config MEM_ALLOC_PROFILING_DEBUG
1070 bool "Memory allocation profiler debugging"
1071 default n
1072 depends on MEM_ALLOC_PROFILING
1073 select MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT
1074 help
1075 Adds warnings with helpful error messages for memory allocation
1076 profiling.
1077
1078source "lib/Kconfig.kasan"
1079source "lib/Kconfig.kfence"
1080source "lib/Kconfig.kmsan"
1081
1082endmenu # "Memory Debugging"
1083
1084config DEBUG_SHIRQ
1085 bool "Debug shared IRQ handlers"
1086 depends on DEBUG_KERNEL
1087 help
1088 Enable this to generate a spurious interrupt just before a shared
1089 interrupt handler is deregistered (generating one when registering
1090 is currently disabled). Drivers need to handle this correctly. Some
1091 don't and need to be caught.
1092
1093menu "Debug Oops, Lockups and Hangs"
1094
1095config PANIC_ON_OOPS
1096 bool "Panic on Oops"
1097 help
1098 Say Y here to enable the kernel to panic when it oopses. This
1099 has the same effect as setting oops=panic on the kernel command
1100 line.
1101
1102 This feature is useful to ensure that the kernel does not do
1103 anything erroneous after an oops which could result in data
1104 corruption or other issues.
1105
1106 Say N if unsure.
1107
1108config PANIC_TIMEOUT
1109 int "panic timeout"
1110 default 0
1111 help
1112 Set the timeout value (in seconds) until a reboot occurs when
1113 the kernel panics. If n = 0, then we wait forever. A timeout
1114 value n > 0 will wait n seconds before rebooting, while a timeout
1115 value n < 0 will reboot immediately. This setting can be overridden
1116 with the kernel command line option panic=, and from userspace via
1117 /proc/sys/kernel/panic.
1118
1119config LOCKUP_DETECTOR
1120 bool
1121
1122config SOFTLOCKUP_DETECTOR
1123 bool "Detect Soft Lockups"
1124 depends on DEBUG_KERNEL && !S390
1125 select LOCKUP_DETECTOR
1126 help
1127 Say Y here to enable the kernel to act as a watchdog to detect
1128 soft lockups.
1129
1130 Softlockups are bugs that cause the kernel to loop in kernel
1131 mode for more than 20 seconds, without giving other tasks a
1132 chance to run. The current stack trace is displayed upon
1133 detection and the system will stay locked up.
1134
1135config SOFTLOCKUP_DETECTOR_INTR_STORM
1136 bool "Detect Interrupt Storm in Soft Lockups"
1137 depends on SOFTLOCKUP_DETECTOR && IRQ_TIME_ACCOUNTING
1138 select GENERIC_IRQ_STAT_SNAPSHOT
1139 default y if NR_CPUS <= 128
1140 help
1141 Say Y here to enable the kernel to detect interrupt storm
1142 during "soft lockups".
1143
1144 "soft lockups" can be caused by a variety of reasons. If one is
1145 caused by an interrupt storm, then the storming interrupts will not
1146 be on the callstack. To detect this case, it is necessary to report
1147 the CPU stats and the interrupt counts during the "soft lockups".
1148
1149config BOOTPARAM_SOFTLOCKUP_PANIC
1150 int "Panic (Reboot) On Soft Lockups"
1151 depends on SOFTLOCKUP_DETECTOR
1152 default 0
1153 help
1154 Set to a non-zero value N to enable the kernel to panic on "soft
1155 lockups", which are bugs that cause the kernel to loop in kernel
1156 mode for more than (N * 20 seconds) (configurable using the
1157 watchdog_thresh sysctl), without giving other tasks a chance to run.
1158
1159 The panic can be used in combination with panic_timeout,
1160 to cause the system to reboot automatically after a
1161 lockup has been detected. This feature is useful for
1162 high-availability systems that have uptime guarantees and
1163 where a lockup must be resolved ASAP.
1164
1165 Say 0 if unsure.
1166
1167config HAVE_HARDLOCKUP_DETECTOR_BUDDY
1168 bool
1169 depends on SMP
1170 default y
1171
1172#
1173# Global switch whether to build a hardlockup detector at all. It is available
1174# only when the architecture supports at least one implementation. There are
1175# two exceptions. The hardlockup detector is never enabled on:
1176#
1177# s390: it reported many false positives there
1178#
1179# sparc64: has a custom implementation which is not using the common
1180# hardlockup command line options and sysctl interface.
1181#
1182config HARDLOCKUP_DETECTOR
1183 bool "Detect Hard Lockups"
1184 depends on DEBUG_KERNEL && !S390 && !HARDLOCKUP_DETECTOR_SPARC64
1185 depends on HAVE_HARDLOCKUP_DETECTOR_PERF || HAVE_HARDLOCKUP_DETECTOR_BUDDY || HAVE_HARDLOCKUP_DETECTOR_ARCH
1186 imply HARDLOCKUP_DETECTOR_PERF
1187 imply HARDLOCKUP_DETECTOR_BUDDY
1188 imply HARDLOCKUP_DETECTOR_ARCH
1189 select LOCKUP_DETECTOR
1190
1191 help
1192 Say Y here to enable the kernel to act as a watchdog to detect
1193 hard lockups.
1194
1195 Hardlockups are bugs that cause the CPU to loop in kernel mode
1196 for more than 10 seconds, without letting other interrupts have a
1197 chance to run. The current stack trace is displayed upon detection
1198 and the system will stay locked up.
1199
1200#
1201# Note that arch-specific variants are always preferred.
1202#
1203config HARDLOCKUP_DETECTOR_PREFER_BUDDY
1204 bool "Prefer the buddy CPU hardlockup detector"
1205 depends on HARDLOCKUP_DETECTOR
1206 depends on HAVE_HARDLOCKUP_DETECTOR_PERF && HAVE_HARDLOCKUP_DETECTOR_BUDDY
1207 depends on !HAVE_HARDLOCKUP_DETECTOR_ARCH
1208 help
1209 Say Y here to prefer the buddy hardlockup detector over the perf one.
1210
1211 With the buddy detector, each CPU uses its softlockup hrtimer
1212 to check that the next CPU is processing hrtimer interrupts by
1213 verifying that a counter is increasing.
1214
1215 This hardlockup detector is useful on systems that don't have
1216 an arch-specific hardlockup detector or if resources needed
1217 for the hardlockup detector are better used for other things.
1218
1219config HARDLOCKUP_DETECTOR_PERF
1220 bool
1221 depends on HARDLOCKUP_DETECTOR
1222 depends on HAVE_HARDLOCKUP_DETECTOR_PERF && !HARDLOCKUP_DETECTOR_PREFER_BUDDY
1223 depends on !HAVE_HARDLOCKUP_DETECTOR_ARCH
1224 select HARDLOCKUP_DETECTOR_COUNTS_HRTIMER
1225
1226config HARDLOCKUP_DETECTOR_BUDDY
1227 bool
1228 depends on HARDLOCKUP_DETECTOR
1229 depends on HAVE_HARDLOCKUP_DETECTOR_BUDDY
1230 depends on !HAVE_HARDLOCKUP_DETECTOR_PERF || HARDLOCKUP_DETECTOR_PREFER_BUDDY
1231 depends on !HAVE_HARDLOCKUP_DETECTOR_ARCH
1232 select HARDLOCKUP_DETECTOR_COUNTS_HRTIMER
1233
1234config HARDLOCKUP_DETECTOR_ARCH
1235 bool
1236 depends on HARDLOCKUP_DETECTOR
1237 depends on HAVE_HARDLOCKUP_DETECTOR_ARCH
1238 help
1239 The arch-specific implementation of the hardlockup detector will
1240 be used.
1241
1242#
1243# Both the "perf" and "buddy" hardlockup detectors count hrtimer
1244# interrupts. This config enables functions managing this common code.
1245#
1246config HARDLOCKUP_DETECTOR_COUNTS_HRTIMER
1247 bool
1248 select SOFTLOCKUP_DETECTOR
1249
1250#
1251# Enables a timestamp based low pass filter to compensate for perf based
1252# hard lockup detection which runs too fast due to turbo modes.
1253#
1254config HARDLOCKUP_CHECK_TIMESTAMP
1255 bool
1256
1257config BOOTPARAM_HARDLOCKUP_PANIC
1258 bool "Panic (Reboot) On Hard Lockups"
1259 depends on HARDLOCKUP_DETECTOR
1260 help
1261 Say Y here to enable the kernel to panic on "hard lockups",
1262 which are bugs that cause the kernel to loop in kernel
1263 mode with interrupts disabled for more than 10 seconds (configurable
1264 using the watchdog_thresh sysctl).
1265
1266 Say N if unsure.
1267
1268config DETECT_HUNG_TASK
1269 bool "Detect Hung Tasks"
1270 depends on DEBUG_KERNEL
1271 default SOFTLOCKUP_DETECTOR
1272 help
1273 Say Y here to enable the kernel to detect "hung tasks",
1274 which are bugs that cause the task to be stuck in
1275 uninterruptible "D" state indefinitely.
1276
1277 When a hung task is detected, the kernel will print the
1278 current stack trace (which you should report), but the
1279 task will stay in uninterruptible state. If lockdep is
1280 enabled then all held locks will also be reported. This
1281 feature has negligible overhead.
1282
1283config DEFAULT_HUNG_TASK_TIMEOUT
1284 int "Default timeout for hung task detection (in seconds)"
1285 depends on DETECT_HUNG_TASK
1286 default 120
1287 help
1288 This option controls the default timeout (in seconds) used
1289 to determine when a task has become non-responsive and should
1290 be considered hung.
1291
1292 It can be adjusted at runtime via the kernel.hung_task_timeout_secs
1293 sysctl or by writing a value to
1294 /proc/sys/kernel/hung_task_timeout_secs.
1295
1296 A timeout of 0 disables the check. The default is two minutes.
1297 Keeping the default should be fine in most cases.
1298
1299config BOOTPARAM_HUNG_TASK_PANIC
1300 int "Number of hung tasks to trigger kernel panic"
1301 depends on DETECT_HUNG_TASK
1302 default 0
1303 help
1304 When set to a non-zero value, a kernel panic will be triggered
1305 if the number of hung tasks found during a single scan reaches
1306 this value.
1307
1308 The panic can be used in combination with panic_timeout,
1309 to cause the system to reboot automatically after a
1310 hung task has been detected. This feature is useful for
1311 high-availability systems that have uptime guarantees and
1312 where a hung tasks must be resolved ASAP.
1313
1314 Say 0 if unsure.
1315
1316config DETECT_HUNG_TASK_BLOCKER
1317 bool "Dump Hung Tasks Blocker"
1318 depends on DETECT_HUNG_TASK
1319 depends on !PREEMPT_RT
1320 default y
1321 help
1322 Say Y here to show the blocker task's stacktrace who acquires
1323 the mutex lock which "hung tasks" are waiting.
1324 This will add overhead a bit but shows suspicious tasks and
1325 call trace if it comes from waiting a mutex.
1326
1327config WQ_WATCHDOG
1328 bool "Detect Workqueue Stalls"
1329 depends on DEBUG_KERNEL
1330 help
1331 Say Y here to enable stall detection on workqueues. If a
1332 worker pool doesn't make forward progress on a pending work
1333 item for over a given amount of time, 30s by default, a
1334 warning message is printed along with dump of workqueue
1335 state. This can be configured through kernel parameter
1336 "workqueue.watchdog_thresh" and its sysfs counterpart.
1337
1338config BOOTPARAM_WQ_STALL_PANIC
1339 int "Panic on Nth workqueue stall"
1340 default 0
1341 range 0 100
1342 depends on WQ_WATCHDOG
1343 help
1344 Set the number of workqueue stalls to trigger a kernel panic.
1345 A workqueue stall occurs when a worker pool doesn't make forward
1346 progress on a pending work item for over 30 seconds (configurable
1347 using the workqueue.watchdog_thresh parameter).
1348
1349 If n = 0, the kernel will not panic on stall. If n > 0, the kernel
1350 will panic after n stall warnings.
1351
1352 The panic can be used in combination with panic_timeout,
1353 to cause the system to reboot automatically after a
1354 stall has been detected. This feature is useful for
1355 high-availability systems that have uptime guarantees and
1356 where a stall must be resolved ASAP.
1357
1358 This setting can be overridden at runtime via the
1359 workqueue.panic_on_stall kernel parameter.
1360
1361config WQ_CPU_INTENSIVE_REPORT
1362 bool "Report per-cpu work items which hog CPU for too long"
1363 depends on DEBUG_KERNEL
1364 help
1365 Say Y here to enable reporting of concurrency-managed per-cpu work
1366 items that hog CPUs for longer than
1367 workqueue.cpu_intensive_thresh_us. Workqueue automatically
1368 detects and excludes them from concurrency management to prevent
1369 them from stalling other per-cpu work items. Occassional
1370 triggering may not necessarily indicate a problem. Repeated
1371 triggering likely indicates that the work item should be switched
1372 to use an unbound workqueue.
1373
1374config TEST_LOCKUP
1375 tristate "Test module to generate lockups"
1376 depends on m
1377 help
1378 This builds the "test_lockup" module that helps to make sure
1379 that watchdogs and lockup detectors are working properly.
1380
1381 Depending on module parameters it could emulate soft or hard
1382 lockup, "hung task", or locking arbitrary lock for a long time.
1383 Also it could generate series of lockups with cooling-down periods.
1384
1385 If unsure, say N.
1386
1387endmenu # "Debug lockups and hangs"
1388
1389menu "Scheduler Debugging"
1390
1391config SCHED_INFO
1392 bool
1393 default n
1394
1395config SCHEDSTATS
1396 bool "Collect scheduler statistics"
1397 depends on PROC_FS
1398 select SCHED_INFO
1399 help
1400 If you say Y here, additional code will be inserted into the
1401 scheduler and related routines to collect statistics about
1402 scheduler behavior and provide them in /proc/schedstat. These
1403 stats may be useful for both tuning and debugging the scheduler
1404 If you aren't debugging the scheduler or trying to tune a specific
1405 application, you can say N to avoid the very slight overhead
1406 this adds.
1407
1408endmenu
1409
1410config DEBUG_PREEMPT
1411 bool "Debug preemptible kernel"
1412 depends on DEBUG_KERNEL && PREEMPTION && TRACE_IRQFLAGS_SUPPORT
1413 help
1414 If you say Y here then the kernel will use a debug variant of the
1415 commonly used smp_processor_id() function and will print warnings
1416 if kernel code uses it in a preemption-unsafe way. Also, the kernel
1417 will detect preemption count underflows.
1418
1419 This option has potential to introduce high runtime overhead,
1420 depending on workload as it triggers debugging routines for each
1421 this_cpu operation. It should only be used for debugging purposes.
1422
1423config DEBUG_ATOMIC
1424 bool "Debug atomic variables"
1425 depends on DEBUG_KERNEL
1426 help
1427 If you say Y here then the kernel will add a runtime alignment check
1428 to atomic accesses. Useful for architectures that do not have trap on
1429 mis-aligned access.
1430
1431 This option has potentially significant overhead.
1432
1433config DEBUG_ATOMIC_LARGEST_ALIGN
1434 bool "Check alignment only up to __aligned_largest"
1435 depends on DEBUG_ATOMIC
1436 help
1437 If you say Y here then the check for natural alignment of
1438 atomic accesses will be constrained to the compiler's largest
1439 alignment for scalar types.
1440
1441menu "Lock Debugging (spinlocks, mutexes, etc...)"
1442
1443config LOCK_DEBUGGING_SUPPORT
1444 bool
1445 depends on TRACE_IRQFLAGS_SUPPORT && STACKTRACE_SUPPORT && LOCKDEP_SUPPORT
1446 default y
1447
1448config PROVE_LOCKING
1449 bool "Lock debugging: prove locking correctness"
1450 depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
1451 select LOCKDEP
1452 select DEBUG_SPINLOCK
1453 select DEBUG_MUTEXES if !PREEMPT_RT
1454 select DEBUG_RT_MUTEXES if RT_MUTEXES
1455 select DEBUG_RWSEMS if !PREEMPT_RT
1456 select DEBUG_WW_MUTEX_SLOWPATH
1457 select DEBUG_LOCK_ALLOC
1458 select PREEMPT_COUNT if !ARCH_NO_PREEMPT
1459 select TRACE_IRQFLAGS
1460 default n
1461 help
1462 This feature enables the kernel to prove that all locking
1463 that occurs in the kernel runtime is mathematically
1464 correct: that under no circumstance could an arbitrary (and
1465 not yet triggered) combination of observed locking
1466 sequences (on an arbitrary number of CPUs, running an
1467 arbitrary number of tasks and interrupt contexts) cause a
1468 deadlock.
1469
1470 In short, this feature enables the kernel to report locking
1471 related deadlocks before they actually occur.
1472
1473 The proof does not depend on how hard and complex a
1474 deadlock scenario would be to trigger: how many
1475 participant CPUs, tasks and irq-contexts would be needed
1476 for it to trigger. The proof also does not depend on
1477 timing: if a race and a resulting deadlock is possible
1478 theoretically (no matter how unlikely the race scenario
1479 is), it will be proven so and will immediately be
1480 reported by the kernel (once the event is observed that
1481 makes the deadlock theoretically possible).
1482
1483 If a deadlock is impossible (i.e. the locking rules, as
1484 observed by the kernel, are mathematically correct), the
1485 kernel reports nothing.
1486
1487 NOTE: this feature can also be enabled for rwlocks, mutexes
1488 and rwsems - in which case all dependencies between these
1489 different locking variants are observed and mapped too, and
1490 the proof of observed correctness is also maintained for an
1491 arbitrary combination of these separate locking variants.
1492
1493 For more details, see Documentation/locking/lockdep-design.rst.
1494
1495config PROVE_RAW_LOCK_NESTING
1496 bool "Enable raw_spinlock - spinlock nesting checks" if !ARCH_SUPPORTS_RT
1497 depends on PROVE_LOCKING
1498 default y if ARCH_SUPPORTS_RT
1499 help
1500 Enable the raw_spinlock vs. spinlock nesting checks which ensure
1501 that the lock nesting rules for PREEMPT_RT enabled kernels are
1502 not violated.
1503
1504config LOCK_STAT
1505 bool "Lock usage statistics"
1506 depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
1507 select LOCKDEP
1508 select DEBUG_SPINLOCK
1509 select DEBUG_MUTEXES if !PREEMPT_RT
1510 select DEBUG_RT_MUTEXES if RT_MUTEXES
1511 select DEBUG_LOCK_ALLOC
1512 default n
1513 help
1514 This feature enables tracking lock contention points
1515
1516 For more details, see Documentation/locking/lockstat.rst
1517
1518 This also enables lock events required by "perf lock",
1519 subcommand of perf.
1520 If you want to use "perf lock", you also need to turn on
1521 CONFIG_EVENT_TRACING.
1522
1523 CONFIG_LOCK_STAT defines "contended" and "acquired" lock events.
1524 (CONFIG_LOCKDEP defines "acquire" and "release" events.)
1525
1526config DEBUG_RT_MUTEXES
1527 bool "RT Mutex debugging, deadlock detection"
1528 depends on DEBUG_KERNEL && RT_MUTEXES
1529 help
1530 This allows rt mutex semantics violations and rt mutex related
1531 deadlocks (lockups) to be detected and reported automatically.
1532
1533config DEBUG_SPINLOCK
1534 bool "Spinlock and rw-lock debugging: basic checks"
1535 depends on DEBUG_KERNEL
1536 select UNINLINE_SPIN_UNLOCK
1537 help
1538 Say Y here and build SMP to catch missing spinlock initialization
1539 and certain other kinds of spinlock errors commonly made. This is
1540 best used in conjunction with the NMI watchdog so that spinlock
1541 deadlocks are also debuggable.
1542
1543config DEBUG_MUTEXES
1544 bool "Mutex debugging: basic checks"
1545 depends on DEBUG_KERNEL && !PREEMPT_RT
1546 help
1547 This feature allows mutex semantics violations to be detected and
1548 reported.
1549
1550config DEBUG_WW_MUTEX_SLOWPATH
1551 bool "Wait/wound mutex debugging: Slowpath testing"
1552 depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
1553 select DEBUG_LOCK_ALLOC
1554 select DEBUG_SPINLOCK
1555 select DEBUG_MUTEXES if !PREEMPT_RT
1556 select DEBUG_RT_MUTEXES if PREEMPT_RT
1557 help
1558 This feature enables slowpath testing for w/w mutex users by
1559 injecting additional -EDEADLK wound/backoff cases. Together with
1560 the full mutex checks enabled with (CONFIG_PROVE_LOCKING) this
1561 will test all possible w/w mutex interface abuse with the
1562 exception of simply not acquiring all the required locks.
1563 Note that this feature can introduce significant overhead, so
1564 it really should not be enabled in a production or distro kernel,
1565 even a debug kernel. If you are a driver writer, enable it. If
1566 you are a distro, do not.
1567
1568config DEBUG_RWSEMS
1569 bool "RW Semaphore debugging: basic checks"
1570 depends on DEBUG_KERNEL && !PREEMPT_RT
1571 help
1572 This debugging feature allows mismatched rw semaphore locks
1573 and unlocks to be detected and reported.
1574
1575config DEBUG_LOCK_ALLOC
1576 bool "Lock debugging: detect incorrect freeing of live locks"
1577 depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
1578 select DEBUG_SPINLOCK
1579 select DEBUG_MUTEXES if !PREEMPT_RT
1580 select DEBUG_RT_MUTEXES if RT_MUTEXES
1581 select LOCKDEP
1582 help
1583 This feature will check whether any held lock (spinlock, rwlock,
1584 mutex or rwsem) is incorrectly freed by the kernel, via any of the
1585 memory-freeing routines (kfree(), kmem_cache_free(), free_pages(),
1586 vfree(), etc.), whether a live lock is incorrectly reinitialized via
1587 spin_lock_init()/mutex_init()/etc., or whether there is any lock
1588 held during task exit.
1589
1590config LOCKDEP
1591 bool
1592 depends on DEBUG_KERNEL && LOCK_DEBUGGING_SUPPORT
1593 select STACKTRACE
1594 select KALLSYMS
1595 select KALLSYMS_ALL
1596
1597config LOCKDEP_SMALL
1598 bool
1599
1600config LOCKDEP_BITS
1601 int "Size for MAX_LOCKDEP_ENTRIES (as Nth power of 2)"
1602 depends on LOCKDEP && !LOCKDEP_SMALL
1603 range 10 24
1604 default 15
1605 help
1606 Try increasing this value if you hit "BUG: MAX_LOCKDEP_ENTRIES too low!" message.
1607
1608config LOCKDEP_CHAINS_BITS
1609 int "Size for MAX_LOCKDEP_CHAINS (as Nth power of 2)"
1610 depends on LOCKDEP && !LOCKDEP_SMALL
1611 range 10 21
1612 default 16
1613 help
1614 Try increasing this value if you hit "BUG: MAX_LOCKDEP_CHAINS too low!" message.
1615
1616config LOCKDEP_STACK_TRACE_BITS
1617 int "Size for MAX_STACK_TRACE_ENTRIES (as Nth power of 2)"
1618 depends on LOCKDEP && !LOCKDEP_SMALL
1619 range 10 26
1620 default 19
1621 help
1622 Try increasing this value if you hit "BUG: MAX_STACK_TRACE_ENTRIES too low!" message.
1623
1624config LOCKDEP_STACK_TRACE_HASH_BITS
1625 int "Size for STACK_TRACE_HASH_SIZE (as Nth power of 2)"
1626 depends on LOCKDEP && !LOCKDEP_SMALL
1627 range 10 26
1628 default 14
1629 help
1630 Try increasing this value if you need large STACK_TRACE_HASH_SIZE.
1631
1632config LOCKDEP_CIRCULAR_QUEUE_BITS
1633 int "Size for elements in circular_queue struct (as Nth power of 2)"
1634 depends on LOCKDEP
1635 range 10 26
1636 default 12
1637 help
1638 Try increasing this value if you hit "lockdep bfs error:-1" warning due to __cq_enqueue() failure.
1639
1640config DEBUG_LOCKDEP
1641 bool "Lock dependency engine debugging"
1642 depends on DEBUG_KERNEL && LOCKDEP
1643 select DEBUG_IRQFLAGS
1644 help
1645 If you say Y here, the lock dependency engine will do
1646 additional runtime checks to debug itself, at the price
1647 of more runtime overhead.
1648
1649config DEBUG_ATOMIC_SLEEP
1650 bool "Sleep inside atomic section checking"
1651 select PREEMPT_COUNT
1652 depends on DEBUG_KERNEL
1653 depends on !ARCH_NO_PREEMPT
1654 help
1655 If you say Y here, various routines which may sleep will become very
1656 noisy if they are called inside atomic sections: when a spinlock is
1657 held, inside an rcu read side critical section, inside preempt disabled
1658 sections, inside an interrupt, etc...
1659
1660config DEBUG_LOCKING_API_SELFTESTS
1661 bool "Locking API boot-time self-tests"
1662 depends on DEBUG_KERNEL
1663 help
1664 Say Y here if you want the kernel to run a short self-test during
1665 bootup. The self-test checks whether common types of locking bugs
1666 are detected by debugging mechanisms or not. (if you disable
1667 lock debugging then those bugs won't be detected of course.)
1668 The following locking APIs are covered: spinlocks, rwlocks,
1669 mutexes and rwsems.
1670
1671config LOCK_TORTURE_TEST
1672 tristate "torture tests for locking"
1673 depends on DEBUG_KERNEL
1674 select TORTURE_TEST
1675 help
1676 This option provides a kernel module that runs torture tests
1677 on kernel locking primitives. The kernel module may be built
1678 after the fact on the running kernel to be tested, if desired.
1679
1680 Say Y here if you want kernel locking-primitive torture tests
1681 to be built into the kernel.
1682 Say M if you want these torture tests to build as a module.
1683 Say N if you are unsure.
1684
1685config WW_MUTEX_SELFTEST
1686 tristate "Wait/wound mutex selftests"
1687 help
1688 This option provides a kernel module that runs tests on the
1689 on the struct ww_mutex locking API.
1690
1691 It is recommended to enable DEBUG_WW_MUTEX_SLOWPATH in conjunction
1692 with this test harness.
1693
1694 Say M if you want these self tests to build as a module.
1695 Say N if you are unsure.
1696
1697config SCF_TORTURE_TEST
1698 tristate "torture tests for smp_call_function*()"
1699 depends on DEBUG_KERNEL
1700 select TORTURE_TEST
1701 help
1702 This option provides a kernel module that runs torture tests
1703 on the smp_call_function() family of primitives. The kernel
1704 module may be built after the fact on the running kernel to
1705 be tested, if desired.
1706
1707config CSD_LOCK_WAIT_DEBUG
1708 bool "Debugging for csd_lock_wait(), called from smp_call_function*()"
1709 depends on DEBUG_KERNEL
1710 depends on SMP
1711 depends on 64BIT
1712 default n
1713 help
1714 This option enables debug prints when CPUs are slow to respond
1715 to the smp_call_function*() IPI wrappers. These debug prints
1716 include the IPI handler function currently executing (if any)
1717 and relevant stack traces.
1718
1719config CSD_LOCK_WAIT_DEBUG_DEFAULT
1720 bool "Default csd_lock_wait() debugging on at boot time"
1721 depends on CSD_LOCK_WAIT_DEBUG
1722 depends on 64BIT
1723 default n
1724 help
1725 This option causes the csdlock_debug= kernel boot parameter to
1726 default to 1 (basic debugging) instead of 0 (no debugging).
1727
1728endmenu # lock debugging
1729
1730config TRACE_IRQFLAGS
1731 depends on TRACE_IRQFLAGS_SUPPORT
1732 bool
1733 help
1734 Enables hooks to interrupt enabling and disabling for
1735 either tracing or lock debugging.
1736
1737config TRACE_IRQFLAGS_NMI
1738 def_bool y
1739 depends on TRACE_IRQFLAGS
1740 depends on TRACE_IRQFLAGS_NMI_SUPPORT
1741
1742config NMI_CHECK_CPU
1743 bool "Debugging for CPUs failing to respond to backtrace requests"
1744 depends on DEBUG_KERNEL
1745 depends on X86
1746 default n
1747 help
1748 Enables debug prints when a CPU fails to respond to a given
1749 backtrace NMI. These prints provide some reasons why a CPU
1750 might legitimately be failing to respond, for example, if it
1751 is offline of if ignore_nmis is set.
1752
1753config DEBUG_IRQFLAGS
1754 bool "Debug IRQ flag manipulation"
1755 help
1756 Enables checks for potentially unsafe enabling or disabling of
1757 interrupts, such as calling raw_local_irq_restore() when interrupts
1758 are enabled.
1759
1760config STACKTRACE
1761 bool "Stack backtrace support"
1762 depends on STACKTRACE_SUPPORT
1763 help
1764 This option causes the kernel to create a /proc/pid/stack for
1765 every process, showing its current stack trace.
1766 It is also used by various kernel debugging features that require
1767 stack trace generation.
1768
1769config WARN_ALL_UNSEEDED_RANDOM
1770 bool "Warn for all uses of unseeded randomness"
1771 default n
1772 help
1773 Some parts of the kernel contain bugs relating to their use of
1774 cryptographically secure random numbers before it's actually possible
1775 to generate those numbers securely. This setting ensures that these
1776 flaws don't go unnoticed, by enabling a message, should this ever
1777 occur. This will allow people with obscure setups to know when things
1778 are going wrong, so that they might contact developers about fixing
1779 it.
1780
1781 Unfortunately, on some models of some architectures getting
1782 a fully seeded CRNG is extremely difficult, and so this can
1783 result in dmesg getting spammed for a surprisingly long
1784 time. This is really bad from a security perspective, and
1785 so architecture maintainers really need to do what they can
1786 to get the CRNG seeded sooner after the system is booted.
1787 However, since users cannot do anything actionable to
1788 address this, by default this option is disabled.
1789
1790 Say Y here if you want to receive warnings for all uses of
1791 unseeded randomness. This will be of use primarily for
1792 those developers interested in improving the security of
1793 Linux kernels running on their architecture (or
1794 subarchitecture).
1795
1796config DEBUG_KOBJECT
1797 bool "kobject debugging"
1798 depends on DEBUG_KERNEL
1799 help
1800 If you say Y here, some extra kobject debugging messages will be sent
1801 to the syslog.
1802
1803config DEBUG_KOBJECT_RELEASE
1804 bool "kobject release debugging"
1805 depends on DEBUG_OBJECTS_TIMERS
1806 help
1807 kobjects are reference counted objects. This means that their
1808 last reference count put is not predictable, and the kobject can
1809 live on past the point at which a driver decides to drop its
1810 initial reference to the kobject gained on allocation. An
1811 example of this would be a struct device which has just been
1812 unregistered.
1813
1814 However, some buggy drivers assume that after such an operation,
1815 the memory backing the kobject can be immediately freed. This
1816 goes completely against the principles of a refcounted object.
1817
1818 If you say Y here, the kernel will delay the release of kobjects
1819 on the last reference count to improve the visibility of this
1820 kind of kobject release bug.
1821
1822config HAVE_DEBUG_BUGVERBOSE
1823 bool
1824
1825menu "Debug kernel data structures"
1826
1827config DEBUG_LIST
1828 bool "Debug linked list manipulation"
1829 depends on DEBUG_KERNEL
1830 select LIST_HARDENED
1831 help
1832 Enable this to turn on extended checks in the linked-list walking
1833 routines.
1834
1835 This option trades better quality error reports for performance, and
1836 is more suitable for kernel debugging. If you care about performance,
1837 you should only enable CONFIG_LIST_HARDENED instead.
1838
1839 If unsure, say N.
1840
1841config DEBUG_PLIST
1842 bool "Debug priority linked list manipulation"
1843 depends on DEBUG_KERNEL
1844 help
1845 Enable this to turn on extended checks in the priority-ordered
1846 linked-list (plist) walking routines. This checks the entire
1847 list multiple times during each manipulation.
1848
1849 If unsure, say N.
1850
1851config DEBUG_SG
1852 bool "Debug SG table operations"
1853 depends on DEBUG_KERNEL
1854 help
1855 Enable this to turn on checks on scatter-gather tables. This can
1856 help find problems with drivers that do not properly initialize
1857 their sg tables.
1858
1859 If unsure, say N.
1860
1861config DEBUG_NOTIFIERS
1862 bool "Debug notifier call chains"
1863 depends on DEBUG_KERNEL
1864 help
1865 Enable this to turn on sanity checking for notifier call chains.
1866 This is most useful for kernel developers to make sure that
1867 modules properly unregister themselves from notifier chains.
1868 This is a relatively cheap check but if you care about maximum
1869 performance, say N.
1870
1871config DEBUG_CLOSURES
1872 bool "Debug closures (bcache async widgits)"
1873 depends on CLOSURES
1874 select DEBUG_FS
1875 help
1876 Keeps all active closures in a linked list and provides a debugfs
1877 interface to list them, which makes it possible to see asynchronous
1878 operations that get stuck.
1879
1880config DEBUG_MAPLE_TREE
1881 bool "Debug maple trees"
1882 depends on DEBUG_KERNEL
1883 help
1884 Enable maple tree debugging information and extra validations.
1885
1886 If unsure, say N.
1887
1888endmenu
1889
1890source "kernel/rcu/Kconfig.debug"
1891
1892config DEBUG_WQ_FORCE_RR_CPU
1893 bool "Force round-robin CPU selection for unbound work items"
1894 depends on DEBUG_KERNEL
1895 default n
1896 help
1897 Workqueue used to implicitly guarantee that work items queued
1898 without explicit CPU specified are put on the local CPU. This
1899 guarantee is no longer true and while local CPU is still
1900 preferred work items may be put on foreign CPUs. Kernel
1901 parameter "workqueue.debug_force_rr_cpu" is added to force
1902 round-robin CPU selection to flush out usages which depend on the
1903 now broken guarantee. This config option enables the debug
1904 feature by default. When enabled, memory and cache locality will
1905 be impacted.
1906
1907config CPU_HOTPLUG_STATE_CONTROL
1908 bool "Enable CPU hotplug state control"
1909 depends on DEBUG_KERNEL
1910 depends on HOTPLUG_CPU
1911 default n
1912 help
1913 Allows to write steps between "offline" and "online" to the CPUs
1914 sysfs target file so states can be stepped granular. This is a debug
1915 option for now as the hotplug machinery cannot be stopped and
1916 restarted at arbitrary points yet.
1917
1918 Say N if your are unsure.
1919
1920config LATENCYTOP
1921 bool "Latency measuring infrastructure"
1922 depends on DEBUG_KERNEL
1923 depends on STACKTRACE_SUPPORT
1924 depends on PROC_FS
1925 depends on FRAME_POINTER || MIPS || PPC || S390 || MICROBLAZE || ARM || ARC || X86
1926 select KALLSYMS
1927 select KALLSYMS_ALL
1928 select STACKTRACE
1929 select SCHEDSTATS
1930 help
1931 Enable this option if you want to use the LatencyTOP tool
1932 to find out which userspace is blocking on what kernel operations.
1933
1934config DEBUG_CGROUP_REF
1935 bool "Disable inlining of cgroup css reference count functions"
1936 depends on DEBUG_KERNEL
1937 depends on CGROUPS
1938 depends on KPROBES
1939 default n
1940 help
1941 Force cgroup css reference count functions to not be inlined so
1942 that they can be kprobed for debugging.
1943
1944source "kernel/trace/Kconfig"
1945
1946config PROVIDE_OHCI1394_DMA_INIT
1947 bool "Remote debugging over FireWire early on boot"
1948 depends on PCI && X86
1949 help
1950 If you want to debug problems which hang or crash the kernel early
1951 on boot and the crashing machine has a FireWire port, you can use
1952 this feature to remotely access the memory of the crashed machine
1953 over FireWire. This employs remote DMA as part of the OHCI1394
1954 specification which is now the standard for FireWire controllers.
1955
1956 With remote DMA, you can monitor the printk buffer remotely using
1957 firescope and access all memory below 4GB using fireproxy from gdb.
1958 Even controlling a kernel debugger is possible using remote DMA.
1959
1960 Usage:
1961
1962 If ohci1394_dma=early is used as boot parameter, it will initialize
1963 all OHCI1394 controllers which are found in the PCI config space.
1964
1965 As all changes to the FireWire bus such as enabling and disabling
1966 devices cause a bus reset and thereby disable remote DMA for all
1967 devices, be sure to have the cable plugged and FireWire enabled on
1968 the debugging host before booting the debug target for debugging.
1969
1970 This code (~1k) is freed after boot. By then, the firewire stack
1971 in charge of the OHCI-1394 controllers should be used instead.
1972
1973 See Documentation/core-api/debugging-via-ohci1394.rst for more information.
1974
1975source "samples/Kconfig"
1976
1977config ARCH_HAS_DEVMEM_IS_ALLOWED
1978 bool
1979
1980config STRICT_DEVMEM
1981 bool "Filter access to /dev/mem"
1982 depends on MMU && DEVMEM
1983 depends on ARCH_HAS_DEVMEM_IS_ALLOWED || GENERIC_LIB_DEVMEM_IS_ALLOWED
1984 default y if PPC || X86 || ARM64 || S390
1985 help
1986 If this option is disabled, you allow userspace (root) access to all
1987 of memory, including kernel and userspace memory. Accidental
1988 access to this is obviously disastrous, but specific access can
1989 be used by people debugging the kernel. Note that with PAT support
1990 enabled, even in this case there are restrictions on /dev/mem
1991 use due to the cache aliasing requirements.
1992
1993 If this option is switched on, and IO_STRICT_DEVMEM=n, the /dev/mem
1994 file only allows userspace access to PCI space and the BIOS code and
1995 data regions. This is sufficient for dosemu and X and all common
1996 users of /dev/mem.
1997
1998 If in doubt, say Y.
1999
2000config IO_STRICT_DEVMEM
2001 bool "Filter I/O access to /dev/mem"
2002 depends on STRICT_DEVMEM
2003 help
2004 If this option is disabled, you allow userspace (root) access to all
2005 io-memory regardless of whether a driver is actively using that
2006 range. Accidental access to this is obviously disastrous, but
2007 specific access can be used by people debugging kernel drivers.
2008
2009 If this option is switched on, the /dev/mem file only allows
2010 userspace access to *idle* io-memory ranges (see /proc/iomem) This
2011 may break traditional users of /dev/mem (dosemu, legacy X, etc...)
2012 if the driver using a given range cannot be disabled.
2013
2014 If in doubt, say Y.
2015
2016menu "$(SRCARCH) Debugging"
2017
2018source "arch/$(SRCARCH)/Kconfig.debug"
2019
2020endmenu
2021
2022menu "Kernel Testing and Coverage"
2023
2024source "lib/kunit/Kconfig"
2025
2026config NOTIFIER_ERROR_INJECTION
2027 tristate "Notifier error injection"
2028 depends on DEBUG_KERNEL
2029 select DEBUG_FS
2030 help
2031 This option provides the ability to inject artificial errors to
2032 specified notifier chain callbacks. It is useful to test the error
2033 handling of notifier call chain failures.
2034
2035 Say N if unsure.
2036
2037config PM_NOTIFIER_ERROR_INJECT
2038 tristate "PM notifier error injection module"
2039 depends on PM && NOTIFIER_ERROR_INJECTION
2040 default m if PM_DEBUG
2041 help
2042 This option provides the ability to inject artificial errors to
2043 PM notifier chain callbacks. It is controlled through debugfs
2044 interface /sys/kernel/debug/notifier-error-inject/pm
2045
2046 If the notifier call chain should be failed with some events
2047 notified, write the error code to "actions/<notifier event>/error".
2048
2049 Example: Inject PM suspend error (-12 = -ENOMEM)
2050
2051 # cd /sys/kernel/debug/notifier-error-inject/pm/
2052 # echo -12 > actions/PM_SUSPEND_PREPARE/error
2053 # echo mem > /sys/power/state
2054 bash: echo: write error: Cannot allocate memory
2055
2056 To compile this code as a module, choose M here: the module will
2057 be called pm-notifier-error-inject.
2058
2059 If unsure, say N.
2060
2061config OF_RECONFIG_NOTIFIER_ERROR_INJECT
2062 tristate "OF reconfig notifier error injection module"
2063 depends on OF_DYNAMIC && NOTIFIER_ERROR_INJECTION
2064 help
2065 This option provides the ability to inject artificial errors to
2066 OF reconfig notifier chain callbacks. It is controlled
2067 through debugfs interface under
2068 /sys/kernel/debug/notifier-error-inject/OF-reconfig/
2069
2070 If the notifier call chain should be failed with some events
2071 notified, write the error code to "actions/<notifier event>/error".
2072
2073 To compile this code as a module, choose M here: the module will
2074 be called of-reconfig-notifier-error-inject.
2075
2076 If unsure, say N.
2077
2078config NETDEV_NOTIFIER_ERROR_INJECT
2079 tristate "Netdev notifier error injection module"
2080 depends on NET && NOTIFIER_ERROR_INJECTION
2081 help
2082 This option provides the ability to inject artificial errors to
2083 netdevice notifier chain callbacks. It is controlled through debugfs
2084 interface /sys/kernel/debug/notifier-error-inject/netdev
2085
2086 If the notifier call chain should be failed with some events
2087 notified, write the error code to "actions/<notifier event>/error".
2088
2089 Example: Inject netdevice mtu change error (-22 = -EINVAL)
2090
2091 # cd /sys/kernel/debug/notifier-error-inject/netdev
2092 # echo -22 > actions/NETDEV_CHANGEMTU/error
2093 # ip link set eth0 mtu 1024
2094 RTNETLINK answers: Invalid argument
2095
2096 To compile this code as a module, choose M here: the module will
2097 be called netdev-notifier-error-inject.
2098
2099 If unsure, say N.
2100
2101config FUNCTION_ERROR_INJECTION
2102 bool "Fault-injections of functions"
2103 depends on HAVE_FUNCTION_ERROR_INJECTION && KPROBES
2104 help
2105 Add fault injections into various functions that are annotated with
2106 ALLOW_ERROR_INJECTION() in the kernel. BPF may also modify the return
2107 value of these functions. This is useful to test error paths of code.
2108
2109 If unsure, say N
2110
2111config FAULT_INJECTION
2112 bool "Fault-injection framework"
2113 depends on DEBUG_KERNEL
2114 help
2115 Provide fault-injection framework.
2116 For more details, see Documentation/fault-injection/.
2117
2118config FAILSLAB
2119 bool "Fault-injection capability for kmalloc"
2120 depends on FAULT_INJECTION
2121 help
2122 Provide fault-injection capability for kmalloc.
2123
2124config FAIL_PAGE_ALLOC
2125 bool "Fault-injection capability for alloc_pages()"
2126 depends on FAULT_INJECTION
2127 help
2128 Provide fault-injection capability for alloc_pages().
2129
2130config FAULT_INJECTION_USERCOPY
2131 bool "Fault injection capability for usercopy functions"
2132 depends on FAULT_INJECTION
2133 help
2134 Provides fault-injection capability to inject failures
2135 in usercopy functions (copy_from_user(), get_user(), ...).
2136
2137config FAIL_MAKE_REQUEST
2138 bool "Fault-injection capability for disk IO"
2139 depends on FAULT_INJECTION && BLOCK
2140 help
2141 Provide fault-injection capability for disk IO.
2142
2143config FAIL_IO_TIMEOUT
2144 bool "Fault-injection capability for faking disk interrupts"
2145 depends on FAULT_INJECTION && BLOCK
2146 help
2147 Provide fault-injection capability on end IO handling. This
2148 will make the block layer "forget" an interrupt as configured,
2149 thus exercising the error handling.
2150
2151 Only works with drivers that use the generic timeout handling,
2152 for others it won't do anything.
2153
2154config FAIL_FUTEX
2155 bool "Fault-injection capability for futexes"
2156 select DEBUG_FS
2157 depends on FAULT_INJECTION && FUTEX
2158 help
2159 Provide fault-injection capability for futexes.
2160
2161config FAULT_INJECTION_DEBUG_FS
2162 bool "Debugfs entries for fault-injection capabilities"
2163 depends on FAULT_INJECTION && SYSFS && DEBUG_FS
2164 help
2165 Enable configuration of fault-injection capabilities via debugfs.
2166
2167config FAIL_FUNCTION
2168 bool "Fault-injection capability for functions"
2169 depends on FAULT_INJECTION_DEBUG_FS && FUNCTION_ERROR_INJECTION
2170 help
2171 Provide function-based fault-injection capability.
2172 This will allow you to override a specific function with a return
2173 with given return value. As a result, function caller will see
2174 an error value and have to handle it. This is useful to test the
2175 error handling in various subsystems.
2176
2177config FAIL_MMC_REQUEST
2178 bool "Fault-injection capability for MMC IO"
2179 depends on FAULT_INJECTION_DEBUG_FS && MMC
2180 help
2181 Provide fault-injection capability for MMC IO.
2182 This will make the mmc core return data errors. This is
2183 useful to test the error handling in the mmc block device
2184 and to test how the mmc host driver handles retries from
2185 the block device.
2186
2187config FAIL_SUNRPC
2188 bool "Fault-injection capability for SunRPC"
2189 depends on FAULT_INJECTION_DEBUG_FS && SUNRPC_DEBUG
2190 help
2191 Provide fault-injection capability for SunRPC and
2192 its consumers.
2193
2194config FAIL_SKB_REALLOC
2195 bool "Fault-injection capability forcing skb to reallocate"
2196 depends on FAULT_INJECTION_DEBUG_FS
2197 help
2198 Provide fault-injection capability that forces the skb to be
2199 reallocated, catching possible invalid pointers to the skb.
2200
2201 For more information, check
2202 Documentation/fault-injection/fault-injection.rst
2203
2204config FAULT_INJECTION_CONFIGFS
2205 bool "Configfs interface for fault-injection capabilities"
2206 depends on FAULT_INJECTION
2207 select CONFIGFS_FS
2208 help
2209 This option allows configfs-based drivers to dynamically configure
2210 fault-injection via configfs. Each parameter for driver-specific
2211 fault-injection can be made visible as a configfs attribute in a
2212 configfs group.
2213
2214
2215config FAULT_INJECTION_STACKTRACE_FILTER
2216 bool "stacktrace filter for fault-injection capabilities"
2217 depends on FAULT_INJECTION
2218 depends on (FAULT_INJECTION_DEBUG_FS || FAULT_INJECTION_CONFIGFS) && STACKTRACE_SUPPORT
2219 select STACKTRACE
2220 depends on FRAME_POINTER || MIPS || PPC || S390 || MICROBLAZE || ARM || ARC || X86
2221 help
2222 Provide stacktrace filter for fault-injection capabilities
2223
2224config ARCH_HAS_KCOV
2225 bool
2226 help
2227 An architecture should select this when it can successfully
2228 build and run with CONFIG_KCOV. This typically requires
2229 disabling instrumentation for some early boot code.
2230
2231config KCOV
2232 bool "Code coverage for fuzzing"
2233 depends on ARCH_HAS_KCOV
2234 depends on !ARCH_WANTS_NO_INSTR || HAVE_NOINSTR_HACK || \
2235 GCC_VERSION >= 120000 || CC_IS_CLANG
2236 select DEBUG_FS
2237 select OBJTOOL if HAVE_NOINSTR_HACK
2238 help
2239 KCOV exposes kernel code coverage information in a form suitable
2240 for coverage-guided fuzzing (randomized testing).
2241
2242 For more details, see Documentation/dev-tools/kcov.rst.
2243
2244config KCOV_ENABLE_COMPARISONS
2245 bool "Enable comparison operands collection by KCOV"
2246 depends on KCOV
2247 depends on $(cc-option,-fsanitize-coverage=trace-cmp)
2248 help
2249 KCOV also exposes operands of every comparison in the instrumented
2250 code along with operand sizes and PCs of the comparison instructions.
2251 These operands can be used by fuzzing engines to improve the quality
2252 of fuzzing coverage.
2253
2254config KCOV_INSTRUMENT_ALL
2255 bool "Instrument all code by default"
2256 depends on KCOV
2257 default y
2258 help
2259 If you are doing generic system call fuzzing (like e.g. syzkaller),
2260 then you will want to instrument the whole kernel and you should
2261 say y here. If you are doing more targeted fuzzing (like e.g.
2262 filesystem fuzzing with AFL) then you will want to enable coverage
2263 for more specific subsets of files, and should say n here.
2264
2265config KCOV_IRQ_AREA_SIZE
2266 hex "Size of interrupt coverage collection area in words"
2267 depends on KCOV
2268 default 0x40000
2269 help
2270 KCOV uses preallocated per-cpu areas to collect coverage from
2271 soft interrupts. This specifies the size of those areas in the
2272 number of unsigned long words.
2273
2274config KCOV_SELFTEST
2275 bool "Perform short selftests on boot"
2276 depends on KCOV
2277 help
2278 Run short KCOV coverage collection selftests on boot.
2279 On test failure, causes the kernel to panic. Recommended to be
2280 enabled, ensuring critical functionality works as intended.
2281
2282menuconfig RUNTIME_TESTING_MENU
2283 bool "Runtime Testing"
2284 default y
2285
2286if RUNTIME_TESTING_MENU
2287
2288config TEST_DHRY
2289 tristate "Dhrystone benchmark test"
2290 help
2291 Enable this to include the Dhrystone 2.1 benchmark. This test
2292 calculates the number of Dhrystones per second, and the number of
2293 DMIPS (Dhrystone MIPS) obtained when the Dhrystone score is divided
2294 by 1757 (the number of Dhrystones per second obtained on the VAX
2295 11/780, nominally a 1 MIPS machine).
2296
2297 To run the benchmark, it needs to be enabled explicitly, either from
2298 the kernel command line (when built-in), or from userspace (when
2299 built-in or modular).
2300
2301 Run once during kernel boot:
2302
2303 test_dhry.run
2304
2305 Set number of iterations from kernel command line:
2306
2307 test_dhry.iterations=<n>
2308
2309 Set number of iterations from userspace:
2310
2311 echo <n> > /sys/module/test_dhry/parameters/iterations
2312
2313 Trigger manual run from userspace:
2314
2315 echo y > /sys/module/test_dhry/parameters/run
2316
2317 If the number of iterations is <= 0, the test will devise a suitable
2318 number of iterations (test runs for at least 2s) automatically.
2319 This process takes ca. 4s.
2320
2321 If unsure, say N.
2322
2323config LKDTM
2324 tristate "Linux Kernel Dump Test Tool Module"
2325 depends on DEBUG_FS
2326 help
2327 This module enables testing of the different dumping mechanisms by
2328 inducing system failures at predefined crash points.
2329 If you don't need it: say N
2330 Choose M here to compile this code as a module. The module will be
2331 called lkdtm.
2332
2333 Documentation on how to use the module can be found in
2334 Documentation/fault-injection/provoke-crashes.rst
2335
2336config CPUMASK_KUNIT_TEST
2337 tristate "KUnit test for cpumask" if !KUNIT_ALL_TESTS
2338 depends on KUNIT
2339 default KUNIT_ALL_TESTS
2340 help
2341 Enable to turn on cpumask tests, running at boot or module load time.
2342
2343 For more information on KUnit and unit tests in general, please refer
2344 to the KUnit documentation in Documentation/dev-tools/kunit/.
2345
2346 If unsure, say N.
2347
2348config TEST_LIST_SORT
2349 tristate "Linked list sorting test" if !KUNIT_ALL_TESTS
2350 depends on KUNIT
2351 default KUNIT_ALL_TESTS
2352 help
2353 Enable this to turn on 'list_sort()' function test. This test is
2354 executed only once during system boot (so affects only boot time),
2355 or at module load time.
2356
2357 If unsure, say N.
2358
2359config TEST_SORT
2360 tristate "Array-based sort test" if !KUNIT_ALL_TESTS
2361 depends on KUNIT
2362 default KUNIT_ALL_TESTS
2363 help
2364 This option enables the self-test function of 'sort()' at boot,
2365 or at module load time.
2366
2367 If unsure, say N.
2368
2369config TEST_DIV64
2370 tristate "64bit/32bit division and modulo test"
2371 depends on DEBUG_KERNEL || m
2372 help
2373 Enable this to turn on 'do_div()' function test. This test is
2374 executed only once during system boot (so affects only boot time),
2375 or at module load time.
2376
2377 If unsure, say N.
2378
2379config TEST_MULDIV64
2380 tristate "mul_u64_u64_div_u64() test"
2381 depends on DEBUG_KERNEL || m
2382 help
2383 Enable this to turn on 'mul_u64_u64_div_u64()' function test.
2384 This test is executed only once during system boot (so affects
2385 only boot time), or at module load time.
2386
2387 If unsure, say N.
2388
2389config TEST_IOV_ITER
2390 tristate "Test iov_iter operation" if !KUNIT_ALL_TESTS
2391 depends on KUNIT
2392 depends on MMU
2393 default KUNIT_ALL_TESTS
2394 help
2395 Enable this to turn on testing of the operation of the I/O iterator
2396 (iov_iter). This test is executed only once during system boot (so
2397 affects only boot time), or at module load time.
2398
2399 If unsure, say N.
2400
2401config KPROBES_SANITY_TEST
2402 tristate "Kprobes sanity tests" if !KUNIT_ALL_TESTS
2403 depends on DEBUG_KERNEL
2404 depends on KPROBES
2405 depends on KUNIT
2406 select STACKTRACE if ARCH_CORRECT_STACKTRACE_ON_KRETPROBE
2407 default KUNIT_ALL_TESTS
2408 help
2409 This option provides for testing basic kprobes functionality on
2410 boot. Samples of kprobe and kretprobe are inserted and
2411 verified for functionality.
2412
2413 Say N if you are unsure.
2414
2415config FPROBE_SANITY_TEST
2416 bool "Self test for fprobe"
2417 depends on DEBUG_KERNEL
2418 depends on FPROBE
2419 depends on KUNIT=y
2420 help
2421 This option will enable testing the fprobe when the system boot.
2422 A series of tests are made to verify that the fprobe is functioning
2423 properly.
2424
2425 Say N if you are unsure.
2426
2427config BACKTRACE_SELF_TEST
2428 tristate "Self test for the backtrace code"
2429 depends on DEBUG_KERNEL
2430 help
2431 This option provides a kernel module that can be used to test
2432 the kernel stack backtrace code. This option is not useful
2433 for distributions or general kernels, but only for kernel
2434 developers working on architecture code.
2435
2436 Note that if you want to also test saved backtraces, you will
2437 have to enable STACKTRACE as well.
2438
2439 Say N if you are unsure.
2440
2441config TEST_REF_TRACKER
2442 tristate "Self test for reference tracker"
2443 depends on DEBUG_KERNEL && STACKTRACE_SUPPORT
2444 select REF_TRACKER
2445 help
2446 This option provides a kernel module performing tests
2447 using reference tracker infrastructure.
2448
2449 Say N if you are unsure.
2450
2451config RBTREE_TEST
2452 tristate "Red-Black tree test"
2453 depends on DEBUG_KERNEL
2454 help
2455 A benchmark measuring the performance of the rbtree library.
2456 Also includes rbtree invariant checks.
2457
2458config REED_SOLOMON_TEST
2459 tristate "Reed-Solomon library test"
2460 depends on DEBUG_KERNEL || m
2461 select REED_SOLOMON
2462 select REED_SOLOMON_ENC16
2463 select REED_SOLOMON_DEC16
2464 help
2465 This option enables the self-test function of rslib at boot,
2466 or at module load time.
2467
2468 If unsure, say N.
2469
2470config INTERVAL_TREE_TEST
2471 tristate "Interval tree test"
2472 depends on DEBUG_KERNEL
2473 select INTERVAL_TREE
2474 help
2475 A benchmark measuring the performance of the interval tree library
2476
2477config PERCPU_TEST
2478 tristate "Per cpu operations test"
2479 depends on m && DEBUG_KERNEL
2480 help
2481 Enable this option to build test module which validates per-cpu
2482 operations.
2483
2484 If unsure, say N.
2485
2486config ATOMIC64_SELFTEST
2487 tristate "Perform an atomic64_t self-test"
2488 help
2489 Enable this option to test the atomic64_t functions at boot or
2490 at module load time.
2491
2492 If unsure, say N.
2493
2494config ASYNC_RAID6_TEST
2495 tristate "Self test for hardware accelerated raid6 recovery"
2496 depends on ASYNC_RAID6_RECOV
2497 select ASYNC_MEMCPY
2498 help
2499 This is a one-shot self test that permutes through the
2500 recovery of all the possible two disk failure scenarios for a
2501 N-disk array. Recovery is performed with the asynchronous
2502 raid6 recovery routines, and will optionally use an offload
2503 engine if one is available.
2504
2505 If unsure, say N.
2506
2507config TEST_HEXDUMP
2508 tristate "Test functions located in the hexdump module at runtime"
2509
2510config PRINTF_KUNIT_TEST
2511 tristate "KUnit test printf() family of functions at runtime" if !KUNIT_ALL_TESTS
2512 depends on KUNIT
2513 default KUNIT_ALL_TESTS
2514 help
2515 Enable this option to test the printf functions at runtime.
2516
2517 If unsure, say N.
2518
2519config SCANF_KUNIT_TEST
2520 tristate "KUnit test scanf() family of functions at runtime" if !KUNIT_ALL_TESTS
2521 depends on KUNIT
2522 default KUNIT_ALL_TESTS
2523 help
2524 Enable this option to test the scanf functions at runtime.
2525
2526 If unsure, say N.
2527
2528config SEQ_BUF_KUNIT_TEST
2529 tristate "KUnit test for seq_buf" if !KUNIT_ALL_TESTS
2530 depends on KUNIT
2531 default KUNIT_ALL_TESTS
2532 help
2533 This builds unit tests for the seq_buf library.
2534
2535 If unsure, say N.
2536
2537config STRING_KUNIT_TEST
2538 tristate "KUnit test string functions at runtime" if !KUNIT_ALL_TESTS
2539 depends on KUNIT
2540 default KUNIT_ALL_TESTS
2541
2542config STRING_HELPERS_KUNIT_TEST
2543 tristate "KUnit test string helpers at runtime" if !KUNIT_ALL_TESTS
2544 depends on KUNIT
2545 default KUNIT_ALL_TESTS
2546
2547config FFS_KUNIT_TEST
2548 tristate "KUnit test ffs-family functions at runtime" if !KUNIT_ALL_TESTS
2549 depends on KUNIT
2550 default KUNIT_ALL_TESTS
2551 help
2552 This builds KUnit tests for ffs-family bit manipulation functions
2553 including ffs(), __ffs(), fls(), __fls(), fls64(), and __ffs64().
2554
2555 These tests validate mathematical correctness, edge case handling,
2556 and cross-architecture consistency of bit scanning functions.
2557
2558 For more information on KUnit and unit tests in general,
2559 please refer to Documentation/dev-tools/kunit/.
2560
2561config TEST_KSTRTOX
2562 tristate "Test kstrto*() family of functions at runtime"
2563
2564config TEST_BITMAP
2565 tristate "Test bitmap_*() family of functions at runtime"
2566 help
2567 Enable this option to test the bitmap functions at boot.
2568
2569 If unsure, say N.
2570
2571config TEST_XARRAY
2572 tristate "Test the XArray code at runtime"
2573
2574config TEST_MAPLE_TREE
2575 tristate "Test the Maple Tree code at runtime or module load"
2576 help
2577 Enable this option to test the maple tree code functions at boot, or
2578 when the module is loaded. Enable "Debug Maple Trees" will enable
2579 more verbose output on failures.
2580
2581 If unsure, say N.
2582
2583config TEST_RHASHTABLE
2584 tristate "Perform selftest on resizable hash table"
2585 help
2586 Enable this option to test the rhashtable functions at boot.
2587
2588 If unsure, say N.
2589
2590config TEST_IDA
2591 tristate "Perform selftest on IDA functions"
2592
2593config TEST_MISC_MINOR
2594 bool "miscdevice KUnit test" if !KUNIT_ALL_TESTS
2595 depends on KUNIT=y
2596 default KUNIT_ALL_TESTS
2597 help
2598 Kunit test for miscdevice API, specially its behavior in respect to
2599 static and dynamic minor numbers.
2600
2601 KUnit tests run during boot and output the results to the debug log
2602 in TAP format (https://testanything.org/). Only useful for kernel devs
2603 running the KUnit test harness, and not intended for inclusion into a
2604 production build.
2605
2606 For more information on KUnit and unit tests in general please refer
2607 to the KUnit documentation in Documentation/dev-tools/kunit/.
2608
2609 If unsure, say N.
2610
2611config TEST_PARMAN
2612 tristate "Perform selftest on priority array manager"
2613 depends on PARMAN
2614 help
2615 Enable this option to test priority array manager on boot
2616 (or module load).
2617
2618 If unsure, say N.
2619
2620config TEST_LKM
2621 tristate "Test module loading with 'hello world' module"
2622 depends on m
2623 help
2624 This builds the "test_module" module that emits "Hello, world"
2625 on printk when loaded. It is designed to be used for basic
2626 evaluation of the module loading subsystem (for example when
2627 validating module verification). It lacks any extra dependencies,
2628 and will not normally be loaded by the system unless explicitly
2629 requested by name.
2630
2631 If unsure, say N.
2632
2633config TEST_BITOPS
2634 tristate "Test module for compilation of bitops operations"
2635 help
2636 This builds the "test_bitops" module that is much like the
2637 TEST_LKM module except that it does a basic exercise of the
2638 set/clear_bit macros and get_count_order/long to make sure there are
2639 no compiler warnings from C=1 sparse checker or -Wextra
2640 compilations. It has no dependencies and doesn't run or load unless
2641 explicitly requested by name. for example: modprobe test_bitops.
2642
2643 If unsure, say N.
2644
2645config TEST_VMALLOC
2646 tristate "Test module for stress/performance analysis of vmalloc allocator"
2647 default n
2648 depends on MMU
2649 help
2650 This builds the "test_vmalloc" module that should be used for
2651 stress and performance analysis. So, any new change for vmalloc
2652 subsystem can be evaluated from performance and stability point
2653 of view.
2654
2655 If unsure, say N.
2656
2657config TEST_BPF
2658 tristate "Test BPF filter functionality"
2659 depends on m && NET
2660 help
2661 This builds the "test_bpf" module that runs various test vectors
2662 against the BPF interpreter or BPF JIT compiler depending on the
2663 current setting. This is in particular useful for BPF JIT compiler
2664 development, but also to run regression tests against changes in
2665 the interpreter code. It also enables test stubs for eBPF maps and
2666 verifier used by user space verifier testsuite.
2667
2668 If unsure, say N.
2669
2670config FIND_BIT_BENCHMARK
2671 tristate "Test find_bit functions"
2672 help
2673 This builds the "test_find_bit" module that measure find_*_bit()
2674 functions performance.
2675
2676 If unsure, say N.
2677
2678config FIND_BIT_BENCHMARK_RUST
2679 tristate "Test find_bit functions in Rust"
2680 depends on RUST
2681 help
2682 This builds the "find_bit_benchmark_rust" module. It is a micro
2683 benchmark that measures the performance of Rust functions that
2684 correspond to the find_*_bit() operations in C. It follows the
2685 FIND_BIT_BENCHMARK closely but will in general not yield same
2686 numbers due to extra bounds checks and overhead of foreign
2687 function calls.
2688
2689 If unsure, say N.
2690
2691config TEST_FIRMWARE
2692 tristate "Test firmware loading via userspace interface"
2693 depends on FW_LOADER
2694 help
2695 This builds the "test_firmware" module that creates a userspace
2696 interface for testing firmware loading. This can be used to
2697 control the triggering of firmware loading without needing an
2698 actual firmware-using device. The contents can be rechecked by
2699 userspace.
2700
2701 If unsure, say N.
2702
2703config TEST_SYSCTL
2704 tristate "sysctl test driver"
2705 depends on PROC_SYSCTL
2706 help
2707 This builds the "test_sysctl" module. This driver enables to test the
2708 proc sysctl interfaces available to drivers safely without affecting
2709 production knobs which might alter system functionality.
2710
2711 If unsure, say N.
2712
2713config BITOPS_KUNIT
2714 tristate "KUnit test for bitops" if !KUNIT_ALL_TESTS
2715 depends on KUNIT
2716 default KUNIT_ALL_TESTS
2717 help
2718 This option enables the KUnit test for the bitops library
2719 which provides functions for bit operations.
2720
2721 Note that this is derived from the original test_bitops module.
2722 For micro-benchmarks and compiler warning checks, enable TEST_BITOPS.
2723
2724 If unsure, say N.
2725
2726config BITFIELD_KUNIT
2727 tristate "KUnit test bitfield functions at runtime" if !KUNIT_ALL_TESTS
2728 depends on KUNIT
2729 default KUNIT_ALL_TESTS
2730 help
2731 Enable this option to test the bitfield functions at boot.
2732
2733 KUnit tests run during boot and output the results to the debug log
2734 in TAP format (http://testanything.org/). Only useful for kernel devs
2735 running the KUnit test harness, and not intended for inclusion into a
2736 production build.
2737
2738 For more information on KUnit and unit tests in general please refer
2739 to the KUnit documentation in Documentation/dev-tools/kunit/.
2740
2741 If unsure, say N.
2742
2743config CHECKSUM_KUNIT
2744 tristate "KUnit test checksum functions at runtime" if !KUNIT_ALL_TESTS
2745 depends on KUNIT
2746 default KUNIT_ALL_TESTS
2747 help
2748 Enable this option to test the checksum functions at boot.
2749
2750 KUnit tests run during boot and output the results to the debug log
2751 in TAP format (http://testanything.org/). Only useful for kernel devs
2752 running the KUnit test harness, and not intended for inclusion into a
2753 production build.
2754
2755 For more information on KUnit and unit tests in general please refer
2756 to the KUnit documentation in Documentation/dev-tools/kunit/.
2757
2758 If unsure, say N.
2759
2760config UTIL_MACROS_KUNIT
2761 tristate "KUnit test util_macros.h functions at runtime" if !KUNIT_ALL_TESTS
2762 depends on KUNIT
2763 default KUNIT_ALL_TESTS
2764 help
2765 Enable this option to test the util_macros.h function at boot.
2766
2767 KUnit tests run during boot and output the results to the debug log
2768 in TAP format (http://testanything.org/). Only useful for kernel devs
2769 running the KUnit test harness, and not intended for inclusion into a
2770 production build.
2771
2772 For more information on KUnit and unit tests in general please refer
2773 to the KUnit documentation in Documentation/dev-tools/kunit/.
2774
2775 If unsure, say N.
2776
2777config HASH_KUNIT_TEST
2778 tristate "KUnit Test for integer hash functions" if !KUNIT_ALL_TESTS
2779 depends on KUNIT
2780 default KUNIT_ALL_TESTS
2781 help
2782 Enable this option to test the kernel's string (<linux/stringhash.h>), and
2783 integer (<linux/hash.h>) hash functions on boot.
2784
2785 KUnit tests run during boot and output the results to the debug log
2786 in TAP format (https://testanything.org/). Only useful for kernel devs
2787 running the KUnit test harness, and not intended for inclusion into a
2788 production build.
2789
2790 For more information on KUnit and unit tests in general please refer
2791 to the KUnit documentation in Documentation/dev-tools/kunit/.
2792
2793 This is intended to help people writing architecture-specific
2794 optimized versions. If unsure, say N.
2795
2796config RESOURCE_KUNIT_TEST
2797 tristate "KUnit test for resource API" if !KUNIT_ALL_TESTS
2798 depends on KUNIT
2799 default KUNIT_ALL_TESTS
2800 select GET_FREE_REGION
2801 help
2802 This builds the resource API unit test.
2803 Tests the logic of API provided by resource.c and ioport.h.
2804 For more information on KUnit and unit tests in general please refer
2805 to the KUnit documentation in Documentation/dev-tools/kunit/.
2806
2807 If unsure, say N.
2808
2809config SYSCTL_KUNIT_TEST
2810 tristate "KUnit test for sysctl" if !KUNIT_ALL_TESTS
2811 depends on KUNIT
2812 default KUNIT_ALL_TESTS
2813 help
2814 This builds the proc sysctl unit test, which runs on boot.
2815 Tests the API contract and implementation correctness of sysctl.
2816 For more information on KUnit and unit tests in general please refer
2817 to the KUnit documentation in Documentation/dev-tools/kunit/.
2818
2819 If unsure, say N.
2820
2821config KFIFO_KUNIT_TEST
2822 tristate "KUnit Test for the generic kernel FIFO implementation" if !KUNIT_ALL_TESTS
2823 depends on KUNIT
2824 default KUNIT_ALL_TESTS
2825 help
2826 This builds the generic FIFO implementation KUnit test suite.
2827 It tests that the API and basic functionality of the kfifo type
2828 and associated macros.
2829
2830 For more information on KUnit and unit tests in general please refer
2831 to the KUnit documentation in Documentation/dev-tools/kunit/.
2832
2833 If unsure, say N.
2834
2835config LIST_KUNIT_TEST
2836 tristate "KUnit Test for Kernel Linked-list structures" if !KUNIT_ALL_TESTS
2837 depends on KUNIT
2838 default KUNIT_ALL_TESTS
2839 help
2840 This builds the linked list KUnit test suite.
2841 It tests that the API and basic functionality of the list_head type
2842 and associated macros.
2843
2844 KUnit tests run during boot and output the results to the debug log
2845 in TAP format (https://testanything.org/). Only useful for kernel devs
2846 running the KUnit test harness, and not intended for inclusion into a
2847 production build.
2848
2849 For more information on KUnit and unit tests in general please refer
2850 to the KUnit documentation in Documentation/dev-tools/kunit/.
2851
2852 If unsure, say N.
2853
2854config LIST_PRIVATE_KUNIT_TEST
2855 tristate "KUnit Test for Kernel Private Linked-list structures" if !KUNIT_ALL_TESTS
2856 depends on KUNIT
2857 default KUNIT_ALL_TESTS
2858 help
2859 This builds the KUnit test for the private linked-list primitives
2860 defined in include/linux/list_private.h.
2861
2862 These primitives allow manipulation of list_head members that are
2863 marked as private and require special accessors (ACCESS_PRIVATE)
2864 to strip qualifiers or handle encapsulation.
2865
2866 If unsure, say N.
2867
2868config HASHTABLE_KUNIT_TEST
2869 tristate "KUnit Test for Kernel Hashtable structures" if !KUNIT_ALL_TESTS
2870 depends on KUNIT
2871 default KUNIT_ALL_TESTS
2872 help
2873 This builds the hashtable KUnit test suite.
2874 It tests the basic functionality of the API defined in
2875 include/linux/hashtable.h. For more information on KUnit and
2876 unit tests in general please refer to the KUnit documentation
2877 in Documentation/dev-tools/kunit/.
2878
2879 If unsure, say N.
2880
2881config LINEAR_RANGES_TEST
2882 tristate "KUnit test for linear_ranges"
2883 depends on KUNIT
2884 select LINEAR_RANGES
2885 help
2886 This builds the linear_ranges unit test, which runs on boot.
2887 Tests the linear_ranges logic correctness.
2888 For more information on KUnit and unit tests in general please refer
2889 to the KUnit documentation in Documentation/dev-tools/kunit/.
2890
2891 If unsure, say N.
2892
2893config CONTEXT_ANALYSIS_TEST
2894 bool "Compiler context-analysis warnings test"
2895 depends on EXPERT
2896 help
2897 This builds the test for compiler-based context analysis. The test
2898 does not add executable code to the kernel, but is meant to test that
2899 common patterns supported by the analysis do not result in false
2900 positive warnings.
2901
2902 When adding support for new context locks, it is strongly recommended
2903 to add supported patterns to this test.
2904
2905 If unsure, say N.
2906
2907config LIVEUPDATE_TEST
2908 bool "Live Update Kernel Test"
2909 default n
2910 depends on LIVEUPDATE
2911 help
2912 Enable a built-in kernel test module for the Live Update
2913 Orchestrator.
2914
2915 This module validates the File-Lifecycle-Bound subsystem by
2916 registering a set of mock FLB objects with any real file handlers
2917 that support live update (such as the memfd handler).
2918
2919 When live update operations are performed, this test module will
2920 output messages to the kernel log (dmesg), confirming that its
2921 registration and various callback functions (preserve, retrieve,
2922 finish, etc.) are being invoked correctly.
2923
2924 This is a debugging and regression testing tool for developers
2925 working on the Live Update subsystem. It should not be enabled in
2926 production kernels.
2927
2928 If unsure, say N
2929
2930config CMDLINE_KUNIT_TEST
2931 tristate "KUnit test for cmdline API" if !KUNIT_ALL_TESTS
2932 depends on KUNIT
2933 default KUNIT_ALL_TESTS
2934 help
2935 This builds the cmdline API unit test.
2936 Tests the logic of API provided by cmdline.c.
2937 For more information on KUnit and unit tests in general please refer
2938 to the KUnit documentation in Documentation/dev-tools/kunit/.
2939
2940 If unsure, say N.
2941
2942config BASE64_KUNIT
2943 tristate "KUnit test for base64 decoding and encoding" if !KUNIT_ALL_TESTS
2944 depends on KUNIT
2945 default KUNIT_ALL_TESTS
2946 help
2947 This builds the base64 unit tests.
2948
2949 The tests cover the encoding and decoding logic of Base64 functions
2950 in the kernel.
2951 In addition to correctness checks, simple performance benchmarks
2952 for both encoding and decoding are also included.
2953
2954 For more information on KUnit and unit tests in general please refer
2955 to the KUnit documentation in Documentation/dev-tools/kunit/.
2956
2957 If unsure, say N.
2958
2959config BITS_TEST
2960 tristate "KUnit test for bit functions and macros" if !KUNIT_ALL_TESTS
2961 depends on KUNIT
2962 default KUNIT_ALL_TESTS
2963 help
2964 This builds the bits unit test.
2965 Tests the logic of macros defined in bits.h.
2966 For more information on KUnit and unit tests in general please refer
2967 to the KUnit documentation in Documentation/dev-tools/kunit/.
2968
2969 If unsure, say N.
2970
2971config SLUB_KUNIT_TEST
2972 tristate "KUnit test for SLUB cache error detection" if !KUNIT_ALL_TESTS
2973 depends on SLUB_DEBUG && KUNIT
2974 default KUNIT_ALL_TESTS
2975 help
2976 This builds SLUB allocator unit test.
2977 Tests SLUB cache debugging functionality.
2978 For more information on KUnit and unit tests in general please refer
2979 to the KUnit documentation in Documentation/dev-tools/kunit/.
2980
2981 If unsure, say N.
2982
2983config RATIONAL_KUNIT_TEST
2984 tristate "KUnit test for rational.c" if !KUNIT_ALL_TESTS
2985 depends on KUNIT && RATIONAL
2986 default KUNIT_ALL_TESTS
2987 help
2988 This builds the rational math unit test.
2989 For more information on KUnit and unit tests in general please refer
2990 to the KUnit documentation in Documentation/dev-tools/kunit/.
2991
2992 If unsure, say N.
2993
2994config MEMCPY_KUNIT_TEST
2995 tristate "Test memcpy(), memmove(), and memset() functions at runtime" if !KUNIT_ALL_TESTS
2996 depends on KUNIT
2997 default KUNIT_ALL_TESTS
2998 help
2999 Builds unit tests for memcpy(), memmove(), and memset() functions.
3000 For more information on KUnit and unit tests in general please refer
3001 to the KUnit documentation in Documentation/dev-tools/kunit/.
3002
3003 If unsure, say N.
3004
3005config MIN_HEAP_KUNIT_TEST
3006 tristate "Min heap test" if !KUNIT_ALL_TESTS
3007 depends on KUNIT
3008 default KUNIT_ALL_TESTS
3009 help
3010 This option enables the KUnit test suite for the min heap library
3011 which provides functions for creating and managing min heaps.
3012 The test suite checks the functionality of the min heap library.
3013
3014 If unsure, say N
3015
3016config IS_SIGNED_TYPE_KUNIT_TEST
3017 tristate "Test is_signed_type() macro" if !KUNIT_ALL_TESTS
3018 depends on KUNIT
3019 default KUNIT_ALL_TESTS
3020 help
3021 Builds unit tests for the is_signed_type() macro.
3022
3023 For more information on KUnit and unit tests in general please refer
3024 to the KUnit documentation in Documentation/dev-tools/kunit/.
3025
3026 If unsure, say N.
3027
3028config OVERFLOW_KUNIT_TEST
3029 tristate "Test check_*_overflow() functions at runtime" if !KUNIT_ALL_TESTS
3030 depends on KUNIT
3031 default KUNIT_ALL_TESTS
3032 help
3033 Builds unit tests for the check_*_overflow(), size_*(), allocation, and
3034 related functions.
3035
3036 For more information on KUnit and unit tests in general please refer
3037 to the KUnit documentation in Documentation/dev-tools/kunit/.
3038
3039 If unsure, say N.
3040
3041config RANDSTRUCT_KUNIT_TEST
3042 tristate "Test randstruct structure layout randomization at runtime" if !KUNIT_ALL_TESTS
3043 depends on KUNIT
3044 default KUNIT_ALL_TESTS
3045 help
3046 Builds unit tests for the checking CONFIG_RANDSTRUCT=y, which
3047 randomizes structure layouts.
3048
3049config STACKINIT_KUNIT_TEST
3050 tristate "Test level of stack variable initialization" if !KUNIT_ALL_TESTS
3051 depends on KUNIT
3052 default KUNIT_ALL_TESTS
3053 help
3054 Test if the kernel is zero-initializing stack variables and
3055 padding. Coverage is controlled by compiler flags,
3056 CONFIG_INIT_STACK_ALL_PATTERN or CONFIG_INIT_STACK_ALL_ZERO.
3057
3058config FORTIFY_KUNIT_TEST
3059 tristate "Test fortified str*() and mem*() function internals at runtime" if !KUNIT_ALL_TESTS
3060 depends on KUNIT
3061 default KUNIT_ALL_TESTS
3062 help
3063 Builds unit tests for checking internals of FORTIFY_SOURCE as used
3064 by the str*() and mem*() family of functions. For testing runtime
3065 traps of FORTIFY_SOURCE, see LKDTM's "FORTIFY_*" tests.
3066
3067config LONGEST_SYM_KUNIT_TEST
3068 tristate "Test the longest symbol possible" if !KUNIT_ALL_TESTS
3069 depends on KUNIT && KPROBES
3070 depends on !PREFIX_SYMBOLS && !CFI && !GCOV_KERNEL
3071 default KUNIT_ALL_TESTS
3072 help
3073 Tests the longest symbol possible
3074
3075 If unsure, say N.
3076
3077config HW_BREAKPOINT_KUNIT_TEST
3078 bool "Test hw_breakpoint constraints accounting" if !KUNIT_ALL_TESTS
3079 depends on HAVE_HW_BREAKPOINT
3080 depends on KUNIT=y
3081 default KUNIT_ALL_TESTS
3082 help
3083 Tests for hw_breakpoint constraints accounting.
3084
3085 If unsure, say N.
3086
3087config SIPHASH_KUNIT_TEST
3088 tristate "Perform selftest on siphash functions" if !KUNIT_ALL_TESTS
3089 depends on KUNIT
3090 default KUNIT_ALL_TESTS
3091 help
3092 Enable this option to test the kernel's siphash (<linux/siphash.h>) hash
3093 functions on boot (or module load).
3094
3095 This is intended to help people writing architecture-specific
3096 optimized versions. If unsure, say N.
3097
3098config USERCOPY_KUNIT_TEST
3099 tristate "KUnit Test for user/kernel boundary protections"
3100 depends on KUNIT
3101 default KUNIT_ALL_TESTS
3102 help
3103 This builds the "usercopy_kunit" module that runs sanity checks
3104 on the copy_to/from_user infrastructure, making sure basic
3105 user/kernel boundary testing is working.
3106
3107config BLACKHOLE_DEV_KUNIT_TEST
3108 tristate "Test blackhole netdev functionality" if !KUNIT_ALL_TESTS
3109 depends on NET
3110 depends on KUNIT
3111 default KUNIT_ALL_TESTS
3112 help
3113 This builds the "blackhole_dev_kunit" module that validates the
3114 data path through this blackhole netdev.
3115
3116 If unsure, say N.
3117
3118config TEST_UDELAY
3119 tristate "udelay test driver"
3120 help
3121 This builds the "udelay_test" module that helps to make sure
3122 that udelay() is working properly.
3123
3124 If unsure, say N.
3125
3126config TEST_STATIC_KEYS
3127 tristate "Test static keys"
3128 depends on m
3129 help
3130 Test the static key interfaces.
3131
3132 If unsure, say N.
3133
3134config TEST_DYNAMIC_DEBUG
3135 tristate "Test DYNAMIC_DEBUG"
3136 depends on DYNAMIC_DEBUG
3137 help
3138 This module registers a tracer callback to count enabled
3139 pr_debugs in a 'do_debugging' function, then alters their
3140 enablements, calls the function, and compares counts.
3141
3142 If unsure, say N.
3143
3144config TEST_KMOD
3145 tristate "kmod stress tester"
3146 depends on m
3147 select TEST_LKM
3148 help
3149 Test the kernel's module loading mechanism: kmod. kmod implements
3150 support to load modules using the Linux kernel's usermode helper.
3151 This test provides a series of tests against kmod.
3152
3153 Although technically you can either build test_kmod as a module or
3154 into the kernel we disallow building it into the kernel since
3155 it stress tests request_module() and this will very likely cause
3156 some issues by taking over precious threads available from other
3157 module load requests, ultimately this could be fatal.
3158
3159 To run tests run:
3160
3161 tools/testing/selftests/kmod/kmod.sh --help
3162
3163 If unsure, say N.
3164
3165config TEST_RUNTIME
3166 bool
3167
3168config TEST_RUNTIME_MODULE
3169 bool
3170
3171config TEST_KALLSYMS
3172 tristate "module kallsyms find_symbol() test"
3173 depends on m
3174 select TEST_RUNTIME
3175 select TEST_RUNTIME_MODULE
3176 select TEST_KALLSYMS_A
3177 select TEST_KALLSYMS_B
3178 select TEST_KALLSYMS_C
3179 select TEST_KALLSYMS_D
3180 help
3181 This allows us to stress test find_symbol() through the kallsyms
3182 used to place symbols on the kernel ELF kallsyms and modules kallsyms
3183 where we place kernel symbols such as exported symbols.
3184
3185 We have four test modules:
3186
3187 A: has KALLSYSMS_NUMSYMS exported symbols
3188 B: uses one of A's symbols
3189 C: adds KALLSYMS_SCALE_FACTOR * KALLSYSMS_NUMSYMS exported
3190 D: adds 2 * the symbols than C
3191
3192 We stress test find_symbol() through two means:
3193
3194 1) Upon load of B it will trigger simplify_symbols() to look for the
3195 one symbol it uses from the module A with tons of symbols. This is an
3196 indirect way for us to have B call resolve_symbol_wait() upon module
3197 load. This will eventually call find_symbol() which will eventually
3198 try to find the symbols used with find_exported_symbol_in_section().
3199 find_exported_symbol_in_section() uses bsearch() so a binary search
3200 for each symbol. Binary search will at worst be O(log(n)) so the
3201 larger TEST_MODULE_KALLSYSMS the worse the search.
3202
3203 2) The selftests should load C first, before B. Upon B's load towards
3204 the end right before we call module B's init routine we get
3205 complete_formation() called on the module. That will first check
3206 for duplicate symbols with the call to verify_exported_symbols().
3207 That is when we'll force iteration on module C's insane symbol list.
3208 Since it has 10 * KALLSYMS_NUMSYMS it means we can first test
3209 just loading B without C. The amount of time it takes to load C Vs
3210 B can give us an idea of the impact growth of the symbol space and
3211 give us projection. Module A only uses one symbol from B so to allow
3212 this scaling in module C to be proportional, if it used more symbols
3213 then the first test would be doing more and increasing just the
3214 search space would be slightly different. The last module, module D
3215 will just increase the search space by twice the number of symbols in
3216 C so to allow for full projects.
3217
3218 tools/testing/selftests/module/find_symbol.sh
3219
3220 The current defaults will incur a build delay of about 7 minutes
3221 on an x86_64 with only 8 cores. Enable this only if you want to
3222 stress test find_symbol() with thousands of symbols. At the same
3223 time this is also useful to test building modules with thousands of
3224 symbols, and if BTF is enabled this also stress tests adding BTF
3225 information for each module. Currently enabling many more symbols
3226 will segfault the build system.
3227
3228 If unsure, say N.
3229
3230if TEST_KALLSYMS
3231
3232config TEST_KALLSYMS_A
3233 tristate
3234 depends on m
3235
3236config TEST_KALLSYMS_B
3237 tristate
3238 depends on m
3239
3240config TEST_KALLSYMS_C
3241 tristate
3242 depends on m
3243
3244config TEST_KALLSYMS_D
3245 tristate
3246 depends on m
3247
3248choice
3249 prompt "Kallsym test range"
3250 default TEST_KALLSYMS_LARGE
3251 help
3252 Selecting something other than "Fast" will enable tests which slow
3253 down the build and may crash your build.
3254
3255config TEST_KALLSYMS_FAST
3256 bool "Fast builds"
3257 help
3258 You won't really be testing kallsysms, so this just helps fast builds
3259 when allmodconfig is used..
3260
3261config TEST_KALLSYMS_LARGE
3262 bool "Enable testing kallsyms with large exports"
3263 help
3264 This will enable larger number of symbols. This will slow down
3265 your build considerably.
3266
3267config TEST_KALLSYMS_MAX
3268 bool "Known kallsysms limits"
3269 help
3270 This will enable exports to the point we know we'll start crashing
3271 builds.
3272
3273endchoice
3274
3275config TEST_KALLSYMS_NUMSYMS
3276 int "test kallsyms number of symbols"
3277 range 2 10000
3278 default 2 if TEST_KALLSYMS_FAST
3279 default 100 if TEST_KALLSYMS_LARGE
3280 default 10000 if TEST_KALLSYMS_MAX
3281 help
3282 The number of symbols to create on TEST_KALLSYMS_A, only one of which
3283 module TEST_KALLSYMS_B will use. This also will be used
3284 for how many symbols TEST_KALLSYMS_C will have, scaled up by
3285 TEST_KALLSYMS_SCALE_FACTOR. Note that setting this to 10,000 will
3286 trigger a segfault today, don't use anything close to it unless
3287 you are aware that this should not be used for automated build tests.
3288
3289config TEST_KALLSYMS_SCALE_FACTOR
3290 int "test kallsyms scale factor"
3291 default 8
3292 help
3293 How many more unusued symbols will TEST_KALLSYSMS_C have than
3294 TEST_KALLSYMS_A. If 8, then module C will have 8 * syms
3295 than module A. Then TEST_KALLSYMS_D will have double the amount
3296 of symbols than C so to allow projections.
3297
3298endif # TEST_KALLSYMS
3299
3300config TEST_DEBUG_VIRTUAL
3301 tristate "Test CONFIG_DEBUG_VIRTUAL feature"
3302 depends on DEBUG_VIRTUAL
3303 help
3304 Test the kernel's ability to detect incorrect calls to
3305 virt_to_phys() done against the non-linear part of the
3306 kernel's virtual address map.
3307
3308 If unsure, say N.
3309
3310config TEST_MEMCAT_P
3311 tristate "Test memcat_p() helper function"
3312 help
3313 Test the memcat_p() helper for correctly merging two
3314 pointer arrays together.
3315
3316 If unsure, say N.
3317
3318config TEST_OBJAGG
3319 tristate "Perform selftest on object aggreration manager"
3320 default n
3321 depends on OBJAGG
3322 help
3323 Enable this option to test object aggregation manager on boot
3324 (or module load).
3325
3326config TEST_MEMINIT
3327 tristate "Test heap/page initialization"
3328 help
3329 Test if the kernel is zero-initializing heap and page allocations.
3330 This can be useful to test init_on_alloc and init_on_free features.
3331
3332 If unsure, say N.
3333
3334config TEST_HMM
3335 tristate "Test HMM (Heterogeneous Memory Management)"
3336 depends on TRANSPARENT_HUGEPAGE
3337 depends on DEVICE_PRIVATE
3338 select HMM_MIRROR
3339 select MMU_NOTIFIER
3340 help
3341 This is a pseudo device driver solely for testing HMM.
3342 Say M here if you want to build the HMM test module.
3343 Doing so will allow you to run tools/testing/selftest/vm/hmm-tests.
3344
3345 If unsure, say N.
3346
3347config TEST_FREE_PAGES
3348 tristate "Test freeing pages"
3349 help
3350 Test that a memory leak does not occur due to a race between
3351 freeing a block of pages and a speculative page reference.
3352 Loading this module is safe if your kernel has the bug fixed.
3353 If the bug is not fixed, it will leak gigabytes of memory and
3354 probably OOM your system.
3355
3356config TEST_FPU
3357 tristate "Test floating point operations in kernel space"
3358 depends on ARCH_HAS_KERNEL_FPU_SUPPORT && !KCOV_INSTRUMENT_ALL
3359 help
3360 Enable this option to add /sys/kernel/debug/selftest_helpers/test_fpu
3361 which will trigger a sequence of floating point operations. This is used
3362 for self-testing floating point control register setting in
3363 kernel_fpu_begin().
3364
3365 If unsure, say N.
3366
3367config TEST_CLOCKSOURCE_WATCHDOG
3368 tristate "Test clocksource watchdog in kernel space"
3369 depends on CLOCKSOURCE_WATCHDOG
3370 help
3371 Enable this option to create a kernel module that will trigger
3372 a test of the clocksource watchdog. This module may be loaded
3373 via modprobe or insmod in which case it will run upon being
3374 loaded, or it may be built in, in which case it will run
3375 shortly after boot.
3376
3377 If unsure, say N.
3378
3379config TEST_OBJPOOL
3380 tristate "Test module for correctness and stress of objpool"
3381 default n
3382 depends on m && DEBUG_KERNEL
3383 help
3384 This builds the "test_objpool" module that should be used for
3385 correctness verification and concurrent testings of objects
3386 allocation and reclamation.
3387
3388 If unsure, say N.
3389
3390config TEST_KEXEC_HANDOVER
3391 bool "Test for Kexec HandOver"
3392 default n
3393 depends on KEXEC_HANDOVER
3394 help
3395 This option enables test for Kexec HandOver (KHO).
3396 The test consists of two parts: saving kernel data before kexec and
3397 restoring the data after kexec and verifying that it was properly
3398 handed over. This test module creates and saves data on the boot of
3399 the first kernel and restores and verifies the data on the boot of
3400 kexec'ed kernel.
3401
3402 For detailed documentation about KHO, see Documentation/core-api/kho.
3403
3404 To run the test run:
3405
3406 tools/testing/selftests/kho/vmtest.sh -h
3407
3408 If unsure, say N.
3409
3410config RATELIMIT_KUNIT_TEST
3411 tristate "KUnit Test for correctness and stress of ratelimit" if !KUNIT_ALL_TESTS
3412 depends on KUNIT
3413 default KUNIT_ALL_TESTS
3414 help
3415 This builds the "test_ratelimit" module that should be used
3416 for correctness verification and concurrent testings of rate
3417 limiting.
3418
3419 If unsure, say N.
3420
3421config UUID_KUNIT_TEST
3422 tristate "KUnit test for UUID" if !KUNIT_ALL_TESTS
3423 depends on KUNIT
3424 default KUNIT_ALL_TESTS
3425 help
3426 This option enables the KUnit test suite for the uuid library,
3427 which provides functions for generating and parsing UUID and GUID.
3428 The test suite checks parsing of UUID and GUID strings.
3429
3430 If unsure, say N.
3431
3432config INT_POW_KUNIT_TEST
3433 tristate "Integer exponentiation (int_pow) test" if !KUNIT_ALL_TESTS
3434 depends on KUNIT
3435 default KUNIT_ALL_TESTS
3436 help
3437 This option enables the KUnit test suite for the int_pow function,
3438 which performs integer exponentiation. The test suite is designed to
3439 verify that the implementation of int_pow correctly computes the power
3440 of a given base raised to a given exponent.
3441
3442 Enabling this option will include tests that check various scenarios
3443 and edge cases to ensure the accuracy and reliability of the exponentiation
3444 function.
3445
3446 If unsure, say N
3447
3448config INT_SQRT_KUNIT_TEST
3449 tristate "Integer square root test" if !KUNIT_ALL_TESTS
3450 depends on KUNIT
3451 default KUNIT_ALL_TESTS
3452 help
3453 This option enables the KUnit test suite for the int_sqrt() function,
3454 which performs square root calculation. The test suite checks
3455 various scenarios, including edge cases, to ensure correctness.
3456
3457 Enabling this option will include tests that check various scenarios
3458 and edge cases to ensure the accuracy and reliability of the square root
3459 function.
3460
3461 If unsure, say N
3462
3463config INT_LOG_KUNIT_TEST
3464 tristate "Integer log (int_log) test" if !KUNIT_ALL_TESTS
3465 depends on KUNIT
3466 default KUNIT_ALL_TESTS
3467 help
3468 This option enables the KUnit test suite for the int_log library, which
3469 provides two functions to compute the integer logarithm in base 2 and
3470 base 10, called respectively as intlog2 and intlog10.
3471
3472 If unsure, say N
3473
3474config GCD_KUNIT_TEST
3475 tristate "Greatest common divisor test" if !KUNIT_ALL_TESTS
3476 depends on KUNIT
3477 default KUNIT_ALL_TESTS
3478 help
3479 This option enables the KUnit test suite for the gcd() function,
3480 which computes the greatest common divisor of two numbers.
3481
3482 This test suite verifies the correctness of gcd() across various
3483 scenarios, including edge cases.
3484
3485 If unsure, say N
3486
3487config PRIME_NUMBERS_KUNIT_TEST
3488 tristate "Prime number generator test" if !KUNIT_ALL_TESTS
3489 depends on KUNIT
3490 depends on PRIME_NUMBERS
3491 default KUNIT_ALL_TESTS
3492 help
3493 This option enables the KUnit test suite for the {is,next}_prime_number
3494 functions.
3495
3496 Enabling this option will include tests that compare the prime number
3497 generator functions against a brute force implementation.
3498
3499 If unsure, say N
3500
3501config GLOB_KUNIT_TEST
3502 tristate "Glob matching test" if !KUNIT_ALL_TESTS
3503 depends on GLOB
3504 depends on KUNIT
3505 default KUNIT_ALL_TESTS
3506 help
3507 Enable this option to test the glob functions at runtime.
3508
3509 This test suite verifies the correctness of glob_match() across various
3510 scenarios, including edge cases.
3511
3512 If unsure, say N
3513
3514endif # RUNTIME_TESTING_MENU
3515
3516config ARCH_USE_MEMTEST
3517 bool
3518 help
3519 An architecture should select this when it uses early_memtest()
3520 during boot process.
3521
3522config MEMTEST
3523 bool "Memtest"
3524 depends on ARCH_USE_MEMTEST
3525 help
3526 This option adds a kernel parameter 'memtest', which allows memtest
3527 to be set and executed.
3528 memtest=0, mean disabled; -- default
3529 memtest=1, mean do 1 test pattern;
3530 ...
3531 memtest=17, mean do 17 test patterns.
3532 If you are unsure how to answer this question, answer N.
3533
3534
3535
3536config HYPERV_TESTING
3537 bool "Microsoft Hyper-V driver testing"
3538 default n
3539 depends on HYPERV && DEBUG_FS
3540 help
3541 Select this option to enable Hyper-V vmbus testing.
3542
3543endmenu # "Kernel Testing and Coverage"
3544
3545menu "Rust hacking"
3546
3547config RUST_DEBUG_ASSERTIONS
3548 bool "Debug assertions"
3549 depends on RUST
3550 help
3551 Enables rustc's `-Cdebug-assertions` codegen option.
3552
3553 This flag lets you turn `cfg(debug_assertions)` conditional
3554 compilation on or off. This can be used to enable extra debugging
3555 code in development but not in production. For example, it controls
3556 the behavior of the standard library's `debug_assert!` macro.
3557
3558 Note that this will apply to all Rust code, including `core`.
3559
3560 If unsure, say N.
3561
3562config RUST_OVERFLOW_CHECKS
3563 bool "Overflow checks"
3564 default y
3565 depends on RUST
3566 help
3567 Enables rustc's `-Coverflow-checks` codegen option.
3568
3569 This flag allows you to control the behavior of runtime integer
3570 overflow. When overflow-checks are enabled, a Rust panic will occur
3571 on overflow.
3572
3573 Note that this will apply to all Rust code, including `core`.
3574
3575 If unsure, say Y.
3576
3577config RUST_BUILD_ASSERT_ALLOW
3578 bool "Allow unoptimized build-time assertions"
3579 depends on RUST
3580 help
3581 Controls how `build_error!` and `build_assert!` are handled during the build.
3582
3583 If calls to them exist in the binary, it may indicate a violated invariant
3584 or that the optimizer failed to verify the invariant during compilation.
3585
3586 This should not happen, thus by default the build is aborted. However,
3587 as an escape hatch, you can choose Y here to ignore them during build
3588 and let the check be carried at runtime (with `panic!` being called if
3589 the check fails).
3590
3591 If unsure, say N.
3592
3593config RUST_KERNEL_DOCTESTS
3594 bool "Doctests for the `kernel` crate" if !KUNIT_ALL_TESTS
3595 depends on RUST && KUNIT=y
3596 default KUNIT_ALL_TESTS
3597 help
3598 This builds the documentation tests of the `kernel` crate
3599 as KUnit tests.
3600
3601 For more information on KUnit and unit tests in general,
3602 please refer to the KUnit documentation in Documentation/dev-tools/kunit/.
3603
3604 If unsure, say N.
3605
3606endmenu # "Rust"
3607
3608endmenu # Kernel hacking