linux.git/scripts/kconfig/parser.y, branch v6.12.80

kconfig: fix infinite loop in sym_calc_choice()

2024-09-30T11:42:52+00:00

Since commit f79dc03fe68c ("kconfig: refactor choice value calculation"),
Kconfig for ARCH=powerpc may result in an infinite loop. This occurs
because there are two entries for POWERPC64_CPU in a choice block.

If the same symbol appears twice in a choice block, the ->choice_link
node is added twice to ->choice_members, resulting a corrupted linked
list.

A simple test case is:

    choice
            prompt "choice"

    config A
            bool "A"

    config B
            bool "B 1"

    config B
            bool "B 2"

    endchoice

Running 'make defconfig' results in an infinite loop.

One solution is to replace the current two entries:

    config POWERPC64_CPU
            bool "Generic (POWER5 and PowerPC 970 and above)"
            depends on PPC_BOOK3S_64 && !CPU_LITTLE_ENDIAN
            select PPC_64S_HASH_MMU

    config POWERPC64_CPU
            bool "Generic (POWER8 and above)"
            depends on PPC_BOOK3S_64 && CPU_LITTLE_ENDIAN
            select ARCH_HAS_FAST_MULTIPLIER
            select PPC_64S_HASH_MMU
            select PPC_HAS_LBARX_LHARX

with the following single entry:

    config POWERPC64_CPU
            bool "Generic 64 bit powerpc"
            depends on PPC_BOOK3S_64
            select ARCH_HAS_FAST_MULTIPLIER if CPU_LITTLE_ENDIAN
            select PPC_64S_HASH_MMU
            select PPC_HAS_LBARX_LHARX if CPU_LITTLE_ENDIAN

In my opinion, the latter looks cleaner, but PowerPC maintainers may
prefer to display different prompts depending on CPU_LITTLE_ENDIAN.

For now, this commit fixes the issue in Kconfig, restoring the original
behavior. I will reconsider whether such a use case is worth supporting.

Fixes: f79dc03fe68c ("kconfig: refactor choice value calculation")
Reported-by: Marco Bonelli 
Closes: https://lore.kernel.org/all/1763151587.3581913.1727224126288@privateemail.com/
Signed-off-by: Masahiro Yamada

kbuild: split x*alloc() functions in kconfig to scripts/include/xalloc.h

2024-09-01T11:34:48+00:00

These functions will be useful for other host programs.

Signed-off-by: Masahiro Yamada

kconfig: remove P_SYMBOL property

2024-09-01T11:34:48+00:00

P_SYMBOL is a pseudo property that was previously used for data linking
purposes.

It is no longer used except for debug prints. Remove it.

Signed-off-by: Masahiro Yamada

kconfig: remove dummy assignments to cur_{filename,lineno}

2024-09-01T11:34:47+00:00

Since commit ca4c74ba306e ("kconfig: remove P_CHOICE property"),
menu_finalize() no longer calls menu_add_symbol(). No function
references cur_filename or cur_lineno after yyparse().

Signed-off-by: Masahiro Yamada

kconfig: add const qualifiers to several function arguments

2024-07-16T07:07:14+00:00

Clarify that the given structures are not modified.

Signed-off-by: Masahiro Yamada

kconfig: remove P_CHOICE property

2024-07-15T16:08:37+00:00

P_CHOICE is a pseudo property used to link a choice with its members.

There is no more code relying on this, except for some debug code.

Signed-off-by: Masahiro Yamada

kconfig: refactor choice value calculation

2024-07-15T16:08:37+00:00

Handling choices has always been in a PITA in Kconfig.

For example, fixes and reverts were repeated for randconfig with
KCONFIG_ALLCONFIG:

 - 422c809f03f0 ("kconfig: fix randomising choice entries in presence of KCONFIG_ALLCONFIG")
 - 23a5dfdad22a ("Revert "kconfig: fix randomising choice entries in presence of KCONFIG_ALLCONFIG"")
 - 8357b48549e1 ("kconfig: fix randomising choice entries in presence of KCONFIG_ALLCONFIG")
 - 490f16171119 ("Revert "kconfig: fix randomising choice entries in presence of KCONFIG_ALLCONFIG"")

As these commits pointed out, randconfig does not randomize choices when
KCONFIG_ALLCONFIG is used. This issue still remains.

[Test Case]

    choice
            prompt "choose"

    config A
            bool "A"

    config B
            bool "B"

    endchoice

    $ echo > all.config
    $ make KCONFIG_ALLCONFIG=1 randconfig

The output is always as follows:

    CONFIG_A=y
    # CONFIG_B is not set

Not only randconfig, but other all*config variants are also broken with
KCONFIG_ALLCONFIG.

With the same Kconfig,

    $ echo '# CONFIG_A is not set' > all.config
    $ make KCONFIG_ALLCONFIG=1 allyesconfig

You will get this:

    CONFIG_A=y
    # CONFIG_B is not set

This is incorrect because it does not respect all.config.

The correct output should be:

    # CONFIG_A is not set
    CONFIG_B=y

To handle user inputs more accurately, this commit refactors the code
based on the following principles:

 - When a user value is given, Kconfig must set it immediately.
   Do not defer it by setting SYMBOL_NEED_SET_CHOICE_VALUES.

 - The SYMBOL_DEF_USER flag must not be cleared, unless a new config
   file is loaded. Kconfig must not forget user inputs.

In addition, user values for choices must be managed with priority.
If user inputs conflict within a choice block, the newest value wins.
The values given by randconfig have lower priority than explicit user
inputs.

This commit implements it by using a linked list. Every time a choice
block gets a new input, it is moved to the top of the list.

Let me explain how it works.

Let's say, we have a choice block that consists of five symbols:
A, B, C, D, and E.

Initially, the linked list looks like this:

    A(=?) --> B(=?) --> C(=?) --> D(=?) --> E(=?)

Suppose randconfig is executed with the following KCONFIG_ALLCONFIG:

    CONFIG_C=y
    # CONFIG_A is not set
    CONFIG_D=y

First, CONFIG_C=y is read. C is set to 'y' and moved to the top.

    C(=y) --> A(=?) --> B(=?) --> D(=?) --> E(=?)

Next, '# CONFIG_A is not set' is read. A is set to 'n' and moved to
the top.

    A(=n) --> C(=y) --> B(=?) --> D(=?) --> E(=?)

Then, 'CONFIG_D=y' is read. D is set to 'y' and moved to the top.

    D(=y) --> A(=n) --> C(=y) --> B(=?) --> E(=?)

Lastly, randconfig shuffles the order of the remaining symbols,
resulting in:

    D(=y) --> A(=n) --> C(=y) --> B(=y) --> E(=y)
or
    D(=y) --> A(=n) --> C(=y) --> E(=y) --> B(=y)

When calculating the output, the linked list is traversed and the first
visible symbol with 'y' is taken. In this case, it is D if visible.

If D is hidden by 'depends on', the next node, A, is examined. Since
it is already specified as 'n', it is skipped. Next, C is checked, and
selected if it is visible.

If C is also invisible, either B or E is chosen as a result of the
randomization.

If B and E are also invisible, the linked list is traversed in the
reverse order, and the least prioritized 'n' symbol is chosen. It is
A in this case.

Now, Kconfig remembers all user values. This is a big difference from
the previous implementation, where Kconfig would forget CONFIG_C=y when
CONFIG_D=y appeared in the same input file.

The new appaorch respects user-specified values as much as possible.

Signed-off-by: Masahiro Yamada

kconfig: remember the current choice while parsing the choice block

2024-07-15T16:08:36+00:00

Instead of the boolean flag, it will be more useful to remember the
current choice being parsed.

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

kconfig: turn defaults and additional prompt for choice members into error

2024-05-09T19:34:53+00:00

menu_finalize() warns default properties for choice members and prompts
outside the choice block. These should be hard errors.

While I was here, I moved the checks to slim down menu_finalize().

Signed-off-by: Masahiro Yamada