user/sven/linux.git/scripts/kconfig, branch v4.14.242

kconfig: nconf: stop endless search loops

2021-05-22T08:57:37Z

[ Upstream commit 8c94b430b9f6213dec84e309bb480a71778c4213 ] If the user selects the very first entry in a page and performs a search-up operation, or selects the very last entry in a page and performs a search-down operation that will not succeed (e.g., via [/]asdfzzz[Up Arrow]), nconf will never terminate searching the page. The reason is that in this case, the starting point will be set to -1 or n, which is then translated into (n - 1) (i.e., the last entry of the page) or 0 (i.e., the first entry of the page) and finally the search begins. This continues to work fine until the index reaches 0 or (n - 1), at which point it will be decremented to -1 or incremented to n, but not checked against the starting point right away. Instead, it's wrapped around to the bottom or top again, after which the starting point check occurs... and naturally fails. My original implementation added another check for -1 before wrapping the running index variable around, but Masahiro Yamada pointed out that the actual issue is that the comparison point (starting point) exceeds bounds (i.e., the [0,n-1] interval) in the first place and that, instead, the starting point should be fixed. This has the welcome side-effect of also fixing the case where the starting point was n while searching down, which also lead to an infinite loop. OTOH, this code is now essentially all his work. Amazingly, nobody seems to have been hit by this for 11 years - or at the very least nobody bothered to debug and fix this. Signed-off-by: Mihai Moldovan Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

kconfig: fix broken dependency in randconfig-generated .config

2020-02-28T15:35:59Z

[ Upstream commit c8fb7d7e48d11520ad24808cfce7afb7b9c9f798 ] Running randconfig on arm64 using KCONFIG_SEED=0x40C5E904 (e.g. on v5.5) produces the .config with CONFIG_EFI=y and CONFIG_CPU_BIG_ENDIAN=y, which does not meet the !CONFIG_CPU_BIG_ENDIAN dependency. This is because the user choice for CONFIG_CPU_LITTLE_ENDIAN vs CONFIG_CPU_BIG_ENDIAN is set by randomize_choice_values() after the value of CONFIG_EFI is calculated. When this happens, the has_changed flag should be set. Currently, it takes the result from the last iteration. It should accumulate all the results of the loop. Fixes: 3b9a19e08960 ("kconfig: loop as long as we changed some symbols in randconfig") Reported-by: Vincenzo Frascino Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

kconfig: don't crash on NULL expressions in expr_eq()

2020-01-12T11:11:58Z

[ Upstream commit 272a72103012862e3a24ea06635253ead0b6e808 ] NULL expressions are taken to always be true, as implemented by the expr_is_yes() macro and by several other functions in expr.c. As such, they ought to be valid inputs to expr_eq(), which compares two expressions. Signed-off-by: Thomas Hebb Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

kconfig/[mn]conf: handle backspace (^H) key

2019-05-04T07:15:22Z

[ Upstream commit 9c38f1f044080392603c497ecca4d7d09876ff99 ] Backspace is not working on some terminal emulators which do not send the key code defined by terminfo. Terminals either send '^H' (8) or '^?' (127). But currently only '^?' is handled. Let's also handle '^H' for those terminals. Signed-off-by: Changbin Du Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin (Microsoft)

kconfig: fix memory leak when EOF is encountered in quotation

2019-01-26T08:37:04Z

[ Upstream commit fbac5977d81cb2b2b7e37b11c459055d9585273c ] An unterminated string literal followed by new line is passed to the parser (with "multi-line strings not supported" warning shown), then handled properly there. On the other hand, an unterminated string literal at end of file is never passed to the parser, then results in memory leak. [Test Code] ----------(Kconfig begin)---------- source "Kconfig.inc" config A bool "a" -----------(Kconfig end)----------- --------(Kconfig.inc begin)-------- config B bool "b\No new line at end of file ---------(Kconfig.inc end)--------- [Summary from Valgrind] Before the fix: LEAK SUMMARY: definitely lost: 16 bytes in 1 blocks ... After the fix: LEAK SUMMARY: definitely lost: 0 bytes in 0 blocks ... Eliminate the memory leak path by handling this case. Of course, such a Kconfig file is wrong already, so I will add an error message later. Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

kconfig: fix file name and line number of warn_ignored_character()

2019-01-26T08:37:04Z

[ Upstream commit 77c1c0fa8b1477c5799bdad65026ea5ff676da44 ] Currently, warn_ignore_character() displays invalid file name and line number. The lexer should use current_file->name and yylineno, while the parser should use zconf_curname() and zconf_lineno(). This difference comes from that the lexer is always going ahead of the parser. The parser needs to look ahead one token to make a shift/reduce decision, so the lexer is requested to scan more text from the input file. This commit fixes the warning message from warn_ignored_character(). [Test Code] ----(Kconfig begin)---- / -----(Kconfig end)----- [Output] Before the fix: :0:warning: ignoring unsupported character '/' After the fix: Kconfig:1:warning: ignoring unsupported character '/' Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

kconfig: fix the rule of mainmenu_stmt symbol

2018-11-04T13:52:45Z

[ Upstream commit 56869d45e364244a721de34ce9c5dc9ed022779e ] The rule of mainmenu_stmt does not have debug print of zconf_lineno(), but if it had, it would print a wrong line number for the same reason as commit b2d00d7c61c8 ("kconfig: fix line numbers for if-entries in menu tree"). The mainmenu_stmt does not need to eat following empty lines because they are reduced to common_stmt. Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

kconfig: fix line numbers for if-entries in menu tree

2018-08-24T11:09:06Z

[ Upstream commit b2d00d7c61c84edd150310af3f556f8a3c6e2e67 ] The line numers for if-entries in the menu tree are off by one or more lines which is confusing when debugging for correctness of unrelated changes. According to the git log, commit a02f0570ae201c49 (kconfig: improve error handling in the parser) was the last one that changed that part of the parser and replaced "if_entry: T_IF expr T_EOL" by "if_entry: T_IF expr nl" but the commit message does not state why this has been done. When reverting that part of the commit, only the line numers are corrected (checked with cdebug = DEBUG_PARSE in zconf.y), otherwise the menu tree remains unchanged (checked with zconfdump() enabled in conf.c). An example for the corrected line numbers: drivers/soc/Kconfig:15:source drivers/soc/tegra/Kconfig drivers/soc/tegra/Kconfig:4:if drivers/soc/tegra/Kconfig:6:if changes to: drivers/soc/Kconfig:15:source drivers/soc/tegra/Kconfig drivers/soc/tegra/Kconfig:1:if drivers/soc/tegra/Kconfig:4:if Signed-off-by: Dirk Gouders Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

kconfig: Avoid format overflow warning from GCC 8.1

2018-06-11T20:49:18Z

commit 2ae89c7a82ea9d81a19b4fc2df23bef4b112f24e upstream. In file included from scripts/kconfig/zconf.tab.c:2485: scripts/kconfig/confdata.c: In function ‘conf_write’: scripts/kconfig/confdata.c:773:22: warning: ‘%s’ directive writing likely 7 or more bytes into a region of size between 1 and 4097 [-Wformat-overflow=] sprintf(newname, "%s%s", dirname, basename); ^~ scripts/kconfig/confdata.c:773:19: note: assuming directive output of 7 bytes sprintf(newname, "%s%s", dirname, basename); ^~~~~~ scripts/kconfig/confdata.c:773:2: note: ‘sprintf’ output 1 or more bytes (assuming 4104) into a destination of size 4097 sprintf(newname, "%s%s", dirname, basename); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ scripts/kconfig/confdata.c:776:23: warning: ‘.tmpconfig.’ directive writing 11 bytes into a region of size between 1 and 4097 [-Wformat-overflow=] sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid()); ^~~~~~~~~~~ scripts/kconfig/confdata.c:776:3: note: ‘sprintf’ output between 13 and 4119 bytes into a destination of size 4097 sprintf(tmpname, "%s.tmpconfig.%d", dirname, (int)getpid()); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Increase the size of tmpname and newname to make GCC happy. Signed-off-by: Nathan Chancellor Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman

kconfig: Fix expr_free() E_NOT leak

2018-04-26T09:02:08Z

[ Upstream commit 5b1374b3b3c2fc4f63a398adfa446fb8eff791a4 ] Only the E_NOT operand and not the E_NOT node itself was freed, due to accidentally returning too early in expr_free(). Outline of leak: switch (e->type) { ... case E_NOT: expr_free(e->left.expr); return; ... } *Never reached, 'e' leaked* free(e); Fix by changing the 'return' to a 'break'. Summary from Valgrind on 'menuconfig' (ARCH=x86) before the fix: LEAK SUMMARY: definitely lost: 44,448 bytes in 1,852 blocks ... Summary after the fix: LEAK SUMMARY: definitely lost: 1,608 bytes in 67 blocks ... Signed-off-by: Ulf Magnusson Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman