All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rusty Russell <rusty@rustcorp.com.au>
To: Al Viro <viro@zeniv.linux.org.uk>
Cc: Jeff Garzik <jeff@garzik.org>, Ingo Molnar <mingo@elte.hu>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Mike Travis <travis@sgi.com>, LKML <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	roland@redhat.com
Subject: Re: [RFC PATCH 2/2] kernel/sched.c: VLA in middle of struct
Date: Wed, 13 May 2009 11:42:26 +0930	[thread overview]
Message-ID: <200905131142.27484.rusty@rustcorp.com.au> (raw)
In-Reply-To: <20090512140344.GO8633@ZenIV.linux.org.uk>

On Tue, 12 May 2009 11:33:44 pm Al Viro wrote:
> On Tue, May 12, 2009 at 11:04:51PM +0930, Rusty Russell wrote:
> > ... you're not normally allowed to embed structs with them in another
> > struct (according to the  gcc docs; I can't actually find this clearly
> > stated in the standard).
>
> 6.7.2.1p2.

Ah, thanks.

> > Anyway, since [] is C99, I thought it preferable to [0] which is a gcc
> > extension.  However, if C99 is really so braindead as to disallow this
> > fairly standard trick, so I'm happy to go with the gcc extension.[1]
>
> No.  There's a standard way to do that in C99; you can put a struct with
> that thing into a union.

Ah, thanks for the clue.

How's this:

sched: avoid flexible array member inside struct (gcc extension)

struct sched_group and struct sched_domain end in 'unsigned long
cpumask[]' which Jeff Garzik notes is not legal to place inside
another struct.  It upsets sparse and clang (LLVM's C front end).

Al Viro pointed out that a union is the Right Way to do this.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Reported-by: Jeff Garzik <jeff@garzik.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
---
 kernel/sched.c |   32 +++++++++++++++++---------------
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/kernel/sched.c b/kernel/sched.c
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -7756,22 +7756,24 @@ int sched_smt_power_savings = 0, sched_m
  * FIXME: use cpumask_var_t or dynamic percpu alloc to avoid wasting space
  * for nr_cpu_ids < CONFIG_NR_CPUS.
  */
-struct static_sched_group {
+union static_sched_group {
 	struct sched_group sg;
-	DECLARE_BITMAP(cpus, CONFIG_NR_CPUS);
-};
-
-struct static_sched_domain {
+	char _sg_and_cpus[sizeof(struct sched_group) +
+			  BITS_TO_LONGS(CONFIG_NR_CPUS) * sizeof(long)];
+};
+
+union static_sched_domain {
 	struct sched_domain sd;
-	DECLARE_BITMAP(span, CONFIG_NR_CPUS);
+	char _sd_and_cpus[sizeof(struct sched_domain) +
+			  BITS_TO_LONGS(CONFIG_NR_CPUS) * sizeof(long)];
 };
 
 /*
  * SMT sched-domains:
  */
 #ifdef CONFIG_SCHED_SMT
-static DEFINE_PER_CPU(struct static_sched_domain, cpu_domains);
-static DEFINE_PER_CPU(struct static_sched_group, sched_group_cpus);
+static DEFINE_PER_CPU(union static_sched_domain, cpu_domains);
+static DEFINE_PER_CPU(union static_sched_group, sched_group_cpus);
 
 static int
 cpu_to_cpu_group(int cpu, const struct cpumask *cpu_map,
@@ -7787,8 +7789,8 @@ cpu_to_cpu_group(int cpu, const struct c
  * multi-core sched-domains:
  */
 #ifdef CONFIG_SCHED_MC
-static DEFINE_PER_CPU(struct static_sched_domain, core_domains);
-static DEFINE_PER_CPU(struct static_sched_group, sched_group_core);
+static DEFINE_PER_CPU(union static_sched_domain, core_domains);
+static DEFINE_PER_CPU(union static_sched_group, sched_group_core);
 #endif /* CONFIG_SCHED_MC */
 
 #if defined(CONFIG_SCHED_MC) && defined(CONFIG_SCHED_SMT)
@@ -7815,8 +7817,8 @@ cpu_to_core_group(int cpu, const struct 
 }
 #endif
 
-static DEFINE_PER_CPU(struct static_sched_domain, phys_domains);
-static DEFINE_PER_CPU(struct static_sched_group, sched_group_phys);
+static DEFINE_PER_CPU(union static_sched_domain, phys_domains);
+static DEFINE_PER_CPU(union static_sched_group, sched_group_phys);
 
 static int
 cpu_to_phys_group(int cpu, const struct cpumask *cpu_map,
@@ -7843,11 +7845,11 @@ cpu_to_phys_group(int cpu, const struct 
  * groups, so roll our own. Now each node has its own list of groups which
  * gets dynamically allocated.
  */
-static DEFINE_PER_CPU(struct static_sched_domain, node_domains);
+static DEFINE_PER_CPU(union static_sched_domain, node_domains);
 static struct sched_group ***sched_group_nodes_bycpu;
 
-static DEFINE_PER_CPU(struct static_sched_domain, allnodes_domains);
-static DEFINE_PER_CPU(struct static_sched_group, sched_group_allnodes);
+static DEFINE_PER_CPU(union static_sched_domain, allnodes_domains);
+static DEFINE_PER_CPU(union static_sched_group, sched_group_allnodes);
 
 static int cpu_to_allnodes_group(int cpu, const struct cpumask *cpu_map,
 				 struct sched_group **sg,


  reply	other threads:[~2009-05-13  2:12 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-08 18:48 [PATCH 1/2] kernel/{sched,smp}.c: fix static decl prior to struct declaration Jeff Garzik
2009-05-08 18:50 ` [RFC PATCH 2/2] kernel/sched.c: VLA in middle of struct Jeff Garzik
2009-05-08 19:09   ` Ingo Molnar
2009-05-10  8:49     ` Rusty Russell
2009-05-10 15:09       ` Jeff Garzik
2009-05-12 13:34         ` Rusty Russell
2009-05-12 14:03           ` Al Viro
2009-05-13  2:12             ` Rusty Russell [this message]
2009-05-13  2:31               ` Jeff Garzik
2009-05-13  5:36               ` Al Viro
2009-05-13  6:49                 ` [PATCH] sched: avoid flexible array member inside struct (gcc extension) Rusty Russell
2009-05-13 13:51                   ` [tip:sched/urgent] " tip-bot for Rusty Russell
2009-05-11 10:58       ` [RFC PATCH 2/2] kernel/sched.c: VLA in middle of struct Ingo Molnar
2009-05-11 20:43         ` Jeff Garzik
2009-05-11 20:49           ` Ingo Molnar
2009-05-12  2:24             ` Jeff Garzik
2009-05-12  8:54               ` Ingo Molnar
2009-05-08 19:04 ` [PATCH 1/2] kernel/{sched,smp}.c: fix static decl prior to struct declaration Ingo Molnar
2009-05-08 19:08   ` Jeff Garzik
2009-05-08 19:13     ` Ingo Molnar
2009-05-08 19:38 ` [PATCH 1/2 v2] " Jeff Garzik
2009-05-11 11:26   ` Ingo Molnar
2009-05-11 20:06     ` Jeff Garzik
2009-05-11 20:51       ` Ingo Molnar
2009-05-11 11:30   ` [tip:sched/core] kernel/{sched, smp}.c: " tip-bot for Jeff Garzik
2009-05-11 20:02   ` [PATCH 1/2 v3] kernel/{sched,smp}.c: " Jeff Garzik
2009-05-11 21:51     ` [tip:sched/urgent] kernel/{sched, smp}.c: " tip-bot for Jeff Garzik
2009-05-11 21:56       ` Ingo Molnar

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=200905131142.27484.rusty@rustcorp.com.au \
    --to=rusty@rustcorp.com.au \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=jeff@garzik.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=roland@redhat.com \
    --cc=travis@sgi.com \
    --cc=viro@zeniv.linux.org.uk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.