diff options
| author | Leo Yu-Chi Liang <leo.liang@sifive.com> | 2026-10-06 21:52:29 -0700 |
|---|---|---|
| committer | Paul Walmsley <pjw@kernel.org> | 2026-10-07 09:08:03 -0600 |
| commit | 07e23d0b6f58eec351e52058b9a0a8af7b019c09 (patch) | |
| tree | eff12514f2d544199cb4e4f0a8c9e1e181d0152c /tools/lib/python/kdoc/python_version.py | |
| parent | 298510bbc7c3017c0faf481c6ea66f1065b657b4 (diff) | |
| download | linux-next-07e23d0b6f58eec351e52058b9a0a8af7b019c09.tar.gz linux-next-07e23d0b6f58eec351e52058b9a0a8af7b019c09.zip | |
riscv: fix NR_CPUS range leaking 64-bit default onto 32-bit builds
rv32_defconfig is built in two stages:
- the generic (64-bit-oriented) "defconfig" target runs first
and resolves a concrete NR_CPUS value using the 64BIT default.
- then 32-bit.config is merged on top via merge_config.sh,
which does not touch NR_CPUS.
The final "make olddefconfig" pass sees NR_CPUS=256 is still within
the "2 512" range therefore never recalculates it against the 32BIT
default of 32, silently keeping the leaked 64-bit-stage value.
The NR_CPUS-scaled regions (percpu areas, ...etc) of the resulting
CONFIG_NR_CPUS=256 on a 32-bit build bloats and does not fit in the
percpu/stack layout for rv32 and hangs early boot on QEMU's virt machine.
Fix this by explicitly specify the range for 32/64 and SBI_V01/!SBI_V01.
Fixes: 0fa749771993 ("riscv: Raise default NR_CPUS for 64BIT to 256")
Signed-off-by: Leo Yu-Chi Liang <leo.liang@sifive.com>
Link: https://patch.msgid.link/20261007045229.36114-1-leo.liang@sifive.com
Signed-off-by: Paul Walmsley <pjw@kernel.org>
Diffstat (limited to 'tools/lib/python/kdoc/python_version.py')
0 files changed, 0 insertions, 0 deletions