On Tue, 2017-07-11 at 12:10:54 UTC, Michael Ellerman wrote: > 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") > Cc: sta...@vger.kernel.org # v3.4 > Noticed-by: Linus Torvalds <torva...@linux-foundation.org> > Signed-off-by: Michael Ellerman <m...@ellerman.id.au>
Applied to powerpc fixes. https://git.kernel.org/powerpc/c/01e6a61aceb82e13bec29502a8eb70 cheers