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: > > > 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@xxxxxxxxxxxxxxx
