linux-kernel - Re: [PATCH] futex: fix uninitialized warning

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] [day] [month] [year] [list]

Message-ID: <CAJ8eaTwxN07L4yAj5qmbrZdrpP+OEX9qXR4dX4A+sF74=MK==Q@mail.gmail.com>
Date:	Fri, 17 Feb 2012 10:32:29 +0530
From:	naveen yadav <yad.naveen@...il.com>
To:	Steven Rostedt <rostedt@...dmis.org>
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

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



On Thu, Feb 16, 2012 at 7:02 PM, Steven Rostedt <rostedt@...dmis.org> wrote:
> 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/