From: Connor Davis <connojdavis@gmail.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Bobby Eshleman <bobbyeshleman@gmail.com>,
George Dunlap <george.dunlap@citrix.com>,
Dario Faggioli <dfaggioli@suse.com>,
xen-devel@lists.xenproject.org
Subject: Re: [PATCH for-next 3/6] xen/sched: Fix build when NR_CPUS == 1
Date: Fri, 26 Feb 2021 21:17:47 -0700 [thread overview]
Message-ID: <20210227041747.p6kfrtvmkk5sbwof@thewall> (raw)
In-Reply-To: <eb19a389-d2b3-d0cc-fd25-62bbb121cf98@suse.com>
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
next prev parent reply other threads:[~2021-02-27 4:18 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-25 15:23 [PATCH for-next 0/6] Minimal build for RISCV Connor Davis
2021-02-25 15:24 ` [PATCH for-next 1/6] xen/char: Default HAS_NS16550 to y only for X86 and ARM Connor Davis
2021-02-25 15:24 ` [PATCH for-next 2/6] xen/common: Guard iommu symbols with CONFIG_HAS_PASSTHROUGH Connor Davis
2021-02-25 15:45 ` Jan Beulich
2021-02-26 2:54 ` Connor Davis
2021-02-26 7:41 ` Jan Beulich
2021-02-25 15:24 ` [PATCH for-next 3/6] xen/sched: Fix build when NR_CPUS == 1 Connor Davis
2021-02-25 15:50 ` Jan Beulich
2021-02-26 3:08 ` Connor Davis
2021-02-26 8:31 ` Jan Beulich
2021-02-26 16:49 ` Dario Faggioli
2021-02-27 4:17 ` Connor Davis [this message]
2021-02-25 22:55 ` Bob Eshleman
2021-02-26 3:01 ` Connor Davis
2021-02-26 15:21 ` Bob Eshleman
2021-02-25 15:24 ` [PATCH for-next 4/6] xen: Fix build when !CONFIG_GRANT_TABLE Connor Davis
2021-02-25 15:53 ` Jan Beulich
2021-02-26 3:36 ` Connor Davis
2021-02-25 15:24 ` [PATCH for-next 5/6] xen: Add files needed for minimal riscv build Connor Davis
2021-02-25 23:14 ` Andrew Cooper
2021-02-26 1:06 ` Stefano Stabellini
2021-02-27 4:05 ` Connor Davis
2021-02-26 3:29 ` Connor Davis
2021-02-26 15:30 ` Bob Eshleman
2021-02-26 15:55 ` Andrew Cooper
2021-02-26 16:21 ` Bob Eshleman
2021-02-26 16:56 ` Andrew Cooper
2021-03-12 17:01 ` Jan Beulich
2021-03-12 17:09 ` Jan Beulich
2021-05-14 3:25 ` Connor Davis
2021-02-25 15:24 ` [PATCH for-next 6/6] automation: add container for riscv64 builds Connor Davis
2021-02-26 0:31 ` Stefano Stabellini
2021-02-26 6:15 ` Connor Davis
2021-02-26 15:54 ` [PATCH for-next 0/6] Minimal build for RISCV Bob Eshleman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210227041747.p6kfrtvmkk5sbwof@thewall \
--to=connojdavis@gmail.com \
--cc=bobbyeshleman@gmail.com \
--cc=dfaggioli@suse.com \
--cc=george.dunlap@citrix.com \
--cc=jbeulich@suse.com \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).