Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933206Ab2BBTh5 (ORCPT ); Thu, 2 Feb 2012 14:37:57 -0500 Received: from e39.co.us.ibm.com ([32.97.110.160]:58498 "EHLO e39.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932137Ab2BBThy (ORCPT ); Thu, 2 Feb 2012 14:37:54 -0500 Date: Thu, 2 Feb 2012 11:37:47 -0800 From: "Paul E. McKenney" To: Linus Torvalds Cc: Torvald Riegel , Jan Kara , LKML , linux-ia64@vger.kernel.org, dsterba@suse.cz, ptesarik@suse.cz, rguenther@suse.de, gcc@gcc.gnu.org Subject: Re: Memory corruption due to word sharing Message-ID: <20120202193747.GG2518@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Content-Scanned: Fidelis XPS MAILER x-cbid: 12020219-4242-0000-0000-000000AC8706 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2760 Lines: 67 On Thu, Feb 02, 2012 at 11:08:25AM -0800, Linus Torvalds wrote: > On Thu, Feb 2, 2012 at 10:42 AM, Paul E. McKenney > wrote: > >> > >> SMP-atomic or percpu atomic? Or both? > > > > Only SMP-atomic. > > And I assume that since the compiler does them, that would now make it > impossible for us to gather a list of all the 'lock' prefixes so that > we can undo them if it turns out that we are running on a UP machine. > > When we do SMP operations, we don't just add a "lock" prefix to it. We do this: > > #define LOCK_PREFIX_HERE \ > ".section .smp_locks,\"a\"\n" \ > ".balign 4\n" \ > ".long 671f - .\n" /* offset */ \ > ".previous\n" \ > "671:" > > #define LOCK_PREFIX LOCK_PREFIX_HERE "\n\tlock; " > > and I'm sure you know that, but I'm not sure the gcc people realize > the kinds of games we play to make things work better. > > Sure, "everything will be SMP" some day, but running UP kernels is > likely still going to remain a good idea in virtualized environments, > for example. And having to make it a compile-time option is *not* a > good idea. > > So compiler intrisics are often *worse* than doing it by hand for us > for all these kinds of reasons. They aren't generally geared towards > the very specialized needs that a kernel has. > > Of course, maybe even user space would want some kind of way to > automatically strip 'lock' prefixes from a binary, so maybe the > compiler would have some kind of support like this too. > > (And no, disassembling the binary in order to find lock prefixes is > *not* the answer, at least not for the kernel) So if the gcc guys want the Linux kernel to use their atomics, they must give it some useful way of finding all the lock prefixes on x86. Should be a fun conversation. ;-) > >> We need both variants in the kernel. If the compiler generates one of > >> them for us, that doesn't really much help. > > > > I must admit that the non-x86 per-CPU atomics are, ummm, "interesting". > > Most non-x86 cpu's would probably be better off treating them the same > as smp-atomics (load-locked + store-conditional), but right now we > have this insane generic infrastructure for having versions that are > irq-safe by disabling interrupts etc. Ugh. Mainly because nobody > really is willing to work on and fix up the 25 architectures that > really don't matter. Again, fair point! Thanx, Paul -- 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/