linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Darren Hart <dvhart@linux.intel.com>
To: Davidlohr Bueso <davidlohr@hp.com>
Cc: linux-kernel@vger.kernel.org, mingo@kernel.org,
	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/4] futex: silence uninitialized warnings
Date: Mon, 06 Jan 2014 10:48:35 -0800	[thread overview]
Message-ID: <1389034115.30730.32.camel@dvhart-mobl4.amr.corp.intel.com> (raw)
In-Reply-To: <1388972316.4918.5.camel@buesod1.americas.hpqcorp.net>

On Sun, 2014-01-05 at 17:38 -0800, Davidlohr Bueso 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.
> 

I've gone after such things myself and seen arguments against this as it
will mask any future such bugs. If, as in this case, the value is indeed
not being used uninitialized, I believe this is considered a compiler
bug. Do we mask compiler bugs in the kernel at the expense of catching
legitimate future bugs? There are certainly several examples of this
method being used throughout the kernel.

Alternatively - does anyone see something Davidlohr or I have missed in
this call chain? It seems to me that the only way for curval not be
initialized is if cmpxchg_futex_value_lock() returns an error, in which
case we return without using curval anyway.

Is there some rule about how to deal with this when inline ASM is
involved? (Although there is an explicit assignment following that ASM).

If not, given existing precedent, and the unlikelihood of this
particular path seeing significant changes, I'm inclined to agree with
the proposed fix:

Acked-by: Darren Hart <dvhart@linux.intel.com>

--
Darren

> 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 5b4d09e..65ade8a 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

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel



  reply	other threads:[~2014-01-06 18:48 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-02 15:05 [PATCH v5 0/4] futex: Wakeup optimizations Davidlohr Bueso
2014-01-02 15:05 ` [PATCH v5 1/4] futex: Misc cleanups Davidlohr Bueso
2014-01-11  6:43   ` Paul E. McKenney
2014-01-02 15:05 ` [PATCH v5 2/4] futex: Larger hash table Davidlohr Bueso
2014-01-11  7:37   ` Paul E. McKenney
2014-01-02 15:05 ` [PATCH v5 3/4] futex: Document ordering guarantees Davidlohr Bueso
2014-01-06 18:58   ` Darren Hart
2014-01-11  7:40   ` Paul E. McKenney
2014-01-02 15:05 ` [PATCH v5 4/4] futex: Avoid taking hb lock if nothing to wakeup Davidlohr Bueso
2014-01-02 19:23   ` Linus Torvalds
2014-01-02 20:59     ` Davidlohr Bueso
2014-01-06 20:56       ` Darren Hart
2014-01-06 20:52   ` Darren Hart
2014-01-07  3:29     ` Davidlohr Bueso
2014-01-07 17:40       ` Darren Hart
2014-01-11  9:49   ` Paul E. McKenney
2014-01-11  9:52     ` Paul E. McKenney
2014-01-11 18:21       ` Davidlohr Bueso
2014-01-06  0:59 ` [PATCH v5 0/4] futex: Wakeup optimizations Davidlohr Bueso
2014-01-06  1:38 ` [PATCH 5/4] futex: silence uninitialized warnings Davidlohr Bueso
2014-01-06 18:48   ` Darren Hart [this message]
2014-01-07  2:55   ` Linus Torvalds
2014-01-07  3:02     ` Davidlohr Bueso

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=1389034115.30730.32.camel@dvhart-mobl4.amr.corp.intel.com \
    --to=dvhart@linux.intel.com \
    --cc=Waiman.Long@hp.com \
    --cc=aswin@hp.com \
    --cc=davidlohr@hp.com \
    --cc=efault@gmx.de \
    --cc=jason.low2@hp.com \
    --cc=jeffm@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@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;
as well as URLs for NNTP newsgroup(s).