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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 16 Feb 2012 08:32:03 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	yad.naveen@...il.com
Cc:	Thomas Gleixner <tglx@...utronix.de>,
	Darren Hart <dvhart@...ux.intel.com>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] futex: fix uninitialized warning

On Thu, 2012-02-16 at 15:15 +0530, yad.naveen@...il.com wrote:
> From: Naveen Yadav <yad.naveen@...il.com>
> 
> 
> Signed-off-by: Naveen Yadav <yad.naveen@...il.com>
> ---
>  kernel/futex.c |    4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/futex.c b/kernel/futex.c
> index 6487e4c..fdb93b0 100644
> --- a/kernel/futex.c
> +++ b/kernel/futex.c
> @@ -1588,7 +1588,7 @@ static int fixup_pi_state_owner(u32 __user *uaddr, struct futex_q *q,
>  	u32 newtid = task_pid_vnr(newowner) | FUTEX_WAITERS;
>  	struct futex_pi_state *pi_state = q->pi_state;
>  	struct task_struct *oldowner = pi_state->owner;
> -	u32 uval, curval, newval;
> +	u32 uval, uninitialized_var(curval), newval;

NAK, an uninitialized_var() macro should not be added unless there's a
really good reason that gcc is not detecting it. Some logic does require
this.

If it ends up being that this macro should be added, then it should have
a comment to why it is added, and why gcc is failing to figure out that
it is initialized.

What gcc version is complaining and what arch is this for? There could
definitely be a case here that it may really be uninitialized, and this
patch would hide that bug.

The cmpxchg_futex_* is arch specific, and if an arch screws it up, we
will never know that this value is uninitialized because this patch
would have hidden that bug. Hiding a bug is much worse than dealing with
some "might be uninitialized" warnings.

-- Steve

>  	int ret;
>  
>  	/* Owner died? */
> @@ -2493,7 +2493,7 @@ err_unlock:
>   */
>  int handle_futex_death(u32 __user *uaddr, struct task_struct *curr, int pi)
>  {
> -	u32 uval, nval, mval;
> +	u32 uval, uninitialized_var(nval), mval;
>  
>  retry:
>  	if (get_user(uval, uaddr))


--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ