On 22.02.2023 17:04, Andrew Cooper wrote:
> While testing the rebuilt debian unstable container, I found:
>
> common/core_parking.c: In function 'core_parking_remove':
> common/core_parking.c:230:53: error: array subscript 1 is above array
> bounds of 'unsigned int[1]' [-Werror=array-bounds]
> 230 | core_parking_cpunum[i] = core_parking_cpunum[i + 1];
> | ~~~~~~~~~~~~~~~~~~~^~~~~~~
> common/core_parking.c:31:21: note: while referencing 'core_parking_cpunum'
> 31 | static unsigned int core_parking_cpunum[NR_CPUS] = {[0 ...
> NR_CPUS-1] = -1};
> | ^~~~~~~~~~~~~~~~~~~
>
>
> which is an legitimate complaint - this logic is simply broken with
> NR_CPUS=1.
>
> In principle, I think the best fix is probably to have CORE_PARKING
> depend on NR_CPUS > 1, except none of the interacting x86 code has been
> written in a way that would be compatible.
>
> But it also occurs to me that this is the kind of thing an embedded x86
> usecase would want to compile. Frankly, its niche even on regular x86
> use-cases.
>
> Except having looked at the code, it's a different to the other thing we
> call core parking which is the smt=0 logic to keep the stacks valid for
> cores/threads we don't want to use, because of #MC broadcast problems -
> and this logic does need to stay.
>
> Thoughts?
See "core-parking: fix build with gcc12 and NR_CPUS=1" sent back in September
last year.
Jan
