[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20171018225746.GT3521@linux.vnet.ibm.com>
Date: Wed, 18 Oct 2017 15:57:46 -0700
From: "Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
To: Alan Stern <stern@...land.harvard.edu>
Cc: Andrea Parri <parri.andrea@...il.com>,
Will Deacon <will.deacon@....com>, peterz@...radead.org,
boqun.feng@...il.com, npiggin@...il.com, dhowells@...hat.com,
Jade Alglave <j.alglave@....ac.uk>,
Luc Maranget <luc.maranget@...ia.fr>,
Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: Linux-kernel examples for LKMM recipes
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
Powered by blists - more mailing lists