On 22/02/2023 4:17 pm, Jan Beulich wrote:
> 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.
I'd clearly missed that thread, but the final part seems to have agreed
on a NR_CPUS check, with you saying that you'd send a v2 "in a minute".
~Andrew
