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


* Rusty Russell <rusty@rustcorp.com.au> wrote:

> On Sat, 9 May 2009 04:39:44 am Ingo Molnar wrote:
> > * Jeff Garzik <jeff@garzik.org> wrote:
> > > The semantics for variable-length arrays __in the middle of structs__
> > > are quite muddy, and a case in sched.c presents an interesting case,
> > > as the preceding code comment indicates:
> > >
> > > 	/*
> > > 	 * The cpus mask in sched_group and sched_domain hangs off
> > > 	 the end.  * FIXME: use cpumask_var_t or dynamic percpu alloc
> > > 	 to avoid * wasting space for nr_cpu_ids < CONFIG_NR_CPUS.  */
> > > 	struct static_sched_group {
> > > 		struct sched_group sg; DECLARE_BITMAP(cpus,
> > > 		CONFIG_NR_CPUS);
> > > 	};
> 
> Yeah, it's kinda nasty.  Generally, sched_group is dynamically 
> allocated, so we just allocate sizeof(struct sched_group) + size 
> of nr_cpu_ids bits.
> 
> These ones are static, and it was easier to put this hack in than 
> make them dynamic.  There's nothing wrong with it, until we really 
> want NR_CPUS == bignum, or we want to get rid of NR_CPUS 
> altogether for CONFIG_CPUMASKS_OFFSTACK (which would be very 
> clean, but not clearly worthwhile).
> 
> But more importantly, my comment is obviously unclear, since your 
> patch shows you didn't understand the purpose of the field: The 
> cpus bitmap *is* the sg-cpumask[] array.

I dont think Jeff misunderstood this code (hey, he found it! :), his 
patch is a demonstration of why this code is a problem: a seemingly 
innocious invariant modification (his patch) kills the kernel dead.

> > > Maybe a C expert can say whether cpumask[0] is better than cpumask[],
> > > or have other comments?
> 
> [0] is a gcc extension, but it should be equivalent.
> 
> > That cpumask[] should probably be cpumask[0], to document the
> > aliasing to ->span and ->cpus properly.
> 
> If the comment wasn't sufficient documentation, I don't think that 
> would help :(

It's a visual helper: it matches up with how we do these 'zero size 
array means dynamic structure continuation' tricks generally.

I first mis-parsed the code for a second when seeing cpumask[]. 
cpumask[0] stands out like a sore thumb. And we dont read comments 
anyway ;-)

Jeff, i suspect you found this because you are working on something 
rather interesting? :) If yes, would it help your project if we did 
the cpumask[0] cleanup and pushed it upstream immediately?

	Ingo

  parent reply	other threads:[~2009-05-11 10:59 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
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       ` Ingo Molnar [this message]
2009-05-11 20:43         ` [RFC PATCH 2/2] kernel/sched.c: VLA in middle of struct 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=20090511105816.GG4648@elte.hu \
    --to=mingo@elte.hu \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=jeff@garzik.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=roland@redhat.com \
    --cc=rusty@rustcorp.com.au \
    --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.