On 22.02.2023 17:20, Andrew Cooper wrote:
> 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".
And so I did:
https://lists.xen.org/archives/html/xen-devel/2022-09/msg00906.html
Jan
