summaryrefslogtreecommitdiff
path: root/scripts/kconfig/tests
AgeCommit message (Collapse)Author
2026-10-09kconfig: use the value argument in sym_get_near_range_bound()Leizhen Zhang
sym_get_near_range_bound() is meant to check whether the given value is outside of the active range of an int/hex symbol, and is called with the symbol's current value from sym_calc_value() and with the default value from sym_get_string_default(). Since commit 9b8719973ee2 ("kconfig: use unsigned integers for hex range checks") it ignores its value argument and uses the current value of the symbol (via sym_get_range_val()) instead. As a result, an out-of-range default is no longer clamped in sym_get_string_default(), and savedefconfig writes out values that are equal to the effective default again, for example CONFIG_A=4 for: config A int "a" range 1 4 default 8 The existing savedefconfig_range test did not catch this because it only covers symbols without a prompt. Parse the value argument again, and add a test case for a symbol with a prompt. Found while fuzzing Kconfig input with ASan/UBSan. Fixes: 9b8719973ee2 ("kconfig: use unsigned integers for hex range checks") Assisted-by: Claude:claude-opus-5-5 Signed-off-by: Leizhen Zhang <lzsx618@gmail.com> Tested-by: Julian Braha <julianbraha@gmail.com> Reviewed-by: Julian Braha <julianbraha@gmail.com> Link: https://patch.msgid.link/20261008164540.3686383-1-lzsx618@gmail.com Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-09-30kconfig: tests: {old,save}defconfig: Forward dynamic keyword argumentsNicolas Schier
Let kconfig test framework forward dynamic keyword arguments for 'olddefconfig' and 'savedefconfig' and update the _run_conf() calls in warn_changed_input to use the corrsponding wrappers instead. The warn_changed_input test needed to use _run_conf() as the {old,save}defconfig wrapper did not provide the necessary flexibility for common calls. With dynamic keyword arguments, there is no need to use the framework-internal _run_conf() any more. Reviewed-by: Julian Braha <julianbraha@gmail.com> Signed-off-by: Nicolas Schier <n.schier@fritz.com> Link: https://patch.msgid.link/20260929-kconfig-tests-minor-updates-v2-4-c5902bee1d0c@fritz.com Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-09-30kconfig: tests: warn_changed_input: Simplify by reusing the extra envNicolas Schier
Define the extra environment once and re-use it for the respective _run_conf() calls to increase readability. Reviewed-by: Julian Braha <julianbraha@gmail.com> Signed-off-by: Nicolas Schier <n.schier@fritz.com> Link: https://patch.msgid.link/20260929-kconfig-tests-minor-updates-v2-3-c5902bee1d0c@fritz.com Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-09-30kconfig: tests: Provide defconfig outfile for savedefconfigNicolas Schier
Let kconfig test framework's 'savedefconfig' forward the requested output 'defconfig' filename to 'conf'. The original implementation was calling 'conf' with '--savedefconfig' but missed the mandatory filename for the defconfig output file. While at it, honour the 'dot_config' argument which points to the input config file. Fixes: 022a4bf6b59d ("kconfig: tests: add framework for Kconfig unit testing") Reviewed-by: Julian Braha <julianbraha@gmail.com> Signed-off-by: Nicolas Schier <n.schier@fritz.com> Link: https://patch.msgid.link/20260929-kconfig-tests-minor-updates-v2-2-c5902bee1d0c@fritz.com Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-09-30kconfig: tests: Reset all KCONFIG_* env variables by defaultNicolas Schier
Reset all environment variables with names starting with 'KCONFIG_' from the user-provided environment. This fixes the 'warn_changed_input' test on systems with KCONFIG_WARN_CHANGED_INPUT=1 and ensures a cleaner test environment. Fixes: 645323a7f4e5 ("kconfig: add optional warnings for changed input values") Signed-off-by: Nicolas Schier <n.schier@fritz.com> Reviewed-by: Julian Braha <julianbraha@gmail.com> Link: https://patch.msgid.link/20260929-kconfig-tests-minor-updates-v2-1-c5902bee1d0c@fritz.com Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-09-24kconfig: Add "def_string", "def_int" and "def_hex"Kees Cook
Kconfig has offered "def_bool" and "def_tristate" as a shorthand for a type definition plus a default since before the git era, but has never offered the equivalent for the other three types. Conor Dooley ran into this gap[1] when fixing a symbol that had been given the wrong type: Unfortunately, there is no such thing as "def_string", but in this case we can use "default" to propagate the value of ... Nothing in the grammar requires the restriction. The rule that consumes a default is already type agnostic. Add the three missing types. No changes are needed to existing diagnostics. E.g. declaring a symbol "bool" and then assigning it with "def_string" still reports warning: ignoring type redefinition of 'CONFLICT' from 'bool' to 'string' Added tests for the types. Build tested ARCH=x86_64 with GCC 16.2.0. Tests pass with "make testconfig". Link: https://lore.kernel.org/all/20230111104848.2088516-1-conor.dooley@microchip.com/ [1] Assisted-by: LLM Signed-off-by: Kees Cook <kees@kernel.org> Tested-by: Julian Braha <julianbraha@gmail.com> Reviewed-by: Julian Braha <julianbraha@gmail.com> Link: https://patch.msgid.link/20260919005929.4077729-1-kees@kernel.org Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-09-24kconfig: warn about malformed KCONFIG_PROBABILITY valuesDmitrii Tulnov
randconfig checks the numeric range of each probability but does not validate where strtol() stops. For example, KCONFIG_PROBABILITY=50% is accepted as 50:0:0: the '%' is parsed repeatedly as zero. For the documented value 50, tristate y/m/n probabilities are 25%/25%/50%. With 50%, both y/m probabilities silently become zero, reducing the coverage of random configuration builds. Empty fields and extra fields are also accepted. Warn when the value does not follow the documented decimal format. For malformed inputs whose parsed probabilities are in range, preserve the existing interpretation unless KCONFIG_WERROR is set. In that case, exit with an error before writing the configuration. Leading whitespace and signs are accepted by strtol(), but also trigger the warning because they are outside the documented format. Keep the strtol() result as long until the range check. This rejects out-of-range values that narrowing to int previously made valid, such as 4294967296 becoming zero on a 64-bit host, regardless of KCONFIG_WERROR. Add regression tests for one warning per malformed input, preserved configurations, KCONFIG_WERROR, out-of-range values, the supported probability formats, and the documented empty-value default. Fixes: e43956e60769 ("kconfig: implement KCONFIG_PROBABILITY for randconfig") Assisted-by: LLM Signed-off-by: Dmitrii Tulnov <tulnov.dl@gmail.com> Tested-by: Julian Braha <julianbraha@gmail.com> Reviewed-by: Julian Braha <julianbraha@gmail.com> Link: https://patch.msgid.link/20260918213430.3-1-tulnov.dl@gmail.com Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-09-17kconfig: use unsigned integers for hex range checksJulian Braha
While 'hex' values should use the bounds of 64-bit unsigned integers, the range values are treated as signed (checks use strtoll). For example: config HEX_RANGE hex range 0 0xfffffffffffffffe default 0xffffffffffffffff the default value should adjust down to the upper bound of 0xfffffffffffffffe, but since the check incorrectly parses both as LLONG_MAX, the value stays at the out-of-range default of 0xffffffffffffffff. To fix this, let's use a union of signed and unsigned integers to represent both 'int' and 'hex' range values, then use both strtoll and strtoull where appropriate. Assisted-by: LLM Signed-off-by: Julian Braha <julianbraha@gmail.com> Reviewed-by: Nicolas Schier <n.schier@fritz.com> Link: https://patch.msgid.link/20260915211508.291790-6-julianbraha@gmail.com Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-09-17kconfig: prevent out-of-bounds user input for numeric optionsJulian Braha
Currently, user input of out-of-bounds values for 'int' and 'hex' options is possible, leading to later silent failures in Kconfig if that value is used in a comparison, or a warning by GCC or error by Clang if used in the C code. Let's factor out the out-of-bounds check on constants, so that it can be reused for checking user input. The frontend will now reject an attempted user input of an out-of-bounds numeric value, similarly to how a value outside the active 'range' already does. For migration of existing configurations, a .config file with an out-of-bounds numeric value will be allowed for now, but will warn the user when read in by confdata.c Assisted-by: LLM Signed-off-by: Julian Braha <julianbraha@gmail.com> Reviewed-by: Nicolas Schier <n.schier@fritz.com> Link: https://patch.msgid.link/20260915211508.291790-5-julianbraha@gmail.com Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-09-17kconfig: check for hex and int mismatchesJulian Braha
Using a numeric option of one type (e.g. 'int') to determine the value of a different numeric type (e.g. 'hex') currently fails silently in various ways if attempted, because the underlying string representation is naively reused. Example 1: config I int default -1 config HEX_DEFAULT_INT hex default I Here, HEX_DEFAULT_INT actually gets set to '0x-1', which is of course not a valid hex value. Example 2: config H hex default A config INT_DEFAULT_HEX int default H Here, INT_DEFAULT_HEX actually gets set to 'A', without even converting into the base-10 equivalent of 10. This value, 'A', is otherwise a rejected int value if entered in the frontend, or read in from an existing .config file. These int-hex mismatches currently do not appear anywhere in the tree, so it is already safe to make these error out. Assisted-by: LLM Signed-off-by: Julian Braha <julianbraha@gmail.com> Reviewed-by: Nicolas Schier <n.schier@fritz.com> Link: https://patch.msgid.link/20260915211508.291790-4-julianbraha@gmail.com Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-09-17kconfig: check for out-of-bounds numeric constantsJulian Braha
The Kconfig interpreter internally represents constants as strings, then attempts to parse them as 64-bit signed integers for 'int' options, and 64-bit unsigned integers for 'hex' options. However, there is currently no check that the conversion succeeds, leading to failures when the values are actually used. For example: config LARGE_INT int default 10000000000000000000 config BUGGED_INT_COMPARISON bool default y if LARGE_INT < 2 Obviously 10000000000000000000 is larger than 2, but the Kconfig interpreter will fallback to comparing the two values with strcmp() after the numeric conversion fails, causing the first character, '1', to be compared with '2', and giving the wrong result. Since none of these out-of-bounds values are used as constants anywhere in the tree, we can already make these error out. Assisted-by: LLM Signed-off-by: Julian Braha <julianbraha@gmail.com> Reviewed-by: Nicolas Schier <n.schier@fritz.com> Link: https://patch.msgid.link/20260915211508.291790-3-julianbraha@gmail.com Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-09-17kconfig: promote invalid numeric reference from warning to errorJulian Braha
The Kconfig interpreter already warns if a numeric option attempts to use a non-numeric option (bool, tristate, or string) to set its value (for example, with a 'default' or 'range'). Since there is nowhere in the tree that attempts this, we can safely promote this check from warning to error. Assisted-by: LLM Signed-off-by: Julian Braha <julianbraha@gmail.com> Reviewed-by: Nicolas Schier <n.schier@fritz.com> Link: https://patch.msgid.link/20260915211508.291790-2-julianbraha@gmail.com Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-09-17kconfig: fix extra output from savedefconfig on out-of-range defaultsJulian Braha
The Kconfig interpreter currently allows defaults that are outside of the range bounds. In these cases, the 'sym_validate_range' function will adjust the default value to the nearest range bound. For example, see this example: config A int range 1 2 default 16 Here, since the default value of 16 is greater than the bounds, the effective default value gets adjusted down to the upper bound, 2. However, 'savedefconfig' writes non-default values, and without being aware of the automatic adjustment to the range bound, it would write: A=2 This limitation is also documented in a comment: "The following fails to handle the situation where a default value is further limited by the valid range." To resolve this, let's factor out the default-range adjustment logic from the existing 'sym_validate_range' function into its own 'sym_get_near_range_bound' function for 'savedefconfig' to use too, so that it compares against the effective value. Adds tests, accordingly. Fixes: 7cf3d73b4360 ("kconfig: add savedefconfig") Assisted-by: Codex:gpt-5.6-sol Reported-by: Geert Uytterhoeven <geert+renesas@glider.be> Closes: https://lore.kernel.org/lkml/CAMuHMdVyUAA3L4mUkSjmnuE3cvj-+N8z-Bhxsh1wa-FQWc=fjw@mail.gmail.com/ Signed-off-by: Julian Braha <julianbraha@gmail.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://patch.msgid.link/20260830221129.2668354-1-julianbraha@gmail.com Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-08-31kconfig: error out for recursive rangeJulian Braha
Currently, it is possible to create recursive ranges with Kconfig, such as: config C int "Enable C" default 1 range A B config A int "Enable A" default 2 range B C config B int "Enable B" default 3 range A C The current outcome of this example above, is that all 3 options are set to 2. There is currently no warning or error if a user attempts this. Several attributes are already checked for recursion, including 'depends on', 'select', and 'imply', and we can extend this to 'range' for numeric options (int and hex types). Recursive ranges are currently not used anywhere in the tree, so it is already safe to make this a hard error. Assisted-by: Codex:gpt-5.6-sol Signed-off-by: Julian Braha <julianbraha@gmail.com> Link: https://patch.msgid.link/20260816215354.1499059-1-julianbraha@gmail.com Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-06-25Merge tag 'kbuild-7.2-2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux Pull more Kbuild updates from Nathan Chancellor: - Link host programs with ld.lld when $(LLVM) is set to match user's expectations that LLVM will be used exclusively during the build process - Fix modpost warnings from static variable name promotion that can happen more aggressively with the recently merged distributed ThinLTO support - Add an optional warning for user-supplied Kconfig values that changed after processing, such as out of range values or options that have incorrect / missing dependencies * tag 'kbuild-7.2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux: kconfig: add optional warnings for changed input values modpost: Ignore Clang LTO suffixes in symbol matching kbuild: Use ld.lld for linking host programs when LLVM is set
2026-06-18kconfig: add optional warnings for changed input valuesPengpeng Hou
When reading .config input, Kconfig stores user-provided values first and then resolves the final value after applying dependencies, ranges, and other constraints. If the final value differs from the user input, Kconfig already tracks that state internally, but it does not provide a focused diagnostic to show which explicit inputs were adjusted. This is particularly confusing for requested values that get forced down by unmet dependencies or clamped by ranges. Add an opt-in diagnostic controlled by KCONFIG_WARN_CHANGED_INPUT. Emit the warnings from conf_write() and conf_write_defconfig() after value resolution. Print the diagnostic to stderr directly, not through the normal message callback, so it remains visible when conf is run with -s, such as from make -s. Keep the diagnostic out of the conf_message() formatting buffer so long warning lists are not truncated, and mark processed symbols as written before the SYMBOL_WRITE check so duplicate menu nodes cannot emit duplicate warnings. Document the new environment variable and add tests for olddefconfig, savedefconfig, and the silent-conf path. Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Tested-by: Julian Braha <julianbraha@gmail.com> Link: https://patch.msgid.link/20260611060000.23858-1-pengpeng@iscas.ac.cn Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-06-15Merge tag 'kbuild-7.2-1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux Pull Kbuild / Kconfig updates from Nathan Chancellor: "Kbuild: - Remove broken module linking exclusion for BTF - Add documentation around how offset header files work - Include unstripped vDSO libraries in pacman packages - Bump minimum version of LLVM for building the kernel to 17.0.1 and clean up unnecessary workarounds - Use a context manager in run-clang-tools - Add dist macro value if present to release tag for RPM packages - Detect and report truncated buf_printf() output in modpost - Add __llvm_covfun and __llvm_covmap to section whitelist in modpost - Support Clang's distributed ThinLTO mode - Remove architecture specific configurations for AutoFDO and Propeller to ease individual architecture maintenance Kconfig: - Add kconfig-sym-check target to look for dangling Kconfig symbol references and invalid tristate literal values - Harden against potential NULL pointer dereference - Fix typo in Kconfig test comment" * tag 'kbuild-7.2-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux: (31 commits) kconfig: tests: fix typo in comment kconfig: Remove the architecture specific config for Propeller kconfig: Remove the architecture specific config for AutoFDO modpost: Add __llvm_covfun and __llvm_covmap to section_white_list kconfig: add kconfig-sym-check static checker kbuild: Remove unnecessary 'T' modifier in cmd_ar_builtin_fixup kbuild: distributed build support for Clang ThinLTO kbuild: move vmlinux.a build rule to scripts/Makefile.vmlinux_a scripts: modpost: detect and report truncated buf_printf() output kbuild: rpm-pkg: append %{?dist} macro to Release tag run-clang-tools: run multiprocessing.Pool as context manager compiler-clang.h: Drop explicit version number from "all" diagnostic macro compiler-clang.h: Remove __cleanup -Wunused-variable workaround kbuild: Remove check for broken scoping with clang < 17 in CC_HAS_ASM_GOTO_OUTPUT x86/entry/vdso32: Remove conditional omission of '.cfi_offset eflags' x86/module: Revert "Deal with GOT based stack cookie load on Clang < 17" x86/build: Drop unnecessary '-ffreestanding' addition to KBUILD_CFLAGS scripts/Makefile.warn: Drop -Wformat handling for clang < 16 riscv: Drop tautological condition from TOOLCHAIN_NEEDS_OLD_ISA_SPEC riscv: Remove tautological condition from selection of ARCH_SUPPORTS_CFI ...
2026-06-09kconfig: tests: fix typo in commentEthan Nelson-Moore
scripts/kconfig/tests/no_write_if_dep_unmet/__init__.py contains a typo "COFIG_" for "CONFIG_". Fix it. Discovered while searching for typos in CONFIG_* variable references. Signed-off-by: Ethan Nelson-Moore <enelsonmoore@gmail.com> Link: https://patch.msgid.link/20260609021712.7965-1-enelsonmoore@gmail.com Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2026-06-05kconfig: Fix repeated include selftest expectationZhou Yuhang
The err_repeated_inc test was added with an expected stderr fixture that does not match the diagnostic printed by kconfig. Running "make testconfig" currently fails in that test even though the parser reports the duplicated include correctly: [stderr] Kconfig.inc1:4: error: repeated inclusion of Kconfig.inc3 Kconfig.inc2:3: note: location of first inclusion of Kconfig.inc3 The fixture expects "Repeated" and "Location" with capital letters, but the diagnostic emitted by scripts/kconfig/util.c uses lowercase words. Update the fixture to match the real message. Fixes: 102d712ded3e ("kconfig: Error out on duplicated kconfig inclusion") Signed-off-by: Zhou Yuhang <zhouyuhang@kylinos.cn> Tested-by: Nicolas Schier <nsc@kernel.org> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Link: https://patch.msgid.link/20260520070800.2265479-1-zhouyuhang1010@163.com Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-02-27kconfig: Error out on duplicated kconfig inclusionNicolas Schier
Let kconfig exit with error on duplicated Kconfig file inclusion. Repeated inclusion of Kbuild files are considered bad-practise with regard to maintenance; and Kconfig language is rich enough that there should be no need for that. If repeated inclusion of Kconfig files is detected, error out with messages like: Kconfig.inc1:4: error: repeated inclusion of Kconfig.inc3 Kconfig.inc2:3: note: location of first inclusion of Kconfig.inc3 While commit f094f8a1b273 ("kconfig: allow multiple inclusion of the same file") introduced detection of recursive inclusions of Kconfig files, it explicitly allowed repeated inclusions, unfortunately w/o reasoning. Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Closes: https://lore.kernel.org/all/CAHk-=wj03hLzK2D=+OYmjgcmGM+XYymp8GyaEs=C0=rXG2nb7w@mail.gmail.com/ Reviewed-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Link: https://patch.msgid.link/20260220-kconfig-error-out-on-duplicated-inclusion-v1-1-be78aa241a53@kernel.org Signed-off-by: Nicolas Schier <nsc@kernel.org>
2026-01-06kconfig: Support conditional deps using "depends on X if Y"Nicolas Pitre
Extend the "depends on" syntax to support conditional dependencies using "depends on X if Y". While functionally equivalent to "depends on X || (Y == n)", "depends on X if Y" is much more readable and makes the kconfig language uniform in supporting the "if <expr>" suffix. This also improves readability for "optional" dependencies, which are the subset of conditional dependencies where X is Y. Previously such optional dependencies had to be expressed as the counterintuitive "depends on X || !X", now this can be represented as "depends on X if X". The change is implemented by converting the "X if Y" syntax into the "X || (Y == n)" syntax during "depends on" token processing. Signed-off-by: Nicolas Pitre <nico@fluxnic.net> [Graham Roff: Rewrote commit message, updated patch, added tests] Signed-off-by: Graham Roff <grahamr@qti.qualcomm.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Link: https://patch.msgid.link/20251215-kconfig_conditional_deps-v3-1-59519af0a5df@qti.qualcomm.com [nathan: Minor adjustments to spacing] Signed-off-by: Nathan Chancellor <nathan@kernel.org>
2025-10-07kconfig: Avoid prompting for transitional symbolsKees Cook
The "transitional" symbol keyword, while working with the "olddefconfig" target, was prompting during "oldconfig". This occurred because these symbols were not being marked as user-defined when they received values from transitional symbols that had user values. The "olddefconfig" target explicitly doesn't prompt for anything, so this deficiency wasn't noticed. The issue manifested when a symbol's value came from a transitional symbol's user value but the receiving symbol wasn't marked with SYMBOL_DEF_USER. Thus the "oldconfig" logic would then prompt for these symbols unnecessarily. Check after value calculation whether a symbol without a user value gets its value from a single transitional symbol that does have a user value. In such cases, mark the receiving symbol as user-defined to prevent prompting. Update regression tests to verify that symbols with transitional defaults are not prompted in "oldconfig", except when conditional defaults evaluate to 'no' and should legitimately be prompted. Build tested with "make testconfig". Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Closes: https://lore.kernel.org/lkml/CAHk-=wgZjUk4Cy2XgNkTrQoO8XCmNUHrTe5D519Fij1POK+3qw@mail.gmail.com/ Fixes: f9afce4f32e9 ("kconfig: Add transitional symbol attribute for migration support") Cc: Vegard Nossum <vegard.nossum@oracle.com> Link: https://lore.kernel.org/r/20250930154514.it.623-kees@kernel.org Signed-off-by: Kees Cook <kees@kernel.org>
2025-09-24kconfig: Add transitional symbol attribute for migration supportKees Cook
During kernel option migrations (e.g. CONFIG_CFI_CLANG to CONFIG_CFI), existing .config files need to maintain backward compatibility while preventing deprecated options from appearing in newly generated configurations. This is challenging with existing Kconfig mechanisms because: 1. Simply removing old options breaks existing .config files. 2. Manually listing an option as "deprecated" leaves it needlessly visible and still writes them to new .config files. 3. Using any method to remove visibility (.e.g no 'prompt', 'if n', etc) prevents the option from being processed at all. Add a "transitional" attribute that creates symbols which are: - Processed during configuration (can influence other symbols' defaults) - Hidden from user menus (no prompts appear) - Omitted from newly written .config files (gets migrated) - Restricted to only having help sections (no defaults, selects, etc) making it truly just a "prior value pass-through" option. The transitional syntax requires a type argument and prevents type redefinition: config NEW_OPTION bool "New option" default OLD_OPTION config OLD_OPTION bool transitional help Transitional config for OLD_OPTION migration. This allows seamless migration: olddefconfig processes existing CONFIG_OLD_OPTION=y settings to enable CONFIG_NEW_OPTION=y, while CONFIG_OLD_OPTION is omitted from newly generated .config files. Added positive and negative testing via "testconfig" make target. Co-developed-by: Vegard Nossum <vegard.nossum@oracle.com> Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20250923213422.1105654-2-kees@kernel.org Signed-off-by: Kees Cook <kees@kernel.org>
2025-09-24kconfig: Fix BrokenPipeError warnings in selftestsKees Cook
The kconfig test harness ("make testconfig") was generating BrokenPipeError warnings when running interactive tests like oldaskconfig and oldconfig: /usr/lib/python3/dist-packages/_pytest/unraisableexception.py:85: PytestUnraisableExceptionWarning: Exception ignored in: <_io.BufferedWriter name=12> Traceback (most recent call last): File "/srv/code/scripts/kconfig/tests/conftest.py", line 127, in oldaskconfig return self._run_conf('--oldaskconfig', dot_config=dot_config, ~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ interactive=True, in_keys=in_keys) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ BrokenPipeError: [Errno 32] Broken pipe The issue occurred when the test framework attempted to write to stdin after the conf subprocess had already exited. Wrap stdin write operations in try/except to catch BrokenPipeError and stop sending more input. Add explicit flush() after writes so we can see delivery errors immediately. Ignore BrokenPipeError when closing stdin. Explicitly call wait() to validate subprocess termination. Reviewed-by: Nathan Chancellor <nathan@kernel.org> Tested-by: Nathan Chancellor <nathan@kernel.org> Link: https://lore.kernel.org/r/20250923213422.1105654-1-kees@kernel.org Signed-off-by: Kees Cook <kees@kernel.org>
2024-07-20kconfig: recursive checks drop file/linenoHONG Yifan
This prevents segfault when getting filename and lineno in recursive checks. If the following snippet is found in Kconfig: [Test code 1] config FOO bool depends on BAR select BAR ... without BAR defined; then there is a segfault. Kconfig:34:error: recursive dependency detected! Kconfig:34: symbol FOO depends on BAR make[4]: *** [scripts/kconfig/Makefile:85: allnoconfig] Segmentation fault This is because of the following. BAR is a fake entry created by sym_lookup() with prop being NULL. In the recursive check, there is a NULL check for prop to fall back to stack->sym->prop if stack->prop is NULL. However, in this case, stack->sym points to the fake BAR entry created by sym_lookup(), so prop is still NULL. prop was then referenced without additional NULL checks, causing segfault. As the previous email thread suggests, the file and lineno for select is also wrong: [Test code 2] config FOO bool config BAR bool config FOO bool "FOO" depends on BAR select BAR $ make defconfig *** Default configuration is based on 'x86_64_defconfig' Kconfig:1:error: recursive dependency detected! Kconfig:1: symbol FOO depends on BAR Kconfig:4: symbol BAR is selected by FOO [...] Kconfig:4 should be Kconfig:10. This patch deletes the wrong and segfault-prone filename/lineno inference completely. With this patch, Test code 1 yields: error: recursive dependency detected! symbol FOO depends on BAR symbol BAR is selected by FOO Signed-off-by: HONG Yifan <elsk@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-07-16kconfig: remove tristate choice supportMasahiro Yamada
I previously submitted a fix for a bug in the choice feature [1], where I mentioned, "Another (much cleaner) approach would be to remove the tristate choice support entirely". There are more issues in the tristate choice feature. For example, you can observe a couple of bugs in the following test code. [Test Code] config MODULES def_bool y modules choice prompt "tristate choice" default A config A tristate "A" config B tristate "B" endchoice Bug 1: the 'default' property is not correctly processed 'make alldefconfig' produces: CONFIG_MODULES=y # CONFIG_A is not set # CONFIG_B is not set However, the correct output should be: CONFIG_MODULES=y CONFIG_A=y # CONFIG_B is not set The unit test file, scripts/kconfig/tests/choice/alldef_expected_config, is wrong as well. Bug 2: choice members never get 'y' with randconfig For the test code above, the following combinations are possible: A B (1) y n (2) n y (3) m m (4) m n (5) n m (6) n n 'make randconfig' never produces (1) or (2). These bugs are fixable, but a more critical problem is the lack of a sensible syntax to specify the default for the tristate choice. The default for the choice must be one of the choice members, which cannot specify any of the patterns (3) through (6) above. In addition, I have never seen it being used in a useful way. The following commits removed unnecessary use of tristate choices: - df8df5e4bc37 ("usb: get rid of 'choice' for legacy gadget drivers") - bfb57ef0544a ("rapidio: remove choice for enumeration") This commit removes the tristate choice support entirely, which allows me to delete a lot of code, making further refactoring easier. Note: This includes the revert of commit fa64e5f6a35e ("kconfig/symbol.c: handle choice_values that depend on 'm' symbols"). It was suspicious because it did not address the root cause but introduced inconsistency in visibility between choice members and other symbols. [1]: https://lore.kernel.org/linux-kbuild/20240427104231.2728905-1-masahiroy@kernel.org/T/#m0a1bb6992581462ceca861b409bb33cb8fd7dbae Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
2024-05-02kconfig: remove 'optional' property supportMasahiro Yamada
The 'choice' statement is primarily used to exclusively select one option, but the 'optional' property allows all entries to be disabled. In the following example, both A and B can be disabled simultaneously: choice prompt "choose A, B, or nothing" optional config A bool "A" config B bool "B" endchoice You can achieve the equivalent outcome by other means. A common solution is to add another option to guard the choice block. In the following example, you can set ENABLE_A_B_CHOICE=n to disable the entire choice block: choice prompt "choose A or B" depends on ENABLE_A_B_CHOICE config A bool "A" config B bool "B" endchoice Another approach is to insert one more entry: choice prompt "choose A, B, or disable both" config A bool "A" config B bool "B" config DISABLE_A_AND_B bool "choose this to disable both A and B" endchoice Some real examples are DEBUG_INFO_NONE, INITRAMFS_COMPRESSION_NONE, LTO_NONE, etc. The 'optional' property is even more unnecessary for a tristate choice. Without the 'optional' property, you can disable A and B; you can set 'm' in the choice prompt, and disable A and B individually: choice prompt "choose one built-in or make them modular" config A tristate "A" config B tristate "B" endchoice In conclusion, the 'optional' property was unneeded. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <n.schier@avm.de>
2024-03-21kconfig: tests: test dependency after shuffling choicesMasahiro Yamada
Commit c8fb7d7e48d1 ("kconfig: fix broken dependency in randconfig- generated .config") fixed the issue, but I did not add a test case. This commit adds a test case that emulates the reported situation. The test would fail without c8fb7d7e48d1. To handle the choice "choose X", FOO must be calculated beforehand. FOO depends on A, which is a member of another choice "choose A or B". Kconfig _temporarily_ assumes the value of A to proceed. The choice "choose A or B" will be shuffled later, but the result may or may not meet "FOO depends on A". Kconfig should invalidate the symbol values and recompute them. In the real example for ARCH=arm64, the choice "Instrumentation type" needs the value of CPU_BIG_ENDIAN. The choice "Endianness" will be shuffled later. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-03-21kconfig: tests: add a test for randconfig with dependent choicesMasahiro Yamada
Since commit 3b9a19e08960 ("kconfig: loop as long as we changed some symbols in randconfig"), conf_set_all_new_symbols() is repeated until there is no more choice left to be shuffled. The motivation was to shuffle a choice nested in another choice. Although commit 09d5873e4d1f ("kconfig: allow only 'config', 'comment', and 'if' inside 'choice'") disallowed the nested choice structure, we must still keep 3b9a19e08960 because there are still cases where conf_set_all_new_symbols() must iterate. scripts/kconfig/tests/choice_randomize/Kconfig is the test case. The second choice depends on 'B', which is the member of the first choice. With 3b9a19e08960 reverted, we would never get the pattern specified by scripts/kconfig/tests/choice_randomize/expected_config2. A real example can be found in lib/Kconfig.debug. Without 3b9a19e08960, the randconfig would not shuffle the "Compressed Debug information" choice, which depends on DEBUG_INFO, which is derived from another choice "Debug information". My goal is to refactor Kconfig so that randconfig will work more simply, without using the loop. For now, let's add a test case to ensure all dependent choices are shuffled, as it is a somewhat tricky case for the current Kconfig. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-03-21kconfig: tests: support KCONFIG_SEED for the randconfig runnerMasahiro Yamada
This will help get consistent results for randconfig tests. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-02-20kconfig: print recursive dependency errors in the parsed orderMasahiro Yamada
for_all_symbols() iterates in the symbol hash table. The order of iteration depends on the hash table implementation. If you use it for printing errors, they are shown in random order. For example, the order of following test input and the corresponding error do not match: - scripts/kconfig/tests/err_recursive_dep/Kconfig - scripts/kconfig/tests/err_recursive_dep/expected_stderr Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-04-14kconfig: change "modules" from sub-option to first-level attributeMasahiro Yamada
Now "modules" is the only member of the "option" property. Remove "option", and move "modules" to the top level property. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-04-14kconfig: change defconfig_list option to environment variableMasahiro Yamada
"defconfig_list" is a weird option that defines a static symbol that declares the list of base config files in case the .config does not exist yet. This is quite different from other normal symbols; we just abused the "string" type and the "default" properties to list out the input files. They must be fixed values since these are searched for and loaded in the parse stage. It is an ugly hack, and should not exist in the first place. Providing this feature as an environment variable is a saner approach. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-05-12kconfig: tests: remove randconfig test for choice in choiceMasahiro Yamada
Nesting choice statements does not make any sense. Commit df8df5e4bc37 ("usb: get rid of 'choice' for legacy gadget drivers") got rid of the only usecase. I will turn it into a syntax error. Remove the test in advance. Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2019-06-14docs: kbuild: convert docs to ReST and rename to *.rstMauro Carvalho Chehab
The kbuild documentation clearly shows that the documents there are written at different times: some use markdown, some use their own peculiar logic to split sections. Convert everything to ReST without affecting too much the author's style and avoiding adding uneeded markups. The conversion is actually: - add blank lines and identation in order to identify paragraphs; - fix tables markups; - add some lists markups; - mark literal blocks; - adjust title markups. At its new index.rst, let's add a :orphan: while this is not linked to the main index.rst file, in order to avoid build warnings. Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
2019-06-05kconfig: tests: fix recursive inclusion unit testMasahiro Yamada
Adding SPDX license identifier is pretty safe; however, here is one exception. Since commit ec8f24b7faaf ("treewide: Add SPDX license identifier - Makefile/Kconfig"), "make testconfig" would not pass. When Kconfig detects a circular file inclusion, it displays error messages with a file name and a line number prefixed to each line. The unit test checks if Kconfig emits the error messages correctly (this also checks the line number correctness). Now that the test input has the SPDX license identifier at the very top, the line numbers in the expected stderr should be incremented by 1. Fixes: ec8f24b7faaf ("treewide: Add SPDX license identifier - Makefile/Kconfig") Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-05-21treewide: Add SPDX license identifier - Makefile/KconfigThomas Gleixner
Add SPDX license identifiers to all Make/Kconfig files which: - Have no license information of any form These files fall under the project license, GPL v2 only. The resulting SPDX license identifier is: GPL-2.0-only Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-28kconfig: convert to SPDX License IdentifierMasahiro Yamada
All files in lxdialog/ are licensed under GPL-2.0+, and the rest are under GPL-2.0. I added GPL-2.0 tags to test scripts in tests/. Documentation/process/license-rules.rst does not suggest anything about the flex/bison files. Because flex does not accept the C++ comment style at the very top of a file, I used the C style for zconf.l, and so for zconf.y for consistency. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-08-22kconfig: improve the recursive dependency reportMasahiro Yamada
This commit improves the messages of the recursive dependency. Currently, sym->dir_dep.expr is not checked. Hence, any dependency in property visibility is regarded as the dependency of the symbol. [Test Code 1] config A bool "a" depends on B config B bool "b" depends on A [Test Code 2] config A bool "a" if B config B bool "b" depends on A For both cases above, the same message is displayed: symbol B depends on A symbol A depends on B This commit changes the message for the latter, like this: symbol B depends on A symbol A prompt is visible depending on B Also, 'select' and 'imply' are distinguished. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Tested-by: Dirk Gouders <dirk@gouders.net>
2018-08-22kconfig: report recursive dependency involving 'imply'Masahiro Yamada
Currently, Kconfig does not complain about the recursive dependency where 'imply' keywords are involved. [Test Code] config A bool "a" config B bool "b" imply A depends on A In the code above, Kconfig cannot calculate the symbol values correctly due to the circular dependency. For example, allyesconfig followed by syncconfig results in an odd behavior because CONFIG_B becomes visible in syncconfig. $ make allyesconfig scripts/kconfig/conf --allyesconfig Kconfig # # configuration written to .config # $ cat .config # # Automatically generated file; DO NOT EDIT. # Main menu # CONFIG_A=y $ make syncconfig scripts/kconfig/conf --syncconfig Kconfig * * Restart config... * * * Main menu * a (A) [Y/n/?] y b (B) [N/y/?] (NEW) To detect this correctly, sym_check_expr_deps() should recurse to not only sym->rev_dep.expr but also sym->implied.expr . At this moment, sym_check_print_recursive() cannot distinguish 'select' and 'imply' since it does not know the precise context where the recursive dependency has been hit. This will be solved by the next commit. In fact, even the document and the unit-test are confused. Using 'imply' does not solve recursive dependency since 'imply' addresses the unmet direct dependency, which 'select' could cause. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Tested-by: Dirk Gouders <dirk@gouders.net>
2018-08-22kconfig: error out when seeing recursive dependencyMasahiro Yamada
Originally, recursive dependency was a fatal error for Kconfig because Kconfig cannot compute symbol values in such a situation. Commit d595cea62403 ("kconfig: print more info when we see a recursive dependency") changed it to a warning, which I guess was not intentional. Get it back to an error again. Also, rename the unit test directory "warn_recursive_dep" to "err_recursive_dep" so that it matches to the behavior. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Tested-by: Dirk Gouders <dirk@gouders.net>
2018-05-29kconfig: test: add Kconfig macro language testsMasahiro Yamada
Here are the test cases I used for developing the text expansion feature. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-05-29kconfig: make default prompt of mainmenu less specificMasahiro Yamada
If "mainmenu" is not specified, "Linux Kernel Configuration" is used as a default prompt. Given that Kconfig is used in other projects than Linux, let's use a more generic prompt, "Main menu". Suggested-by: Sam Ravnborg <sam@ravnborg.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-26kconfig: remove duplicated file name and lineno of recursive inclusionMasahiro Yamada
As in the unit test, the error message for the recursive inclusion looks like this: Kconfig.inc1:4: recursive inclusion detected. Inclusion path: current file : 'Kconfig.inc1' included from: 'Kconfig.inc3:1' included from: 'Kconfig.inc2:3' included from: 'Kconfig.inc1:4' The 'Kconfig.inc1:4' is duplicated in the first and last lines. Also, the single quotes do not help readability. Change the message like follows: Recursive inclusion detected. Inclusion path: current file : Kconfig.inc1 included from: Kconfig.inc3:1 included from: Kconfig.inc2:3 included from: Kconfig.inc1:4 Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-26kconfig: tests: test if recursive inclusion is detectedMasahiro Yamada
If recursive inclusion is detected, it should fail with error messages. Test this. This also tests the line numbers in the error message, fixed by commit 5ae6fcc4bb82 ("kconfig: fix line number in recursive inclusion error message"). Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
2018-03-26kconfig: tests: test if recursive dependencies are detectedMasahiro Yamada
Recursive dependency should be detected and warned. Test this. This indirectly tests the line number increments. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
2018-03-26kconfig: tests: test randconfig for choice in choiceMasahiro Yamada
Commit 3b9a19e08960 ("kconfig: loop as long as we changed some symbols in randconfig") fixed randconfig where a choice contains a sub-choice. Prior to that commit, the sub-choice values were not set. I am not sure whether this is an intended feature or just something people discovered works, but it is used in the real world; drivers/usb/gadget/legacy/Kconfig is source'd in a choice context, then creates a sub-choice in it. For the test case in this commit, there are 3 possible results. Case 1: CONFIG_A=y # CONFIG_B is not set Case 2: # CONFIG_A is not set CONFIG_B=y CONFIG_C=y # CONFIG_D is not set Case 3: # CONFIG_A is not set CONFIG_B=y # CONFIG_C is not set CONFIG_D=y CONFIG_E=y So, this test iterates several times, and checks if the result is either of the three. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
2018-03-26kconfig: tests: test defconfig when two choices interactMasahiro Yamada
Commit fbe98bb9ed3d ("kconfig: Fix defconfig when one choice menu selects options that another choice menu depends on") fixed defconfig when two choices interact (i.e. calculating the visibility of a choice requires to calculate another choice). The test code in that commit log was based on the real world example, and complicated. So, I shrunk it down to the following: defconfig.choice: ---8<--- CONFIG_CHOICE_VAL0=y ---8<--- ---8<--- config MODULES def_bool y option modules choice prompt "Choice" config CHOICE_VAL0 tristate "Choice 0" config CHOICE_VAL1 tristate "Choice 1" endchoice choice prompt "Another choice" depends on CHOICE_VAL0 config DUMMY bool "dummy" endchoice ---8<--- Prior to commit fbe98bb9ed3d, $ scripts/kconfig/conf --defconfig=defconfig.choice Kconfig.choice resulted in: CONFIG_MODULES=y CONFIG_CHOICE_VAL0=m # CONFIG_CHOICE_VAL1 is not set CONFIG_DUMMY=y where the expected result would be: CONFIG_MODULES=y CONFIG_CHOICE_VAL0=y # CONFIG_CHOICE_VAL1 is not set CONFIG_DUMMY=y Roughly, this weird behavior happened like this: Symbols are calculated a couple of times. First, all symbols are calculated in conf_read(). The first 'choice' is evaluated to 'y' due to the SYMBOL_DEF_USER flag, but sym_calc_choice() clears it unless all of its choice values are explicitly set by the user. conf_set_all_new_symbols() clears all SYMBOL_VALID flags. Then, only choices are calculated. Here, the SYMBOL_DEF_USER for the first choice has been forgotten, so it is evaluated to 'm'. set_all_choice_values() sets SYMBOL_DEF_USER again to choice symbols. When calculating the second choice, due to 'depends on CHOICE_VAL0', it triggers the calculation of CHOICE_VAL0. As a result, SYMBOL_VALID is set for CHOICE_VAL0. Symbols except choices get the final chance of re-calculation in conf_write(). In a normal case, CHOICE_VAL0 would be re-calculated, then the first choice would be indirectly re-calculated with the SYMBOL_DEF_USER which has been recalled by set_all_choice_values(), which would be evaluated to 'y'. But, in this case, CHOICE_VAL0 has already been marked as SYMBOL_VALID, so this re-calculation does not happen. Then, =m from the conf_set_all_new_symbols() phase is written out to the .config file. Add a unit test for this naive case. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
2018-03-26kconfig: tests: check visibility of tristate choice values in y choiceMasahiro Yamada
If tristate choice values depend on symbols set to 'm', they should be hidden when the choice containing them is changed from 'm' to 'y' (i.e. exclusive choice). This issue was fixed by commit fa64e5f6a35e ("kconfig/symbol.c: handle choice_values that depend on 'm' symbols"). Add a test case to avoid regression. For the input in this unit test, there is a room for argument if "# CONFIG_CHOICE1 is not set" should be written to the .config file. After commit fa64e5f6a35e, this line was written to the .config file. With commit cb67ab2cd2b8 ("kconfig: do not write choice values when their dependency becomes n"), it is not written now. In this test, "# CONFIG_CHOICE1 is not set" is don't care. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>
2018-03-26kconfig: tests: check unneeded "is not set" with unmet dependencyMasahiro Yamada
Commit cb67ab2cd2b8 ("kconfig: do not write choice values when their dependency becomes n") fixed a problem where "# CONFIG_... is not set" for choice values are wrongly written into the .config file when they are once visible, then become invisible later. Add a test for this naive case. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Ulf Magnusson <ulfalizer@gmail.com>