[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87sgh6o3ur.fsf@nanos.tec.linutronix.de>
Date: Tue, 14 Apr 2020 10:42:36 +0200
From: Thomas Gleixner <tglx@...utronix.de>
To: Stephen Rothwell <sfr@...b.auug.org.au>
Cc: Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
Peter Zijlstra <peterz@...radead.org>,
Linux Next Mailing List <linux-next@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Al Viro <viro@...iv.linux.org.uk>
Subject: Re: linux-next: build warning after merge of the tip tree
Stephen,
Stephen Rothwell <sfr@...b.auug.org.au> writes:
> On Thu, 02 Apr 2020 00:39:55 +0200 Thomas Gleixner <tglx@...utronix.de> wrote:
>> and the below proves it:
>>
>> diff --git a/arch/arm/include/asm/futex.h b/arch/arm/include/asm/futex.h
>> index e133da303a98..a9151884bc85 100644
>> --- a/arch/arm/include/asm/futex.h
>> +++ b/arch/arm/include/asm/futex.h
>> @@ -165,8 +165,13 @@ arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *uaddr)
>> preempt_enable();
>> #endif
>>
>> - if (!ret)
>> - *oval = oldval;
>> + /*
>> + * Store unconditionally. If ret != 0 the extra store is the least
>> + * of the worries but GCC cannot figure out that __futex_atomic_op()
>> + * is either setting ret to -EFAULT or storing the old value in
>> + * oldval which results in a uninitialized warning at the call site.
>> + */
>> + *oval = oldval;
>>
>> return ret;
>> }
>>
>> I think that's the right thing to do anyway. The conditional is pointless.
>
> Thanks for the analysis.
>
> I am still getting this warning, now from Linus' tree builds.
Yeah. Just noticed that both of us failed to CC the arm folks. :(
Let me send out a proper patch.
Thanks,
tglx
Powered by blists - more mailing lists