From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Zijlstra Subject: Re: [RFC PATCH] lib: Introduce generic __cmpxchg_u64() and use it where needed Date: Thu, 1 Nov 2018 15:59:26 +0100 Message-ID: <20181101145926.GE3178@hirez.programming.kicks-ass.net> References: <1541015538-11382-1-git-send-email-linux@roeck-us.net> <20181031213240.zhh7dfcm47ucuyfl@pburton-laptop> <20181031220253.GA15505@roeck-us.net> <20181031233235.qbedw3pinxcuk7me@pburton-laptop> <4e2438a23d2edf03368950a72ec058d1d299c32e.camel@hammerspace.com> <20181101131846.biyilr2msonljmij@lakrids.cambridge.arm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Trond Myklebust , "linux@roeck-us.net" , "paul.burton@mips.com" , "linux-kernel@vger.kernel.org" , "ralf@linux-mips.org" , "jlayton@kernel.org" , "linuxppc-dev@lists.ozlabs.org" , "bfields@fieldses.org" , "linux-mips@linux-mips.org" , "linux-nfs@vger.kernel.org" , "akpm@linux-foundation.org" , "anna.schumaker@netapp.com" , "jhogan@kernel.org" , "netdev@vger.kernel.org" , "davem@davemloft.net" , "arnd@arndb.de" To: Mark Rutland Return-path: Content-Disposition: inline In-Reply-To: <20181101131846.biyilr2msonljmij@lakrids.cambridge.arm.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: netdev.vger.kernel.org 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).