From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751519AbdJRU2M (ORCPT ); Wed, 18 Oct 2017 16:28:12 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:36718 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751045AbdJRU2K (ORCPT ); Wed, 18 Oct 2017 16:28:10 -0400 Date: Wed, 18 Oct 2017 13:28:05 -0700 From: "Paul E. McKenney" To: Alan Stern Cc: Andrea Parri , Will Deacon , peterz@infradead.org, boqun.feng@gmail.com, npiggin@gmail.com, dhowells@redhat.com, Jade Alglave , Luc Maranget , Kernel development list Subject: Re: Linux-kernel examples for LKMM recipes Reply-To: paulmck@linux.vnet.ibm.com References: <20171017215521.GB3521@linux.vnet.ibm.com> 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-GCONF: 00 x-cbid: 17101820-0040-0000-0000-000003B4AEEF X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007915; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000237; SDB=6.00933052; UDB=6.00469926; IPR=6.00713342; BA=6.00005648; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00017596; XFM=3.00000015; UTC=2017-10-18 20:28:09 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17101820-0041-0000-0000-000007A9B658 Message-Id: <20171018202805.GP3521@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-10-18_07:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710180283 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 18, 2017 at 10:43:42AM -0400, Alan Stern wrote: > On Tue, 17 Oct 2017, Paul E. McKenney wrote: > > > > > > > b. Compilers are permitted to use the "as-if" rule. > > > > > > That is, a compiler can emit whatever code it likes, > > > > > > as long as the results appear just as if the compiler > > > > > > had followed all the relevant rules. To see this, > > > > > > compiler with a high level of optimization and run > > > > > > the debugger on the resulting binary. > > > > > > > > > > You might omit the last sentence. Furthermore, if the accesses don't > > > > > use READ_ONCE/WRITE_ONCE then the code might not get the same result as > > > > > if it had executed in order (even for a single variable!), and if you > > > > > do use READ_ONCE/WRITE_ONCE then the compiler can't emit whatever code > > > > > it likes. > > > > > > > > Ah, I omitted an important qualifier: > > > > > > > > b. Compilers are permitted to use the "as-if" rule. That is, > > > > a compiler can emit whatever code it likes, as long as > > > > the results of a single-threaded execution appear just > > > > as if the compiler had followed all the relevant rules. > > > > To see this, compile with a high level of optimization > > > > and run the debugger on the resulting binary. > > > > > > That's okay for the single-CPU case. I don't think it covers the > > > multiple-CPU single-variable case correctly, though. If you don't use > > > READ_ONCE or WRITE_ONCE, isn't the compiler allowed to tear the loads > > > and stores? And won't that potentially cause the end result to be > > > different from what you would get if the code had appeared to execute > > > in order? > > > > Ah, good point, I need yet another qualifier. How about the following? > > > > b. Compilers are permitted to use the "as-if" rule. That is, > > a compiler can emit whatever code it likes for normal > > accesses, as long as the results of a single-threaded > > execution appear just as if the compiler had followed > > all the relevant rules. To see this, compile with a > > high level of optimization and run the debugger on the > > resulting binary. > > > > I added "for normal accesses", which excludes READ_ONCE(), WRITE_ONCE(), > > and atomics. This, in conjunction with the previously added > > "single-threaded execution" means that yes, the compiler is permitted > > to tear normal loads and stores. The reason is that a single-threaded > > run could not tell the difference. Interrupt handlers or multiple > > threads are required to detect load/store tearing. > > > > So, what am I still missing? ;-) > > Well, you could explicitly mention that in the multi-thread case, this > means all accesses to the shared variable had better use READ_ONCE() or > WRITE_ONCE(). Like this? Thanx, Paul ------------------------------------------------------------------------ d. If there are multiple CPUs, accesses to shared variables should use READ_ONCE() and WRITE_ONCE() or stronger to prevent load/store tearing, load/store fusing, and invented loads and stores. There are exceptions to this rule, for example: i. When there is no possibility of a given shared variable being updated, for example, while holding the update-side lock, reads from that variable need not use READ_ONCE(). ii. When there is no possibility of a given shared variable being either read or updated, for example, when running during early boot, reads from that variable need not use READ_ONCE() and writes to that variable need not use WRITE_ONCE().