Messages in this thread | | | Date | Sun, 24 Jun 2012 20:57:33 -0700 | From | "Paul E. McKenney" <> | Subject | Re: BUG: tracer_alloc_buffers returned with preemption imbalance |
| |
On Sun, Jun 24, 2012 at 04:37:28PM +0800, Cong Wang wrote: > On Sun, Jun 24, 2012 at 1:48 AM, Fengguang Wu <fengguang.wu@intel.com> wrote: > >> > static inline int rcu_blocking_is_gp(void) > >> > { > >> > might_sleep(); /* Check for RCU read-side critical section. */ > >> > + preempt_disable(); > >> > return num_online_cpus() <= 1; > >> > + preempt_enable(); > >> > } > >> > >> Thank you! I have no idea how a preempt_disable() causes that badness > >> to happen, but this commit is not yet critically important, so I will > >> drop it. > > > > preempt_enable() becomes dead code because of the return statement? > > I wonder why gcc didn't issue a warning (or I failed to catch it)... > > > > gcc has an option -Wunreachable-code, but we don't enable it > when building kernel, nor it will be enabled with -Wall. If we enable it, > we will have many false-positives as we have lots of debugging code > which is not reachable unless we enable some debugging option. > > However, when I test it manually with the following code: > > ~% cat /tmp/unreachable.c > int main(void) > { > int a = 0; > a++; > return ++a; > a++; > } > ~% gcc -Wunreachable-code -O0 -c /tmp/unreachable.c > > gcc still doesn't give me any warning for the last line of the code, > gcc optimizes it out silently, I am wondering if this is a gcc bug.
But in my case, the trailing preempt_enable() should not have been optimized away, right? Wouldn't it be more like the following?
int a = 0; int main(void) { a++; return ++a; a++; }
Hmmm... But this -still- doesn't emit any warnings.
Thanx, Paul
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |