From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751840AbdF3X2Q (ORCPT ); Fri, 30 Jun 2017 19:28:16 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:60232 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751581AbdF3X2P (ORCPT ); Fri, 30 Jun 2017 19:28:15 -0400 Date: Fri, 30 Jun 2017 16:28:10 -0700 From: "Paul E. McKenney" To: linux-kernel@vger.kernel.org Cc: ldr709@gmail.com, dhowells@redhat.com, will.deacon@arm.com, peterz@infradead.org, corbet@lwn.net, stern@rowland.harvard.edu, parri.andrea@gmail.com, j.alglave@ucl.ac.uk, luc.maranget@inria.fr Subject: [PATCH] doc: Update memory-barriers.txt for read-to-write dependencies Reply-To: paulmck@linux.vnet.ibm.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 17063023-0036-0000-0000-0000023D0D11 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007300; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000214; SDB=6.00881074; UDB=6.00439291; IPR=6.00661227; BA=6.00005448; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00016027; XFM=3.00000015; UTC=2017-06-30 23:28:13 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17063023-0037-0000-0000-000040EE8670 Message-Id: <20170630232810.GA28036@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-06-30_15:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706300360 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The memory-barriers.txt document contains an obsolete passage stating that smp_read_barrier_depends() is required to force ordering for read-to-write dependencies. We now know that this is not required, even for DEC Alpha. This commit therefore updates this passage to state that read-to-write dependencies are respected even without smp_read_barrier_depends(). Reported-by: Lance Roy Signed-off-by: Paul E. McKenney Cc: David Howells Cc: Will Deacon Cc: Peter Zijlstra Cc: Jonathan Corbet Cc: Alan Stern Cc: Andrea Parri Cc: Jade Alglave Cc: Luc Maranget diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 9d5e0f853f08..a8a91b9d5a1b 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -594,7 +594,10 @@ between the address load and the data load: This enforces the occurrence of one of the two implications, and prevents the third possibility from arising. -A data-dependency barrier must also order against dependent writes: +A data-dependency barrier is not required to order dependent writes +because the CPUs that the Linux kernel supports don't do writes until +they are certain (1) that the write will actually happen, (2) of the +location of the write, and (3) of the value to be written. CPU 1 CPU 2 =============== =============== @@ -603,19 +606,19 @@ A data-dependency barrier must also order against dependent writes: WRITE_ONCE(P, &B); Q = READ_ONCE(P); - *Q = 5; -The data-dependency barrier must order the read into Q with the store -into *Q. This prohibits this outcome: +Therefore, no data-dependency barrier is required to order the read into +Q with the store into *Q. In other words, this outcome is prohibited, +even without a data-dependency barrier: (Q == &B) && (B == 4) Please note that this pattern should be rare. After all, the whole point of dependency ordering is to -prevent- writes to the data structure, along with the expensive cache misses associated with those writes. This pattern -can be used to record rare error conditions and the like, and the ordering -prevents such records from being lost. +can be used to record rare error conditions and the like, and the CPUs' +naturally occurring ordering prevents such records from being lost. [!] Note that this extremely counterintuitive situation arises most easily on