From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Paul E. McKenney" Subject: Re: [RFC PATCH] lib: Introduce generic __cmpxchg_u64() and use it where needed Date: Thu, 1 Nov 2018 10:43:33 -0700 Message-ID: <20181101174333.GV4170@linux.ibm.com> References: <20181031213240.zhh7dfcm47ucuyfl@pburton-laptop> <20181031220253.GA15505@roeck-us.net> <20181031233235.qbedw3pinxcuk7me@pburton-laptop> <4e2438a23d2edf03368950a72ec058d1d299c32e.camel@hammerspace.com> <20181101131846.biyilr2msonljmij@lakrids.cambridge.arm.com> <20181101145926.GE3178@hirez.programming.kicks-ass.net> <20181101163212.GF3159@hirez.programming.kicks-ass.net> <20181101171432.GH3178@hirez.programming.kicks-ass.net> Reply-To: paulmck@linux.ibm.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Eric Dumazet , Trond Myklebust , "mark.rutland@arm.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@roeck-us.net" , "linux-nfs@vger.kernel.org" , "akpm@linux-foundation.org" , "will.deacon@arm.com" , "boqun.feng@gmail.com" , "paul.burton@mips.com" , "anna.schumaker@netapp.com" Return-path: Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:45534 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726920AbeKBCrk (ORCPT ); Thu, 1 Nov 2018 22:47:40 -0400 Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id wA1Hb8aX067939 for ; Thu, 1 Nov 2018 13:43:43 -0400 Received: from e16.ny.us.ibm.com (e16.ny.us.ibm.com [129.33.205.206]) by mx0a-001b2d01.pphosted.com with ESMTP id 2ng61s889m-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 01 Nov 2018 13:43:43 -0400 Received: from localhost by e16.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 1 Nov 2018 17:43:42 -0000 Content-Disposition: inline In-Reply-To: <20181101171432.GH3178@hirez.programming.kicks-ass.net> Sender: netdev-owner@vger.kernel.org List-ID: On Thu, Nov 01, 2018 at 06:14:32PM +0100, Peter Zijlstra wrote: > On Thu, Nov 01, 2018 at 09:59:38AM -0700, Eric Dumazet wrote: > > On 11/01/2018 09:32 AM, Peter Zijlstra wrote: > > > > >> 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. > > > > > > I myself am certainly relying on it. > > > > Could we get uatomic_t support maybe ? > > Whatever for; it'd be the exact identical same functions as for > atomic_t, except for a giant amount of code duplication to deal with the > new type. > > That is; today we merged a bunch of scripts that generates most of > atomic*_t, so we could probably script uatomic*_t wrappers with minimal > effort, but it would add several thousand lines of code to each compile > for absolutely no reason what so ever. > > > This reminds me of this sooooo silly patch :/ > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=adb03115f4590baa280ddc440a8eff08a6be0cb7 > > Yes, that's stupid. UBSAN is just wrong there. It would be good for UBSAN to treat atomic operations as guaranteed 2s complement with no UB for signed integer overflow. After all, if even the C standard is willing to do this... Ah, but don't we disable interrupts and fall back to normal arithmetic for UP systems? Hmmm... We do so for atomic_add_return() even on x86, it turns out: static __always_inline int arch_atomic_add_return(int i, atomic_t *v) { return i + xadd(&v->counter, i); } So UBSAN actually did have a point. :-( Thanx, Paul