user/sven/linux.git/scripts/kconfig/symbol.c, branch v6.7.2

kconfig: fix memory leak from range properties

2023-11-17T04:24:08Z

Currently, sym_validate_range() duplicates the range string using xstrdup(), which is overwritten by a subsequent sym_calc_value() call. It results in a memory leak. Instead, only the pointer should be copied. Below is a test case, with a summary from Valgrind. [Test Kconfig] config FOO int "foo" range 10 20 [Test .config] CONFIG_FOO=0 [Before] LEAK SUMMARY: definitely lost: 3 bytes in 1 blocks indirectly lost: 0 bytes in 0 blocks possibly lost: 0 bytes in 0 blocks still reachable: 17,465 bytes in 21 blocks suppressed: 0 bytes in 0 blocks [After] LEAK SUMMARY: definitely lost: 0 bytes in 0 blocks indirectly lost: 0 bytes in 0 blocks possibly lost: 0 bytes in 0 blocks still reachable: 17,462 bytes in 20 blocks suppressed: 0 bytes in 0 blocks Signed-off-by: Masahiro Yamada

kconfig: move sym_escape_string_value() to confdata.c

2021-10-11T14:13:23Z

Now that sym_escape_string_value() is only used in confdata.c it can be a 'static' function. Rename it escape_string_value() because it is agnostic about (struct sym *). Signed-off-by: Masahiro Yamada

kconfig: remove 'const' from the return type of sym_escape_string_value()

2021-10-01T08:28:17Z

sym_escape_string_value() returns a malloc'ed memory, but as (const char *). So, it must be casted to (void *) when it is free'd. This is odd. The return type of sym_escape_string_value() should be (char *). I exploited that free(NULL) has no effect. Signed-off-by: Masahiro Yamada

kconfig: change sym_change_count to a boolean flag

2021-04-14T06:22:49Z

sym_change_count has no good reason to be 'int' type. sym_set_change_count() compares the old and new values after casting both of them to (bool). I do not see any practical diffrence between sym_set_change_count(1) and sym_add_change_count(1). Use the boolean flag, conf_changed. Signed-off-by: Masahiro Yamada

kconfig: change defconfig_list option to environment variable

2021-04-14T06:22:48Z

"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

kconfig: clean up header inclusion

2020-12-08T14:31:29Z

- Add missing includes. - Remove no longer necessary includes. Signed-off-by: Boris Kolpackov Signed-off-by: Masahiro Yamada

kconfig: add 'static' to some file-local data

2020-08-14T04:30:04Z

Fix some warnings from sparce like follows: warning: symbol '...' was not declared. Should it be static? Signed-off-by: Masahiro Yamada

kconfig: do not use OR-assignment for zero-cleared structure

2020-05-12T04:28:30Z

The simple assignment is enough because memset() three lines above has zero-cleared the structure. Signed-off-by: Masahiro Yamada

kconfig: make 'imply' obey the direct dependency

2020-03-13T01:05:34Z

The 'imply' statement may create unmet direct dependency when the implied symbol depends on m. [Test Code] config FOO tristate "foo" imply BAZ config BAZ tristate "baz" depends on BAR config BAR def_tristate m config MODULES def_bool y option modules If you set FOO=y, BAZ is also promoted to y, which results in the following .config file: CONFIG_FOO=y CONFIG_BAZ=y CONFIG_BAR=m CONFIG_MODULES=y This does not meet the dependency 'BAZ depends on BAR'. Unlike 'select', what is worse, Kconfig never shows the 'WARNING: unmet direct dependencies detected for ...' for this case. Because 'imply' is considered to be weaker than 'depends on', Kconfig should take the direct dependency into account. For clarification, describe this case in kconfig-language.rst too. Signed-off-by: Masahiro Yamada Acked-by: Nicolas Pitre Tested-by: Geert Uytterhoeven

kconfig: allow symbols implied by y to become m

2020-03-13T01:05:34Z

The 'imply' keyword restricts a symbol to y or n, excluding m when it is implied by y. This is the original behavior since commit 237e3ad0f195 ("Kconfig: Introduce the "imply" keyword"). However, the author of this feature, Nicolas Pitre, stated that the 'imply' keyword should not impose any restrictions. (https://lkml.org/lkml/2020/2/19/714) I agree, and want to get rid of this tricky behavior. Suggested-by: Nicolas Pitre Signed-off-by: Masahiro Yamada Acked-by: Nicolas Pitre