From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754664AbcFGMlv (ORCPT ); Tue, 7 Jun 2016 08:41:51 -0400 Received: from out2-smtp.messagingengine.com ([66.111.4.26]:33792 "EHLO out2-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752637AbcFGMlu (ORCPT ); Tue, 7 Jun 2016 08:41:50 -0400 X-Sasl-enc: SoFNCAVI7RfUAJmjR67ooRAi9QaUBs/vFPWj0FMVkz0k 1465303308 Subject: Re: [RFC][PATCH 1/3] locking: Introduce smp_acquire__after_ctrl_dep To: Peter Zijlstra , "Paul E. McKenney" References: <5745C2CA.4040003@hpe.com> <20160525155747.GE3789@linux.vnet.ibm.com> <57514B6E.6010001@synopsys.com> <20160603093834.GI3190@twins.programming.kicks-ass.net> <20160603120827.GT5231@linux.vnet.ibm.com> <20160603122310.GM3190@twins.programming.kicks-ass.net> <20160603133238.GV5231@linux.vnet.ibm.com> <20160603134552.GL9915@arm.com> <20160604152929.GZ5231@linux.vnet.ibm.com> <20160606172824.GA10383@linux.vnet.ibm.com> <20160607071508.GL30909@twins.programming.kicks-ass.net> Cc: Will Deacon , Vineet Gupta , Waiman Long , linux-kernel@vger.kernel.org, torvalds@linux-foundation.org, manfred@colorfullife.com, dave@stgolabs.net, boqun.feng@gmail.com, tj@kernel.org, pablo@netfilter.org, kaber@trash.net, davem@davemloft.net, oleg@redhat.com, netfilter-devel@vger.kernel.org, sasha.levin@oracle.com, hofrat@osadl.org From: Hannes Frederic Sowa Message-ID: Date: Tue, 7 Jun 2016 14:41:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <20160607071508.GL30909@twins.programming.kicks-ass.net> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 07.06.2016 09:15, Peter Zijlstra wrote: >> >> diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt >> index 147ae8ec836f..a4d0a99de04d 100644 >> --- a/Documentation/memory-barriers.txt >> +++ b/Documentation/memory-barriers.txt >> @@ -806,6 +806,41 @@ out-guess your code. More generally, although READ_ONCE() does force >> the compiler to actually emit code for a given load, it does not force >> the compiler to use the results. >> >> +In addition, control dependencies apply only to the then-clause and >> +else-clause of the if-statement in question. In particular, it does >> +not necessarily apply to code following the if-statement: >> + >> + q = READ_ONCE(a); >> + if (q) { >> + WRITE_ONCE(b, p); >> + } else { >> + WRITE_ONCE(b, r); >> + } >> + WRITE_ONCE(c, 1); /* BUG: No ordering against the read from "a". */ >> + >> +It is tempting to argue that there in fact is ordering because the >> +compiler cannot reorder volatile accesses and also cannot reorder >> +the writes to "b" with the condition. Unfortunately for this line >> +of reasoning, the compiler might compile the two writes to "b" as >> +conditional-move instructions, as in this fanciful pseudo-assembly >> +language: I wonder if we already guarantee by kernel compiler settings that this behavior is not allowed by at least gcc. We unconditionally set --param allow-store-data-races=0 which should actually prevent gcc from generating such conditional stores. Am I seeing this correct here? Thanks, Hannes