Re: Hit ASSERT in credit2 code with NR_CPUS=1 build

[Jan Beulich <jbeulich@xxxxxxxx>]

On 10.03.2021 12:24, Jan Beulich wrote:
> On 10.03.2021 12:13, Dario Faggioli wrote:
>> So, in my mind, now `mask` is empty. Therefore, I'm currently clueless
>> about why we enter this loop...
>>
>>>     for_each_cpu(i, &mask)
>>>     {
>>>         s_time_t score;
>>>
>>>         /* Already looked at this one above */
>>>         ASSERT(i != cpu); <====
>>>
>> ... and we reach this point.
> 
> from xen/cpumask.h:
> 
> #define for_each_cpu(cpu, mask)                       \
>       for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)(mask))
> 
> I'm struggling though why this is this way.

Quoting Linux 5.11 (where, long ago, our code came from):

#define for_each_cpu(cpu, mask)                 \
        for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask)
#define for_each_cpu_not(cpu, mask)             \
        for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask)
#define for_each_cpu_wrap(cpu, mask, start)     \
        for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask, (void)(start))
#define for_each_cpu_and(cpu, mask1, mask2)     \
        for ((cpu) = 0; (cpu) < 1; (cpu)++, (void)mask1, (void)mask2)

where I find particularly odd that for_each_cpu() and
for_each_cpu_not() have the same effect when really they should act
on disjoint sets of CPUs.

I can't find anything under Documentation/ there, so my best guess
is that this is either a bug we share, or there was some historical
reason for the behavior which wasn't written down anywhere.

Jan