From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Josh Triplett <josh@joshtriplett.org>,
linux-kernel@vger.kernel.org, mingo@elte.hu,
laijs@cn.fujitsu.com, dipankar@in.ibm.com,
akpm@linux-foundation.org, mathieu.desnoyers@polymtl.ca,
niv@us.ibm.com, tglx@linutronix.de, peterz@infradead.org,
Valdis.Kletnieks@vt.edu, dhowells@redhat.com,
edumazet@google.com, darren@dvhart.com, fweisbec@gmail.com,
sbw@mit.edu, patches@linaro.org, markus@trippelsdorf.de
Subject: Re: [PATCH tip/core/rcu 4/6] rcu: Silence compiler array out-of-bounds false positive
Date: Mon, 7 Jan 2013 14:33:16 -0800 [thread overview]
Message-ID: <20130107223316.GB2525@linux.vnet.ibm.com> (raw)
In-Reply-To: <1357597117.5190.4.camel@gandalf.local.home>
On Mon, Jan 07, 2013 at 05:18:37PM -0500, Steven Rostedt wrote:
> On Mon, 2013-01-07 at 09:19 -0800, Paul E. McKenney wrote:
> > On Mon, Jan 07, 2013 at 09:16:02AM -0800, Paul E. McKenney wrote:
> > > On Mon, Jan 07, 2013 at 07:50:02AM -0800, Josh Triplett wrote:
> > > > On Sat, Jan 05, 2013 at 09:09:36AM -0800, Paul E. McKenney wrote:
> > > > > From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> > > > >
> > > > > It turns out that gcc 4.8 warns on array indexes being out of bounds
> > > > > unless it can prove otherwise. It gives this warning on some RCU
> > > > > initialization code. Because this is far from any fastpath, add
> > > > > an explicit check for array bounds and panic if so. This gives the
> > > > > compiler enough information to figure out that the array index is never
> > > > > out of bounds.
> > > > >
> > > > > However, if a similar false positive occurs on a fastpath, it will
> > > > > probably be necessary to tell the compiler to keep its array-index
> > > > > anxieties to itself. ;-)
> > > > >
> > > > > Markus Trippelsdorf <markus@trippelsdorf.de>
> > > > > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > > > > ---
> > > > > kernel/rcutree.c | 4 ++++
> > > > > 1 files changed, 4 insertions(+), 0 deletions(-)
> > > > >
> > > > > diff --git a/kernel/rcutree.c b/kernel/rcutree.c
> > > > > index d145796..e0d9815 100644
> > > > > --- a/kernel/rcutree.c
> > > > > +++ b/kernel/rcutree.c
> > > > > @@ -2938,6 +2938,10 @@ static void __init rcu_init_one(struct rcu_state *rsp,
> > > > >
> > > > > BUILD_BUG_ON(MAX_RCU_LVLS > ARRAY_SIZE(buf)); /* Fix buf[] init! */
> > > > >
> > > > > + /* Silence gcc 4.8 warning about array index out of range. */
> > > > > + if (rcu_num_lvls > RCU_NUM_LVLS)
> > > > > + panic("rcu_init_one: rcu_num_lvls overflow");
> > > >
> > > > Why not write this as BUG_ON(rcu_num_lvls > RCU_NUM_LVLS)? Given that
> > > > the condition in question can never happen, you don't really need an
> > > > explanatory message.
> > >
> > > Good point, will do!
> >
> > Ah, wait, BUG_ON() sometimes compiles to nothingness:
> >
> > #ifndef HAVE_ARCH_BUG_ON
> > #define BUG_ON(condition) do { if (condition) ; } while(0)
> > #endif
> >
> > So I do need the explicit "if". :-(
>
> Bah, those archs shouldn't be bothered with. If they don't want to bug,
> then that's there problem :-)
;-) ;-) ;-)
> Lots of places in the kernel have BUG_ON() where they require it to
> panic.
Fair point, but that doesn't mean that I want them complaining to
me when as a result of the compiler's array-index anxieties.
Thanx, Paul
next prev parent reply other threads:[~2013-01-07 22:34 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-05 17:09 [PATCH tip/core/rcu 0/6] RCU fixes for 3.9 Paul E. McKenney
2013-01-05 17:09 ` [PATCH tip/core/rcu 1/6] rcu: Fix blimit type for trace_rcu_batch_start() Paul E. McKenney
2013-01-05 17:09 ` [PATCH tip/core/rcu 2/6] rcu: Make rcu_is_cpu_rrupt_from_idle helper functions static Paul E. McKenney
2013-01-05 17:09 ` [PATCH tip/core/rcu 3/6] rcu: Use new nesting value for rcu_dyntick trace in rcu_eqs_enter_common Paul E. McKenney
2013-01-05 17:09 ` [PATCH tip/core/rcu 4/6] rcu: Silence compiler array out-of-bounds false positive Paul E. McKenney
2013-01-07 15:50 ` Josh Triplett
2013-01-07 17:16 ` Paul E. McKenney
2013-01-07 17:19 ` Paul E. McKenney
2013-01-07 22:18 ` Steven Rostedt
2013-01-07 22:33 ` Paul E. McKenney [this message]
2013-01-07 18:08 ` Markus Trippelsdorf
2013-01-07 18:24 ` Josh Triplett
2013-01-07 18:43 ` Paul E. McKenney
2013-01-05 17:09 ` [PATCH tip/core/rcu 5/6] rcutorture: don't compare ptr with 0 Paul E. McKenney
2013-01-05 17:09 ` [PATCH tip/core/rcu 6/6] rcu: Correct 'optimized' to 'optimize' in header comment Paul E. McKenney
2013-01-05 17:19 ` [PATCH tip/core/rcu 0/6] RCU fixes for 3.9 Paul E. McKenney
2013-01-07 15:51 ` Josh Triplett
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=20130107223316.GB2525@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=akpm@linux-foundation.org \
--cc=darren@dvhart.com \
--cc=dhowells@redhat.com \
--cc=dipankar@in.ibm.com \
--cc=edumazet@google.com \
--cc=fweisbec@gmail.com \
--cc=josh@joshtriplett.org \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=markus@trippelsdorf.de \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=mingo@elte.hu \
--cc=niv@us.ibm.com \
--cc=patches@linaro.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sbw@mit.edu \
--cc=tglx@linutronix.de \
/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.