linux-kernel - Re: [PATCH 5/4] futex: silence uninitialized warnings

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1389034115.30730.32.camel@dvhart-mobl4.amr.corp.intel.com>
Date:	Mon, 06 Jan 2014 10:48:35 -0800
From:	Darren Hart <dvhart@...ux.intel.com>
To:	Davidlohr Bueso <davidlohr@...com>
Cc:	linux-kernel@...r.kernel.org, mingo@...nel.org,
	peterz@...radead.org, tglx@...utronix.de,
	paulmck@...ux.vnet.ibm.com, efault@....de, jeffm@...e.com,
	torvalds@...ux-foundation.org, jason.low2@...com,
	Waiman.Long@...com, tom.vaden@...com, scott.norton@...com,
	aswin@...com
Subject: Re: [PATCH 5/4] futex: silence uninitialized warnings

On Sun, 2014-01-05 at 17:38 -0800, Davidlohr Bueso wrote:
> From: Davidlohr Bueso <davidlohr@...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@...ux.intel.com>

--
Darren

> Signed-off-by: Davidlohr Bueso <davidlohr@...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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/