From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932582AbbFQPnA (ORCPT ); Wed, 17 Jun 2015 11:43:00 -0400 Received: from e31.co.us.ibm.com ([32.97.110.149]:43230 "EHLO e31.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755533AbbFQPmv (ORCPT ); Wed, 17 Jun 2015 11:42:51 -0400 X-Helo: d03dlp03.boulder.ibm.com X-MailFrom: paulmck@linux.vnet.ibm.com X-RcptTo: linux-kernel@vger.kernel.org Date: Wed, 17 Jun 2015 08:42:45 -0700 From: "Paul E. McKenney" To: Peter Zijlstra Cc: umgwanakikbuti@gmail.com, mingo@elte.hu, ktkhai@parallels.com, rostedt@goodmis.org, tglx@linutronix.de, juri.lelli@gmail.com, pang.xunlei@linaro.org, oleg@redhat.com, wanpeng.li@linux.intel.com, linux-kernel@vger.kernel.org, Al Viro , Linus Torvalds Subject: Re: [PATCH 11/18] seqcount: Introduce raw_write_seqcount_barrier() Message-ID: <20150617154245.GB3913@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20150611124636.448700267@infradead.org> <20150611124743.374180021@infradead.org> <20150611153341.GK3913@linux.vnet.ibm.com> <20150611214557.GA4249@linux.vnet.ibm.com> <20150617122924.GP3644@twins.programming.kicks-ass.net> <20150617145712.GZ3913@linux.vnet.ibm.com> <20150617151109.GD19282@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150617151109.GD19282@twins.programming.kicks-ass.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 15061715-8236-0000-0000-00000C6C01CE Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Jun 17, 2015 at 05:11:09PM +0200, Peter Zijlstra wrote: > On Wed, Jun 17, 2015 at 07:57:12AM -0700, Paul E. McKenney wrote: > > On Wed, Jun 17, 2015 at 02:29:24PM +0200, Peter Zijlstra wrote: > > > I did leave off the READ/WRITE ONCE stuff, because I could not come up > > > with a scenario where it makes a difference -- I appreciate paranoia, > > > but I also think we should not overdo the thing. > > > > I can only conclude that you have not read this document: > > > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4455.html > > This would be correct. > > > Specifically, please keep in mind that unless you mark either the variable > > or the memory access, the compiler is within its rights to assume that > > there are no concurrent accesses to that variable. For but one example, > > if you do a normal store to a given variable, then the compiler is > > within its rights to use that variable as temporary storage prior to > > that store. And yes, you can reasonably argue that no sane compiler > > would store something else to s->sequence given that it could free up > > a register by storing the incremented value, but the fact remains that > > you have given it permission to do so if it wants. > > Argh *grmbl*, that's bloody insane! You expected me to argue with that statement? ;-) > So I get the re-loading, I get the tearing, but this random intermittent > values (somewhat related to stores out of thin air) is completely > bonkers. > > I would very much prefer a compiler switch that instructs the compiler > to not do bloody stupid things like this instead of marking every other > load/store in the kernel with volatile. I would of course be good with such a compiler switch, though my earlier attempts to negotiate one were unsuccessful. But I don't believe that we discussed a switch to specifically prohibit only use of to-be-stored-into variables as temporary scratch space. The trick is finding restrictions that are useful, but that don't imply -O0. Any GCC or LLVM folks on the list? > Note that if GCC were to actually do something like this, the kernel > would already be broken, because I'm very sure we did not consider/audit > it for this. An accident waiting to happen, given that both GCC and the Linux kernel are moving targets. :-/ Thanx, Paul