Patch "powerpc/64: Fix atomic64_inc_not_zero() to return an int" has been added to the 3.18-stable tree

Patch "powerpc/64: Fix atomic64_inc_not_zero() to return an int" has been added to the 3.18-stable tree

[gregkh]

This is a note to let you know that I've just added the patch titled

    powerpc/64: Fix atomic64_inc_not_zero() to return an int

to the 3.18-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     powerpc-64-fix-atomic64_inc_not_zero-to-return-an-int.patch
and it can be found in the queue-3.18 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


>From 01e6a61aceb82e13bec29502a8eb70d9574f97ad Mon Sep 17 00:00:00 2001
From: Michael Ellerman <mpe@ellerman.id.au>
Date: Tue, 11 Jul 2017 22:10:54 +1000
Subject: powerpc/64: Fix atomic64_inc_not_zero() to return an int

From: Michael Ellerman <mpe@ellerman.id.au>

commit 01e6a61aceb82e13bec29502a8eb70d9574f97ad upstream.

Although it's not documented anywhere, there is an expectation that
atomic64_inc_not_zero() returns a result which fits in an int. This is
the behaviour implemented on all arches except powerpc.

This has caused at least one bug in practice, in the percpu-refcount
code, where the long result from our atomic64_inc_not_zero() was
truncated to an int leading to lost references and stuck systems. That
was worked around in that code in commit 966d2b04e070 ("percpu-refcount:
fix reference leak during percpu-atomic transition").

To the best of my grepping abilities there are no other callers
in-tree which truncate the value, but we should fix it anyway. Because
the breakage is subtle and potentially very harmful I'm also tagging
it for stable.

Code generation is largely unaffected because in most cases the
callers are just using the result for a test anyway. In particular the
case of fget() that was mentioned in commit a6cf7ed5119f
("powerpc/atomic: Implement atomic*_inc_not_zero") generates exactly
the same code.

Fixes: a6cf7ed5119f ("powerpc/atomic: Implement atomic*_inc_not_zero")
Noticed-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

---
 arch/powerpc/include/asm/atomic.h |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/arch/powerpc/include/asm/atomic.h
+++ b/arch/powerpc/include/asm/atomic.h
@@ -453,7 +453,7 @@ static __inline__ int atomic64_add_unles
  * Atomically increments @v by 1, so long as @v is non-zero.
  * Returns non-zero if @v was non-zero, and zero otherwise.
  */
-static __inline__ long atomic64_inc_not_zero(atomic64_t *v)
+static __inline__ int atomic64_inc_not_zero(atomic64_t *v)
 {
 	long t1, t2;
 
@@ -472,7 +472,7 @@ static __inline__ long atomic64_inc_not_
 	: "r" (&v->counter)
 	: "cc", "xer", "memory");
 
-	return t1;
+	return t1 != 0;
 }
 
 #endif /* __powerpc64__ */


Patches currently in stable-queue which might be from mpe@ellerman.id.au are

queue-3.18/powerpc-asm-mark-cr0-as-clobbered-in-mftb.patch
queue-3.18/powerpc-fix-emulation-of-mfocrf-in-emulate_step.patch
queue-3.18/powerpc-64-fix-atomic64_inc_not_zero-to-return-an-int.patch
queue-3.18/powerpc-fix-emulation-of-mcrf-in-emulate_step.patch