Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753624AbaAMR3X (ORCPT ); Mon, 13 Jan 2014 12:29:23 -0500 Received: from g2t1383g.austin.hp.com ([15.217.136.92]:14814 "EHLO g2t1383g.austin.hp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751732AbaAMR3U (ORCPT ); Mon, 13 Jan 2014 12:29:20 -0500 Message-ID: <1389634128.2750.1.camel@buesod1.americas.hpqcorp.net> Subject: Re: [PATCH 5/5] futex: Silence uninitialized warnings From: Davidlohr Bueso To: Ingo Molnar Cc: linux-kernel@vger.kernel.org, dvhart@linux.intel.com, peterz@infradead.org, tglx@linutronix.de, paulmck@linux.vnet.ibm.com, efault@gmx.de, jeffm@suse.com, torvalds@linux-foundation.org, jason.low2@hp.com, Waiman.Long@hp.com, tom.vaden@hp.com, scott.norton@hp.com, aswin@hp.com Date: Mon, 13 Jan 2014 09:28:48 -0800 In-Reply-To: <20140113101628.GA8270@gmail.com> References: <1389569486-25487-1-git-send-email-davidlohr@hp.com> <1389569486-25487-6-git-send-email-davidlohr@hp.com> <20140113101628.GA8270@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.6.4 (3.6.4-3.fc18) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2014-01-13 at 11:16 +0100, Ingo Molnar wrote: > * Davidlohr Bueso wrote: > > > From: Davidlohr Bueso > > > > Callers of cmpxchg_futex_value_locked() can trigger the following: > > > > kernel/futex.c: In function ‘futex_lock_pi_atomic’: > > kernel/futex.c:725: warning: ‘curval’ may be used uninitialized in this function > > > > This was initially addressed by commit 7cfdaf38, but others still remain. Silence > > these messages once and for all as the variables really aren't uninitialized. > > > > Cc: Ingo Molnar > > Acked-by: Darren Hart > > Cc: Peter Zijlstra > > Cc: Thomas Gleixner > > Cc: Paul E. McKenney > > Cc: Mike Galbraith > > Cc: Jeff Mahoney > > Cc: Linus Torvalds > > Cc: Scott Norton > > Cc: Tom Vaden > > Cc: Aswin Chandramouleeswaran > > Cc: Waiman Long > > Cc: Jason Low > > Signed-off-by: Davidlohr Bueso > > --- > > kernel/futex.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/kernel/futex.c b/kernel/futex.c > > index be6399a..8d40953 100644 > > --- a/kernel/futex.c > > +++ b/kernel/futex.c > > @@ -838,7 +838,7 @@ static int futex_lock_pi_atomic(u32 __user *uaddr, struct futex_hash_bucket *hb, > > struct task_struct *task, int set_waiters) > > { > > int lock_taken, ret, force_take = 0; > > - u32 uval, newval, curval, vpid = task_pid_vnr(task); > > + u32 uval, newval, uninitialized_var(curval), vpid = task_pid_vnr(task); > > > > retry: > > ret = lock_taken = 0; > > @@ -2227,7 +2227,7 @@ static int futex_unlock_pi(u32 __user *uaddr, unsigned int flags) > > struct futex_hash_bucket *hb; > > struct futex_q *this, *next; > > union futex_key key = FUTEX_KEY_INIT; > > - u32 uval, vpid = task_pid_vnr(current); > > + u32 uninitialized_var(uval), vpid = task_pid_vnr(current); > > int ret; > > > > retry: > > @@ -2843,7 +2843,7 @@ SYSCALL_DEFINE6(futex, u32 __user *, uaddr, int, op, u32, val, > > > > static int __init futex_init(void) > > { > > - u32 curval; > > + u32 uninitialized_var(curval); > > unsigned long i; > > > > #if CONFIG_BASE_SMALL > > I'm skipping this patch though. > > I consider the use of uninitialized_var() dangerous and broken: if for > whatever reason a future change to the code makes the warning trigger > and makes it _true_, then we won't notice it because it's hidden > unconditionally ... Sure, so we should then get rid of the already existing ones from 7cfdaf38. > > The following alternative measures can be used to make spurious > old-compiler warnings go away: > > - Consider upgrading your compiler. > > - If for whatever reason you can't upgrade your compiler then > restructure the code so that the flow of logic is more apparent > even to older GCC versions. (Chances are that the flow will be more > readable to humans too, so it's a win-win!) > > - If you think the flow is exactly perfect and (older) GCC which you > cannot upgrade is still being silly, then initialize the variable > to zero. On a new compiler this won't mean a thing because GCC will > notice the superfluous initialization and will optimize it out - > and it's a lot safer than just shutting the warning up forever. Ok, we could go wit this last path then. -- 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/