From: Ingo Molnar <mingo@kernel.org>
To: Davidlohr Bueso <davidlohr@hp.com>
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
Subject: Re: [PATCH 5/5] futex: Silence uninitialized warnings
Date: Mon, 13 Jan 2014 11:16:28 +0100 [thread overview]
Message-ID: <20140113101628.GA8270@gmail.com> (raw)
In-Reply-To: <1389569486-25487-6-git-send-email-davidlohr@hp.com>
* Davidlohr Bueso <davidlohr@hp.com> wrote:
> From: Davidlohr Bueso <davidlohr@hp.com>
>
> 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 <mingo@kernel.org>
> Acked-by: Darren Hart <dvhart@linux.intel.com>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Thomas Gleixner <tglx@linutronix.de>
> Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Cc: Mike Galbraith <efault@gmx.de>
> Cc: Jeff Mahoney <jeffm@suse.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Scott Norton <scott.norton@hp.com>
> Cc: Tom Vaden <tom.vaden@hp.com>
> Cc: Aswin Chandramouleeswaran <aswin@hp.com>
> Cc: Waiman Long <Waiman.Long@hp.com>
> Cc: Jason Low <jason.low2@hp.com>
> Signed-off-by: Davidlohr Bueso <davidlohr@hp.com>
> ---
> 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 ...
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.
Thanks,
Ingo
next prev parent reply other threads:[~2014-01-13 10:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-12 23:31 [PATCH v6 0/5] futex: Wakeup optimizations Davidlohr Bueso
2014-01-12 23:31 ` [PATCH v6 1/5] futex: Misc cleanups Davidlohr Bueso
2014-01-13 15:52 ` [tip:core/locking] futexes: Clean up various details tip-bot for Jason Low
2014-01-12 23:31 ` [PATCH v6 2/5] futex: Larger hash table Davidlohr Bueso
2014-01-13 15:52 ` [tip:core/locking] futexes: Increase hash table size for better performance tip-bot for Davidlohr Bueso
2014-01-12 23:31 ` [PATCH v6 3/5] futex: Document ordering guarantees Davidlohr Bueso
2014-01-13 15:52 ` [tip:core/locking] futexes: Document multiprocessor " tip-bot for Thomas Gleixner
2014-01-12 23:31 ` [PATCH 4/5] futex: Avoid taking hb lock if nothing to wakeup Davidlohr Bueso
2014-01-13 15:52 ` [tip:core/locking] futexes: Avoid taking the hb->lock if there' s nothing to wake up tip-bot for Davidlohr Bueso
2014-01-12 23:31 ` [PATCH 5/5] futex: Silence uninitialized warnings Davidlohr Bueso
2014-01-13 10:16 ` Ingo Molnar [this message]
2014-01-13 17:28 ` Davidlohr Bueso
2014-01-13 10:03 ` [PATCH v6 0/5] futex: Wakeup optimizations Thomas Gleixner
2014-01-13 10:05 ` 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=20140113101628.GA8270@gmail.com \
--to=mingo@kernel.org \
--cc=Waiman.Long@hp.com \
--cc=aswin@hp.com \
--cc=davidlohr@hp.com \
--cc=dvhart@linux.intel.com \
--cc=efault@gmx.de \
--cc=jason.low2@hp.com \
--cc=jeffm@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peterz@infradead.org \
--cc=scott.norton@hp.com \
--cc=tglx@linutronix.de \
--cc=tom.vaden@hp.com \
--cc=torvalds@linux-foundation.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox