futex: fix uninitialized warning
PATCH 1/1 futex: fix uninitialized warning
From: Naveen Yadav <[email protected]>
--- kernel/futex.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
kernel/futex.c +2 -2
@@ -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;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))
Signature · 1 line
1.7.8.4
Steven Rostedt
NAKQuoted 13 lines · On Thu, 2012-02-16 at 15:15 +0530, [email protected] wrote:
From: Naveen Yadav <[email protected]>
Signed-off-by Naveen Yadav <[email protected]>--- kernel/futex.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)kernel/futex.c +0
-0
kernel/futex.c static int fixup_pi_state_owner(u32 __user *uaddr, struct futex_q *q, · line 1591
Quoted 5 lines
kernel/futex.c +1
-1@@ -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
Quoted 12 lines
kernel/futex.c +1
-1int 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))
Thanks a lot Steven for your comments:
I am Building for ARM versatile Board. and
I check with gcc version gcc version 4.4.1 and gcc version 4.6.3.
If we check the code flow, we can confirm that this is fake warning , since value will be updated cmpxchg_futex_value_locked() function. May be this is limitation of GCC.
So we can ignore the warning ..
Thanks.
naveen
Quoted 53 lines · Steven Rostedt
Quoted 13 lines · On Thu, 2012-02-16 at 15:15 +0530, [email protected] wrote:
From: Naveen Yadav <[email protected]>
Signed-off-by Naveen Yadav <[email protected]>---
kernel/futex.c | 4 ++--1 files changed, 2 insertions(+), 2 deletions(-)kernel/futex.c +0
-0kernel/futex.c static int fixup_pi_state_owner(u32 __user *uaddr, struct futex_q *q, · line 1591
Quoted 5 lines
kernel/futex.c +1
-1@@ -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
Quoted 12 lines
kernel/futex.c +1
-1int 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))