From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751457AbcEYS7w (ORCPT ); Wed, 25 May 2016 14:59:52 -0400 Received: from e18.ny.us.ibm.com ([129.33.205.208]:44926 "EHLO e18.ny.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751119AbcEYS7t (ORCPT ); Wed, 25 May 2016 14:59:49 -0400 X-IBM-Helo: d01dlp01.pok.ibm.com X-IBM-MailFrom: paulmck@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org;netfilter-devel@vger.kernel.org Date: Wed, 25 May 2016 11:59:45 -0700 From: "Paul E. McKenney" To: Linus Torvalds Cc: Peter Zijlstra , Waiman Long , Linux Kernel Mailing List , Manfred Spraul , Davidlohr Bueso , Will Deacon , Boqun Feng , Tejun Heo , Pablo Neira Ayuso , Patrick McHardy , David Miller , Oleg Nesterov , netfilter-devel@vger.kernel.org, Sasha Levin , hofrat@osadl.org Subject: Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep Message-ID: <20160525185945.GH3789@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20160524142723.178148277@infradead.org> <20160524143649.523586684@infradead.org> <57451581.6000700@hpe.com> <20160525045329.GQ4148@linux.vnet.ibm.com> <5745C2CA.4040003@hpe.com> <20160525155747.GE3789@linux.vnet.ibm.com> <20160525162829.GX3193@twins.programming.kicks-ass.net> 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-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16052518-0045-0000-0000-0000044A9757 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 25, 2016 at 09:54:55AM -0700, Linus Torvalds wrote: > On Wed, May 25, 2016 at 9:28 AM, Peter Zijlstra wrote: > > > > I would consider any architecture that allows speculative stores as > > broken. They are values out of thin air and would make any kind of > > concurrency extremely 'interesting'. > > It's worth noting that the same is true of compilers too. You will > find compiler people who argue that speculative stores are valid > because the spec doesn't explicitly forbid them. Same is true of > compiler-generated value speculation. Thankfully, this has improved. There was a time when compiler writers were happy to overwrite adjacent variables and fix them up later, believe it or not. Not so good if the variables are shared variables, possibly protected by different locks. Most compiler writers now understand that this sort of thing is not permitted, and recent versions of the standard explicitly forbid it. But there are still any number of optimizations that can cause trouble for concurrent code. Common subexpresssion elimination, for example... Which is one reason for my heavy use of READ_ONCE() and WRITE_ONCE(). > Both are cases of "yeah, the C standard may not explicitly disallow > it, but sanity in a threaded environment does". Sadly, I've seen > compiler people who dismiss "sanity" as an argument, since that also > isn't defined in the C standard. There are people who think that paper > is the most precious resource in the universe. > > I'm not actually aware of anybody doing speculative stores or value > speculation in a compiler we care about, but if those kinds of things > are the kinds of things where we'd just go "that compiler is shit" and > not use it (possibly with a command line option to disable the > particular broken optimization, like we do for the broken type-based > aliasing and some other code generation things that just don't work in > the kernel). > > So we definitely have the option to just say "theory is just theory". > We'll never make design decisions based on insane things being > possible in theory, whether it be crazy architectures or crazy > compilers. There has been some discussion of adding "-std=kernel" to tell the compiler to follow Linux-kernel rules, but not sure whether this is really going anywhere. Thanx, Paul