Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755392Ab2BFPi7 (ORCPT ); Mon, 6 Feb 2012 10:38:59 -0500 Received: from mx1.redhat.com ([209.132.183.28]:24093 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755300Ab2BFPiz (ORCPT ); Mon, 6 Feb 2012 10:38:55 -0500 Subject: Re: Memory corruption due to word sharing From: Torvald Riegel To: Linus Torvalds Cc: Andrew MacLeod , paulmck@linux.vnet.ibm.com, Jan Kara , LKML , linux-ia64@vger.kernel.org, dsterba@suse.cz, ptesarik@suse.cz, rguenther@suse.de, GCC Patches In-Reply-To: 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> <4F2C329B.2080107@redhat.com> Content-Type: text/plain; charset="UTF-8" Date: Mon, 06 Feb 2012 16:38:03 +0100 Message-ID: <1328542683.13242.311.camel@triegel.csb> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3178 Lines: 74 On Fri, 2012-02-03 at 12:00 -0800, Linus Torvalds wrote: > Of course, it you expose some intrinsic for the whole "ll/sc" model > (and you then turn it into cmpxchg on demand), we could literally > open-code it. > > That is likely the most *flexible* approach for a compiler. I think > pretty much everything the kernel needs (except for cmpxchg_double) > can be very naturally written as a "ll/sc" sequence, and if the > compiler then just does the right thing with peephole optimizations, > that's fine. > > IOW, we don't really need "atomic_add()" or anything like that. If we can do > > do { > val = __load_linked(mem); > val++; > } while (__store_conditional(val, mem)); > > and the compiler just automagically turns that into "lock add" on x86, > that's perfectly fine. > > It might not be too hard, because you really don't need to recognize > very many patterns, and any pattern you don't recognize could be > turned into a cmpxchg loop. > > NOTE NOTE NOTE! The "turned into a cmpxchg loop" is not the true > correct translation of load-linked/store-conditional, since it allows > the memory to be modified as long as it's modified *back* before the > store-conditional, and that actually matters for a few algorithms. But > if you document the fact that it's not a "true" ll/sc (and maybe have > some compile-time way to detect when it isn't), it would be very > flexible. > > Of course, the syntax could be something completely different. Maybe > you'd want to do it as > > __builtin_ll_sc(&var, update-expression, return-expression, > failure-expression) > > rather than an explicit loop. > > But it doesn't sound like the internal gcc model is based on some > generic ll/sc model. No, and I don't think it's beneficial overall to do this. Sure, an LL/SC or CAS loop is universal, but in turn programmers would have to make sure that they hit the patterns that the compiler can actually recognize and turn into the more efficient forms. The custom atomic operations also provide different progress guarantees. While a single CAS/cmpxchg is wait-free, the full loop isn't necessarily. Same for the bit operations. So, I think it makes sense to offer them separately. The split between weak- and strong-progress compare-and-exchange in C++11 is related. > I realize that people have bad memories of the x86 bit instructions, > but especially in their locked form, the fact that they take a few > extra cycles or decode in only one pipeline etc is *not* relevant. > They are small and "fast", because the true cost tends to be not the > instruction cost, but the locking overhead and the cache effects. And the semantics of the operation is known immediately (without trying to recover the actual atomic op from some surrounding cmpxchg loop). That allows potential optimizations like combining (but I'm not a HW expert, so I don't know whether HW actually does this internally). Torvald -- 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/