Return from cpu_schedule_up when either cpu is 0 or
NR_CPUS == 1. This fixes the following:
core.c: In function 'cpu_schedule_up':
core.c:2769:19: error: array subscript 1 is above array bounds
of 'struct vcpu *[1]' [-Werror=array-bounds]
2769 | if ( idle_vcpu[cpu] == NULL )
|
Signed-off-by: Connor Davis <connojdavis@gmail.com>
---
xen/common/sched/core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
index 9745a77eee..f5ec65bf9b 100644
--- a/xen/common/sched/core.c
+++ b/xen/common/sched/core.c
@@ -2763,7 +2763,7 @@ static int cpu_schedule_up(unsigned int cpu)
cpumask_set_cpu(cpu, &sched_res_mask);
/* Boot CPU is dealt with later in scheduler_init(). */
- if ( cpu == 0 )
+ if ( cpu == 0 || NR_CPUS == 1 )
return 0;
if ( idle_vcpu[cpu] == NULL )
--
2.27.0
On 2/25/21 7:24 AM, Connor Davis wrote: > Return from cpu_schedule_up when either cpu is 0 or > NR_CPUS == 1. This fixes the following: > > core.c: In function 'cpu_schedule_up': > core.c:2769:19: error: array subscript 1 is above array bounds > of 'struct vcpu *[1]' [-Werror=array-bounds] > 2769 | if ( idle_vcpu[cpu] == NULL ) > | > > Signed-off-by: Connor Davis <connojdavis@gmail.com> > --- > xen/common/sched/core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c > index 9745a77eee..f5ec65bf9b 100644 > --- a/xen/common/sched/core.c > +++ b/xen/common/sched/core.c > @@ -2763,7 +2763,7 @@ static int cpu_schedule_up(unsigned int cpu) > cpumask_set_cpu(cpu, &sched_res_mask); > > /* Boot CPU is dealt with later in scheduler_init(). */ > - if ( cpu == 0 ) > + if ( cpu == 0 || NR_CPUS == 1 ) > return 0; > > if ( idle_vcpu[cpu] == NULL ) > Interesting. I wonder when this changed in GCC. I haven't yet seen this issue compiling with: NR_CPUS=1 ARCH=riscv64 riscv64-unknown-linux-gnu-gcc (GCC) 10.1.0 Which version of GCC are you seeing emit this? - Bob
On Thu, Feb 25, 2021 at 02:55:45PM -0800, Bob Eshleman wrote:
> On 2/25/21 7:24 AM, Connor Davis wrote:
> > Return from cpu_schedule_up when either cpu is 0 or
> > NR_CPUS == 1. This fixes the following:
> >
> > core.c: In function 'cpu_schedule_up':
> > core.c:2769:19: error: array subscript 1 is above array bounds
> > of 'struct vcpu *[1]' [-Werror=array-bounds]
> > 2769 | if ( idle_vcpu[cpu] == NULL )
> > |
> >
> > Signed-off-by: Connor Davis <connojdavis@gmail.com>
> > ---
> > xen/common/sched/core.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
> > index 9745a77eee..f5ec65bf9b 100644
> > --- a/xen/common/sched/core.c
> > +++ b/xen/common/sched/core.c
> > @@ -2763,7 +2763,7 @@ static int cpu_schedule_up(unsigned int cpu)
> > cpumask_set_cpu(cpu, &sched_res_mask);
> >
> > /* Boot CPU is dealt with later in scheduler_init(). */
> > - if ( cpu == 0 )
> > + if ( cpu == 0 || NR_CPUS == 1 )
> > return 0;
> >
> > if ( idle_vcpu[cpu] == NULL )
> >
>
> Interesting. I wonder when this changed in GCC.
>
> I haven't yet seen this issue compiling with:
> NR_CPUS=1
> ARCH=riscv64
> riscv64-unknown-linux-gnu-gcc (GCC) 10.1.0
>
> Which version of GCC are you seeing emit this?
The one from cloned from github.com/riscv/riscv-gnu-toolchain
in the docker container uses 10.2.0
Connor
On 2/25/21 7:01 PM, Connor Davis wrote: > On Thu, Feb 25, 2021 at 02:55:45PM -0800, Bob Eshleman wrote: >> riscv64-unknown-linux-gnu-gcc (GCC) 10.1.0 >> >> Which version of GCC are you seeing emit this? > > The one from cloned from github.com/riscv/riscv-gnu-toolchain > in the docker container uses 10.2.0 > > Connor > The commit I pinned in the container is actually for GDB only, since more recent versions broke when used with QEMU at the time of writing the dockerfile (this last June). Since I built the container some months ago and no commit pinning for the compiler, it still contains 10.1.0 for me. It _shouldn't_ be necessary... but since there is a lot of dev done on riscv-gcc, it might be worth talking about pinning the compiler version in the container. -Bob
On 25.02.2021 16:24, Connor Davis wrote: > Return from cpu_schedule_up when either cpu is 0 or > NR_CPUS == 1. This fixes the following: > > core.c: In function 'cpu_schedule_up': > core.c:2769:19: error: array subscript 1 is above array bounds > of 'struct vcpu *[1]' [-Werror=array-bounds] > 2769 | if ( idle_vcpu[cpu] == NULL ) > | > > Signed-off-by: Connor Davis <connojdavis@gmail.com> > --- > xen/common/sched/core.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c > index 9745a77eee..f5ec65bf9b 100644 > --- a/xen/common/sched/core.c > +++ b/xen/common/sched/core.c > @@ -2763,7 +2763,7 @@ static int cpu_schedule_up(unsigned int cpu) > cpumask_set_cpu(cpu, &sched_res_mask); > > /* Boot CPU is dealt with later in scheduler_init(). */ > - if ( cpu == 0 ) > + if ( cpu == 0 || NR_CPUS == 1 ) > return 0; > > if ( idle_vcpu[cpu] == NULL ) I'm not convinced a compiler warning is due here, and in turn I'm not sure we want/need to work around this the way you do. First question is whether that's just a specific compiler version that's flawed. If it's not just a special case (e.g. some unreleased version) we may want to think of possible alternatives - the addition looks really odd to me. Jan
On Thu, Feb 25, 2021 at 04:50:02PM +0100, Jan Beulich wrote:
> On 25.02.2021 16:24, Connor Davis wrote:
> > Return from cpu_schedule_up when either cpu is 0 or
> > NR_CPUS == 1. This fixes the following:
> >
> > core.c: In function 'cpu_schedule_up':
> > core.c:2769:19: error: array subscript 1 is above array bounds
> > of 'struct vcpu *[1]' [-Werror=array-bounds]
> > 2769 | if ( idle_vcpu[cpu] == NULL )
> > |
> >
> > Signed-off-by: Connor Davis <connojdavis@gmail.com>
> > ---
> > xen/common/sched/core.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
> > index 9745a77eee..f5ec65bf9b 100644
> > --- a/xen/common/sched/core.c
> > +++ b/xen/common/sched/core.c
> > @@ -2763,7 +2763,7 @@ static int cpu_schedule_up(unsigned int cpu)
> > cpumask_set_cpu(cpu, &sched_res_mask);
> >
> > /* Boot CPU is dealt with later in scheduler_init(). */
> > - if ( cpu == 0 )
> > + if ( cpu == 0 || NR_CPUS == 1 )
> > return 0;
> >
> > if ( idle_vcpu[cpu] == NULL )
>
> I'm not convinced a compiler warning is due here, and in turn
> I'm not sure we want/need to work around this the way you do.
It seems like a reasonable warning to me, but of course I'm open
to dealing with it in a different way.
> First question is whether that's just a specific compiler
> version that's flawed. If it's not just a special case (e.g.
The docker container uses gcc 10.2.0 from
https://github.com/riscv/riscv-gnu-toolchain
> some unreleased version) we may want to think of possible
> alternatives - the addition looks really odd to me.
>
> Jan
Connor
On 26.02.2021 04:08, Connor Davis wrote:
> On Thu, Feb 25, 2021 at 04:50:02PM +0100, Jan Beulich wrote:
>> On 25.02.2021 16:24, Connor Davis wrote:
>>> Return from cpu_schedule_up when either cpu is 0 or
>>> NR_CPUS == 1. This fixes the following:
>>>
>>> core.c: In function 'cpu_schedule_up':
>>> core.c:2769:19: error: array subscript 1 is above array bounds
>>> of 'struct vcpu *[1]' [-Werror=array-bounds]
>>> 2769 | if ( idle_vcpu[cpu] == NULL )
>>> |
>>>
>>> Signed-off-by: Connor Davis <connojdavis@gmail.com>
>>> ---
>>> xen/common/sched/core.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/xen/common/sched/core.c b/xen/common/sched/core.c
>>> index 9745a77eee..f5ec65bf9b 100644
>>> --- a/xen/common/sched/core.c
>>> +++ b/xen/common/sched/core.c
>>> @@ -2763,7 +2763,7 @@ static int cpu_schedule_up(unsigned int cpu)
>>> cpumask_set_cpu(cpu, &sched_res_mask);
>>>
>>> /* Boot CPU is dealt with later in scheduler_init(). */
>>> - if ( cpu == 0 )
>>> + if ( cpu == 0 || NR_CPUS == 1 )
>>> return 0;
>>>
>>> if ( idle_vcpu[cpu] == NULL )
>>
>> I'm not convinced a compiler warning is due here, and in turn
>> I'm not sure we want/need to work around this the way you do.
>
> It seems like a reasonable warning to me, but of course I'm open
> to dealing with it in a different way.
>
>> First question is whether that's just a specific compiler
>> version that's flawed. If it's not just a special case (e.g.
>
> The docker container uses gcc 10.2.0 from
> https://github.com/riscv/riscv-gnu-toolchain
Ah yes, at -O2 I can observe the warning on e.g.
extern int array[N];
int test(unsigned i) {
if(i == N - 1)
return 0;
return array[i];
}
when N=1. No warning appears when N=2 or higher, yet if it is
sensible to emit for N=1 then it would imo be similarly
sensible to emit in other cases. The only difference is that
when N=1, there's no i for which the array access would ever
be valid, while e.g. for N=2 there's exactly one such i.
I've tried an x86 build with NR_CPUS=1, and this hits the case
you found and a 2nd one, where behavior is even more puzzling.
For the case you've found I'd like to suggest as alternative
@@ -2769,6 +2769,12 @@ static int cpu_schedule_up(unsigned int
if ( cpu == 0 )
return 0;
+ /*
+ * Guard in particular also against the compiler suspecting out-of-bounds
+ * array accesses below when NR_CPUS=1.
+ */
+ BUG_ON(cpu >= NR_CPUS);
+
if ( idle_vcpu[cpu] == NULL )
vcpu_create(idle_vcpu[0]->domain, cpu);
else
To fix the x86 build in this regard we'd additionally need
something along the lines of
--- unstable.orig/xen/arch/x86/genapic/x2apic.c
+++ unstable/xen/arch/x86/genapic/x2apic.c
@@ -54,7 +54,17 @@ static void init_apic_ldr_x2apic_cluster
per_cpu(cluster_cpus, this_cpu) = cluster_cpus_spare;
for_each_online_cpu ( cpu )
{
- if (this_cpu == cpu || x2apic_cluster(this_cpu) != x2apic_cluster(cpu))
+ if ( this_cpu == cpu )
+ continue;
+ /*
+ * Guard in particular against the compiler suspecting out-of-bounds
+ * array accesses below when NR_CPUS=1 (oddly enough with gcc 10 it
+ * is the 1st of these alone which actually helps, not the 2nd, nor
+ * are both required together there).
+ */
+ BUG_ON(this_cpu >= NR_CPUS);
+ BUG_ON(cpu >= NR_CPUS);
+ if ( x2apic_cluster(this_cpu) != x2apic_cluster(cpu) )
continue;
per_cpu(cluster_cpus, this_cpu) = per_cpu(cluster_cpus, cpu);
break;
but the comment points out how strangely the compiler behaves here.
Even flipping around the two sides of the != doesn't change its
behavior. It is perhaps relevant to note here that there's no
special casing of smp_processor_id() in the NR_CPUS=1 case, so the
compiler can't infer this_cpu == 0.
Once we've settled on how to change common/sched/core.c I guess
I'll then adjust the x86-specific change accordingly and submit as
a separate fix (or I could of course also bundle both changes then).
Jan
On Fri, 2021-02-26 at 09:31 +0100, Jan Beulich wrote: > On 26.02.2021 04:08, Connor Davis wrote: > > On Thu, Feb 25, 2021 at 04:50:02PM +0100, Jan Beulich wrote: > > > On 25.02.2021 16:24, Connor Davis wrote: > > > > index 9745a77eee..f5ec65bf9b 100644 > > > > --- a/xen/common/sched/core.c > > > > +++ b/xen/common/sched/core.c > > > > @@ -2763,7 +2763,7 @@ static int cpu_schedule_up(unsigned int > > > > cpu) > > > > cpumask_set_cpu(cpu, &sched_res_mask); > > > > > > > > /* Boot CPU is dealt with later in scheduler_init(). */ > > > > - if ( cpu == 0 ) > > > > + if ( cpu == 0 || NR_CPUS == 1 ) > > > > return 0; > > > > > > > > if ( idle_vcpu[cpu] == NULL ) > > @@ -2769,6 +2769,12 @@ static int cpu_schedule_up(unsigned int > if ( cpu == 0 ) > return 0; > > + /* > + * Guard in particular also against the compiler suspecting out- > of-bounds > + * array accesses below when NR_CPUS=1. > + */ > + BUG_ON(cpu >= NR_CPUS); > + > I would be fine with this. Actually, I do prefer it too, over the "is index 0 or is the array length 1" check, which I also find confusing. Regards -- Dario Faggioli, Ph.D http://about.me/dario.faggioli Virtualization Software Engineer SUSE Labs, SUSE https://www.suse.com/ ------------------------------------------------------------------- <<This happens because _I_ choose it to happen!>> (Raistlin Majere)
On Fri, Feb 26, 2021 at 09:31:02AM +0100, Jan Beulich wrote:
> On 26.02.2021 04:08, Connor Davis wrote:
> > On Thu, Feb 25, 2021 at 04:50:02PM +0100, Jan Beulich wrote:
> >> On 25.02.2021 16:24, Connor Davis wrote:
> >>> Return from cpu_schedule_up when either cpu is 0 or
> >>> NR_CPUS == 1. This fixes the following:
> >>>
> >>> core.c: In function 'cpu_schedule_up':
> >>> core.c:2769:19: error: array subscript 1 is above array bounds
> >>> of 'struct vcpu *[1]' [-Werror=array-bounds]
> >>> 2769 | if ( idle_vcpu[cpu] == NULL )
> >>> |
> >>>
>
> Ah yes, at -O2 I can observe the warning on e.g.
>
> extern int array[N];
>
> int test(unsigned i) {
> if(i == N - 1)
> return 0;
> return array[i];
> }
>
> when N=1. No warning appears when N=2 or higher, yet if it is
> sensible to emit for N=1 then it would imo be similarly
> sensible to emit in other cases. The only difference is that
> when N=1, there's no i for which the array access would ever
> be valid, while e.g. for N=2 there's exactly one such i.
>
> I've tried an x86 build with NR_CPUS=1, and this hits the case
> you found and a 2nd one, where behavior is even more puzzling.
> For the case you've found I'd like to suggest as alternative
>
> @@ -2769,6 +2769,12 @@ static int cpu_schedule_up(unsigned int
> if ( cpu == 0 )
> return 0;
>
> + /*
> + * Guard in particular also against the compiler suspecting out-of-bounds
> + * array accesses below when NR_CPUS=1.
> + */
> + BUG_ON(cpu >= NR_CPUS);
> +
Yeah I like this better than my approach.
> if ( idle_vcpu[cpu] == NULL )
> vcpu_create(idle_vcpu[0]->domain, cpu);
> else
>
> To fix the x86 build in this regard we'd additionally need
> something along the lines of
>
> --- unstable.orig/xen/arch/x86/genapic/x2apic.c
> +++ unstable/xen/arch/x86/genapic/x2apic.c
> @@ -54,7 +54,17 @@ static void init_apic_ldr_x2apic_cluster
> per_cpu(cluster_cpus, this_cpu) = cluster_cpus_spare;
> for_each_online_cpu ( cpu )
> {
> - if (this_cpu == cpu || x2apic_cluster(this_cpu) != x2apic_cluster(cpu))
> + if ( this_cpu == cpu )
> + continue;
> + /*
> + * Guard in particular against the compiler suspecting out-of-bounds
> + * array accesses below when NR_CPUS=1 (oddly enough with gcc 10 it
> + * is the 1st of these alone which actually helps, not the 2nd, nor
> + * are both required together there).
> + */
> + BUG_ON(this_cpu >= NR_CPUS);
> + BUG_ON(cpu >= NR_CPUS);
> + if ( x2apic_cluster(this_cpu) != x2apic_cluster(cpu) )
> continue;
> per_cpu(cluster_cpus, this_cpu) = per_cpu(cluster_cpus, cpu);
> break;
>
> but the comment points out how strangely the compiler behaves here.
> Even flipping around the two sides of the != doesn't change its
> behavior. It is perhaps relevant to note here that there's no
> special casing of smp_processor_id() in the NR_CPUS=1 case, so the
> compiler can't infer this_cpu == 0.
>
> Once we've settled on how to change common/sched/core.c I guess
> I'll then adjust the x86-specific change accordingly and submit as
> a separate fix (or I could of course also bundle both changes then).
Feel free to bundle both.
Connor
© 2016 - 2026 Red Hat, Inc.