From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932685AbcDNP2J (ORCPT ); Thu, 14 Apr 2016 11:28:09 -0400 Received: from e36.co.us.ibm.com ([32.97.110.154]:55294 "EHLO e36.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932497AbcDNP2A (ORCPT ); Thu, 14 Apr 2016 11:28:00 -0400 X-IBM-Helo: d03dlp03.boulder.ibm.com X-IBM-MailFrom: paulmck@linux.vnet.ibm.com X-IBM-RcptTo: linux-kernel@vger.kernel.org Date: Thu, 14 Apr 2016 08:28:15 -0700 From: "Paul E. McKenney" To: Steven Rostedt Cc: linux-kernel@vger.kernel.org, mingo@kernel.org, jiangshanlai@gmail.com, dipankar@in.ibm.com, akpm@linux-foundation.org, mathieu.desnoyers@efficios.com, josh@joshtriplett.org, tglx@linutronix.de, peterz@infradead.org, dhowells@redhat.com, edumazet@google.com, dvhart@linux.intel.com, fweisbec@gmail.com, oleg@redhat.com, bobby.prani@gmail.com Subject: Re: [PATCH memory-barriers.txt 1/7] documentation: Clarify relationship of barrier() to control dependencies Message-ID: <20160414152815.GF3755@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20160412155228.GA27257@linux.vnet.ibm.com> <1460476375-27803-1-git-send-email-paulmck@linux.vnet.ibm.com> <20160413235614.3517e030@grimm.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160413235614.3517e030@grimm.local.home> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-MML: disable X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16041415-0021-0000-0000-0000389D4899 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 13, 2016 at 11:56:14PM -0400, Steven Rostedt wrote: > On Tue, 12 Apr 2016 08:52:49 -0700 > "Paul E. McKenney" wrote: > > > The current documentation claims that the compiler ignores barrier(), > > which is not the case. Instead, the compiler carefully pays attention > > to barrier(), but in a creative way that still manages to destroy > > the control dependency. This commit sets the story straight. > > > > Reported-by: Mathieu Desnoyers > > Signed-off-by: Paul E. McKenney > > --- > > Documentation/memory-barriers.txt | 7 ++++--- > > 1 file changed, 4 insertions(+), 3 deletions(-) > > > > diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt > > index 3729cbe60e41..ec1289042396 100644 > > --- a/Documentation/memory-barriers.txt > > +++ b/Documentation/memory-barriers.txt > > @@ -813,9 +813,10 @@ In summary: > > the same variable, then those stores must be ordered, either by > > preceding both of them with smp_mb() or by using smp_store_release() > > to carry out the stores. Please note that it is -not- sufficient > > - to use barrier() at beginning of each leg of the "if" statement, > > - as optimizing compilers do not necessarily respect barrier() > > - in this case. > > + to use barrier() at beginning of each leg of the "if" statement > > + because, as shown by the example above, optimizing compilers can > > + destroy the control dependency while respecting the letter of the > > + barrier() law. > > Which country has the jurisdiction over this barrier() law? > > What about "the letter of the barrier() rules"? >>From https://en.wikipedia.org/wiki/Letter_and_spirit_of_the_law: "Law" originally referred to legislative statute, but in the idiom may refer to any kind of rule. So I believe that the current wording respects the spirit of that idiom. ;-) Thanx, Paul