summaryrefslogtreecommitdiff
path: root/scripts/basic
diff options
context:
space:
mode:
authorSimon Glass <sjg@chromium.org>2026-07-14 07:35:42 -0600
committerNicolas Schier <nsc@kernel.org>2026-08-05 14:46:48 +0200
commitf915149f5cfbd0d4406ec0b0f57b1d2c8685ae55 (patch)
tree8a7b82ab681f080f8c025a5ab1e52fba07d65c60 /scripts/basic
parent2ca47eed701b41c2962429c4dfe2134c49f7a1b3 (diff)
downloadlinux-next-f915149f5cfbd0d4406ec0b0f57b1d2c8685ae55.tar.gz
linux-next-f915149f5cfbd0d4406ec0b0f57b1d2c8685ae55.zip
kconfig: abort rather than loop for ever on EOF
When a non-interactive 'make oldconfig' or 'syncconfig' meets a new int or hex symbol whose default cannot be applied, conf_string() reads a value from stdin. At end of file fgets() returns NULL, no value is set and the loop asks again. The result is an endless loop which fills the output until it exhausts memory, rather than a clean failure. Detect this in conf_string(): if the value cannot be set and stdin is at end of file, stop with an error that names the symbol. Note that a symbol with no default doesn't trigger this, since sym_calc_value() falls back to 0, which is accepted at end of file. The loop is triggered by a broken Kconfig file, with a default whose text fails sym_string_valid(). Such mistakes do creep in from time to time and are hard to debug, since the build fills the log with repeated prompts instead of pointing at the offending symbol. Some bad defaults draw a parse-time warning, but menu_validate_number() accepts a reference to any int or hex symbol, so a cross-type reference loops with no warning at all. For example, "0xff" is not a valid int value: config HEXSYM hex default 0xff config VAL int "Value" default HEXSYM Interactive use is unaffected, since feof() only becomes true once a read actually hits end of file: an invalid answer at a terminal still re-prompts, while Ctrl-D at such a prompt exits with the error instead of looping. bool and tristate symbols and choices already accept the default on an empty line, so they still take their defaults in a non-interactive build. Tested with int and hex symbols carrying such defaults: with empty stdin, the code without this change produces around 190MB of repeated prompts within two seconds, while with the change it exits 1 naming the symbol. Piped and interactive (pty) sessions still re-prompt on an invalid answer and then accept a valid one. A new string symbol with no default still takes the empty string at end of file, since any text is valid for a string. Signed-off-by: Simon Glass <sjg@chromium.org> Link: https://patch.msgid.link/20260714133545.3294648-1-sjg@chromium.org Signed-off-by: Nicolas Schier <nsc@kernel.org>
Diffstat (limited to 'scripts/basic')
0 files changed, 0 insertions, 0 deletions