linux/scripts/kconfig/tests, branch v6.18

kconfig: Avoid prompting for transitional symbols

2025-10-07T15:21:23Z

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 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 Link: https://lore.kernel.org/r/20250930154514.it.623-kees@kernel.org Signed-off-by: Kees Cook

kconfig: Add transitional symbol attribute for migration support

2025-09-24T21:23:35Z

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 Signed-off-by: Vegard Nossum Reviewed-by: Nathan Chancellor Tested-by: Nathan Chancellor Link: https://lore.kernel.org/r/20250923213422.1105654-2-kees@kernel.org Signed-off-by: Kees Cook

kconfig: Fix BrokenPipeError warnings in selftests

2025-09-24T21:23:35Z

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 Tested-by: Nathan Chancellor Link: https://lore.kernel.org/r/20250923213422.1105654-1-kees@kernel.org Signed-off-by: Kees Cook

kconfig: recursive checks drop file/lineno

2024-07-20T07:33:45Z

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 Signed-off-by: Masahiro Yamada

kconfig: remove tristate choice support

2024-07-15T16:08:36Z

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 Reviewed-by: Nicolas Schier

kconfig: remove 'optional' property support

2024-05-02T10:48:26Z

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 Reviewed-by: Nicolas Schier

kconfig: tests: test dependency after shuffling choices

2024-03-20T17:40:39Z

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

kconfig: tests: add a test for randconfig with dependent choices

2024-03-20T17:39:55Z

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

kconfig: tests: support KCONFIG_SEED for the randconfig runner

2024-03-20T17:39:40Z

This will help get consistent results for randconfig tests. Signed-off-by: Masahiro Yamada

kconfig: print recursive dependency errors in the parsed order

2024-02-20T11:47:45Z

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