linux-stable.git/scripts/kconfig/tests, branch master

Merge tag 'kbuild-7.2-1' of git://git.kernel.org/pub/scm/linux/kernel/git/kbuild/linux

2026-06-14T23:31:15+00:00

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
  ...

kconfig: tests: fix typo in comment

2026-06-09T23:28:46+00:00

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 
Link: https://patch.msgid.link/20260609021712.7965-1-enelsonmoore@gmail.com
Signed-off-by: Nathan Chancellor

kconfig: Fix repeated include selftest expectation

2026-06-05T17:24:49+00:00

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 
Tested-by: Nicolas Schier 
Reviewed-by: Nathan Chancellor 
Link: https://patch.msgid.link/20260520070800.2265479-1-zhouyuhang1010@163.com
Signed-off-by: Nicolas Schier

kconfig: Error out on duplicated kconfig inclusion

2026-02-27T08:26:58+00:00

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 
Closes: https://lore.kernel.org/all/CAHk-=wj03hLzK2D=+OYmjgcmGM+XYymp8GyaEs=C0=rXG2nb7w@mail.gmail.com/
Reviewed-by: Nathan Chancellor 
Tested-by: Nathan Chancellor 
Link: https://patch.msgid.link/20260220-kconfig-error-out-on-duplicated-inclusion-v1-1-be78aa241a53@kernel.org
Signed-off-by: Nicolas Schier

kconfig: Support conditional deps using "depends on X if Y"

2026-01-06T21:57:15+00:00

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 "
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 
[Graham Roff: Rewrote commit message, updated patch, added tests]
Signed-off-by: Graham Roff 
Acked-by: Randy Dunlap 
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

kconfig: Avoid prompting for transitional symbols

2025-10-07T15:21:23+00:00

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:35+00:00

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:35+00:00

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:45+00:00

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:36+00:00

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