On Tue, Apr 16, 2019 at 10:13:40AM +0100, Will Deacon wrote: > On Mon, Apr 15, 2019 at 03:01:51PM -0700, Nathan Chancellor wrote: > > On Mon, Apr 15, 2019 at 08:44:36PM +0200, Greg Kroah-Hartman wrote: > > > From: Will Deacon <will.deacon@xxxxxxx> > > [...] > > > > @@ -53,29 +53,29 @@ > > > static inline int > > > arch_futex_atomic_op_inuser(int op, int oparg, int *oval, u32 __user *uaddr) > > > { > > > - int oldval = 0, ret, tmp; > > > + int oldval, ret, tmp; > > > > > > pagefault_disable(); > > > > > > switch (op) { > > > case FUTEX_OP_SET: > > > - __futex_atomic_op("mov %w0, %w4", > > > + __futex_atomic_op("mov %w3, %w4", > > > ret, oldval, uaddr, tmp, oparg); > > > break; > > > case FUTEX_OP_ADD: > > > - __futex_atomic_op("add %w0, %w1, %w4", > > > + __futex_atomic_op("add %w3, %w1, %w4", > > > ret, oldval, uaddr, tmp, oparg); > > > break; > > > case FUTEX_OP_OR: > > > - __futex_atomic_op("orr %w0, %w1, %w4", > > > + __futex_atomic_op("orr %w3, %w1, %w4", > > > ret, oldval, uaddr, tmp, oparg); > > > break; > > > case FUTEX_OP_ANDN: > > > - __futex_atomic_op("and %w0, %w1, %w4", > > > + __futex_atomic_op("and %w3, %w1, %w4", > > > ret, oldval, uaddr, tmp, ~oparg); > > > break; > > > case FUTEX_OP_XOR: > > > - __futex_atomic_op("eor %w0, %w1, %w4", > > > + __futex_atomic_op("eor %w3, %w1, %w4", > > > ret, oldval, uaddr, tmp, oparg); > > > break; > > > default: > > > > > > > > > > This causes a (false) build warning with AOSP's GCC 4.9.4 (which is > > used to build nearly all arm64 Android kernels before 4.14): > > > > CC kernel/futex.o > > ../kernel/futex.c: In function 'do_futex': > > ../kernel/futex.c:1492:17: warning: 'oldval' may be used uninitialized in this function [-Wmaybe-uninitialized] > > return oldval == cmparg; > > ^ > > In file included from ../kernel/futex.c:69:0: > > ../arch/arm64/include/asm/futex.h:56:6: note: 'oldval' was declared here > > int oldval, ret, tmp; > > ^ > > > > The only reason I bring this up is Qualcomm based kernels have a Python > > script that emulates -Werror, meaning this will be fatal for a large > > number of kernels, when this eventually gets merged into them. > > Thanks. Does restoring the initial assignment of 0 suppress the bogus > warning? If so, please could you send a patch on top for stable (assuming > Greg is ok with the simple change for this)? > > Will Yes, it does and I sure can. Greg, let me know if that is okay.