Re: Revert NR_CPUS=1 fix from 4.15 (was: Re: [PATCH] fix for_each_cpu() again for NR_CPUS=1)

[Roger Pau Monné <roger.pau@xxxxxxxxxx>]

On Thu, Apr 01, 2021 at 11:26:03AM +0200, Jan Beulich wrote:
> On 01.04.2021 11:00, Roger Pau Monné wrote:
> > On Wed, Mar 31, 2021 at 04:52:47PM +0200, Jan Beulich wrote:
> >> Unfortunately aa50f45332f1 ("xen: fix for_each_cpu when NR_CPUS=1") has
> >> caused quite a bit of fallout with gcc10, e.g. (there are at least two
> >> more similar ones, and I didn't bother trying to find them all):
> >>
> >> In file included from .../xen/include/xen/config.h:13,
> >>                  from <command-line>:
> >> core_parking.c: In function ‘core_parking_power’:
> >> .../xen/include/asm/percpu.h:12:51: error: array subscript 1 is above 
> >> array bounds of ‘long unsigned int[1]’ [-Werror=array-bounds]
> >>    12 |     (*RELOC_HIDE(&per_cpu__##var, __per_cpu_offset[cpu]))
> >> .../xen/include/xen/compiler.h:141:29: note: in definition of macro 
> >> ‘RELOC_HIDE’
> >>   141 |     (typeof(ptr)) (__ptr + (off)); })
> >>       |                             ^~~
> >> core_parking.c:133:39: note: in expansion of macro ‘per_cpu’
> >>   133 |             core_tmp = cpumask_weight(per_cpu(cpu_core_mask, cpu));
> >>       |                                       ^~~~~~~
> >> In file included from .../xen/include/xen/percpu.h:4,
> >>                  from .../xen/include/asm/msr.h:7,
> >>                  from .../xen/include/asm/time.h:5,
> >>                  from .../xen/include/xen/time.h:76,
> >>                  from .../xen/include/xen/spinlock.h:4,
> >>                  from .../xen/include/xen/cpu.h:5,
> >>                  from core_parking.c:19:
> >> .../xen/include/asm/percpu.h:6:22: note: while referencing 
> >> ‘__per_cpu_offset’
> >>     6 | extern unsigned long __per_cpu_offset[NR_CPUS];
> >>       |                      ^~~~~~~~~~~~~~~~
> > 
> > At this point, should be consider reverting the original fix from the
> > 4.15 branch, so that we don't release something that's build broken
> > with gcc 10?
> 
> Well, I didn't propose reverting (or taking this fix) because I think
> build breakage is better than runtime breakage. But in the end, Ian,
> it's up to you.

Oh, right, sorry. The build issue only happens with NR_CPUS=1, in
which case I agree, there's no need to do anything in 4.15 IMO.

Sorry for bothering.

Roger.