Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757246Ab2BCRRI (ORCPT ); Fri, 3 Feb 2012 12:17:08 -0500 Received: from mail-yw0-f46.google.com ([209.85.213.46]:34910 "EHLO mail-yw0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755050Ab2BCRRF convert rfc822-to-8bit (ORCPT ); Fri, 3 Feb 2012 12:17:05 -0500 MIME-Version: 1.0 In-Reply-To: <4F2C0D8A.70103@redhat.com> References: <20120201151918.GC16714@quack.suse.cz> <1328118174.15992.6206.camel@triegel.csb> <1328128874.15992.6430.camel@triegel.csb> <20120201224554.GK2382@linux.vnet.ibm.com> <20120202184209.GD2518@linux.vnet.ibm.com> <20120202193747.GG2518@linux.vnet.ibm.com> <4F2C0D8A.70103@redhat.com> From: Linus Torvalds Date: Fri, 3 Feb 2012 09:16:43 -0800 X-Google-Sender-Auth: TMNNCR2pu_VOVwkV5MAW4O8k9yo Message-ID: Subject: Re: Memory corruption due to word sharing To: Andrew MacLeod Cc: paulmck@linux.vnet.ibm.com, Torvald Riegel , Jan Kara , LKML , linux-ia64@vger.kernel.org, dsterba@suse.cz, ptesarik@suse.cz, rguenther@suse.de, gcc@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2453 Lines: 57 On Fri, Feb 3, 2012 at 8:38 AM, Andrew MacLeod wrote: > > The atomic intrinsics were created for c++11 ?memory model compliance, but I > am certainly open to enhancements that would make them more useful. ? I am > planning some enhancements for 4.8 now, and it sounds like you may have some > suggestions... So we have several atomics we use in the kernel, with the more common being - add (and subtract) and cmpchg of both 'int' and 'long' - add_return (add and return new value) - special cases of the above: dec_and_test (decrement and test result for zero) inc_and_test (decrement and test result for zero) add_negative (add and check if result is negative) The special cases are because older x86 cannot do the generic "add_return" efficiently - it needs xadd - but can do atomic versions that test the end result and give zero or sign information. - atomic_add_unless() - basically an optimized cmpxchg. - atomic bit array operations (bit set, clear, set-and-test, clear-and-test). We do them on "unsigned long" exclusively, and in fact we do them on arrays of unsigned long, ie we have the whole "bts reg,mem" semantics. I'm not sure we really care about the atomic versions for the arrays, so it's possible we only really care about a single long. The only complication with the bit setting is that we have a concept of "set/clear bit with memory barrier before or after the bit" (for locking). We don't do the whole release/acquire thing, though. - compare_xchg_double We also do byte/word atomic increments and decrements, but that' sin the x86 spinlock implementation, so it's not a generic need. We also do the add version in particular as CPU-local optimizations that do not need to be SMP-safe, but do need to be interrupt-safe. On x86, this is just an r-m-w op, on most other architectures it ends up being the usual load-locked/store-conditional. I think that's pretty much it, but maybe I'm missing something. Of course, locking itself tends to be special cases of the above with extra memory barriers, but it's usually hidden in asm for other reasons (the bit-op + barrier being a special case). Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/