On Thu, 2018-11-01 at 15:59 +0100, Peter Zijlstra wrote:

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

quoted

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).

Fair enough, but there have also been bugfixes to explicitly fix unsafe
C standards assumptions for signed integers. See, for instance commit
5a581b367b5d "jiffies: Avoid undefined behavior from signed overflow"
from Paul McKenney.

Anyhow, if the atomic maintainers are willing to stand up and state for
the record that the atomic counters are guaranteed to wrap modulo 2^n
just like unsigned integers, then I'm happy to take Paul's patch.

-- 
Trond Myklebust
Linux NFS client maintainer, Hammerspace
trond.myklebust@hammerspace.com