On Thu, Nov 01, 2018 at 01:18:46PM +0000, Mark Rutland wrote:

quoted

My one question (and the reason why I went with cmpxchg() in the first
place) would be about the overflow behaviour for atomic_fetch_inc() and
friends. I believe those functions should be OK on x86, so that when we
overflow the counter, it behaves like an unsigned value and wraps back
around.  Is that the case for all architectures?

i.e. are atomic_t/atomic64_t always guaranteed to behave like u32/u64
on increment?

I could not find any documentation that explicitly stated that they
should.

Peter, Will, I understand that the atomic_t/atomic64_t ops are required
to wrap per 2's-complement. IIUC the refcount code relies on this.

Can you confirm?

There is quite a bit of core code that hard assumes 2s-complement. Not
only for atomics but for any signed integer type. Also see the kernel
using -fno-strict-overflow which implies -fwrapv, which defines signed
overflow to behave like 2s-complement (and rids us of that particular
UB).