From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751060AbdJRW5w (ORCPT ); Wed, 18 Oct 2017 18:57:52 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:44336 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750829AbdJRW5v (ORCPT ); Wed, 18 Oct 2017 18:57:51 -0400 Date: Wed, 18 Oct 2017 15:57:46 -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: <20171018202805.GP3521@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: 17101822-0040-0000-0000-000003B4B8D3 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007916; HX=3.00000241; KW=3.00000007; PH=3.00000004; SC=3.00000237; SDB=6.00933102; UDB=6.00469956; IPR=6.00713391; BA=6.00005649; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00017597; XFM=3.00000015; UTC=2017-10-18 22:57:49 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17101822-0041-0000-0000-000007A9C04F Message-Id: <20171018225746.GT3521@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-10-18_08:,, 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-1710180315 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 18, 2017 at 05:18:37PM -0400, Alan Stern wrote: > On Wed, 18 Oct 2017, Paul E. McKenney wrote: > > > > 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(). > > Yeah, except that you mean being read or updated by another thread. Good point, added that qualifier. Thanx, Paul