Re: dcache locking question

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Sun, 2019-03-17 at 03:06 +0000, Al Viro wrote:
> On Sat, Mar 16, 2019 at 07:20:20PM -0700, James Bottomley wrote:
> > On Sat, 2019-03-16 at 17:50 -0700, Paul E. McKenney wrote:
> > [...]
> > >  I -have- seen stores of constant values be torn, but not stores
> > > of runtime-variable values and not loads.  Still, such tearing is
> > > permitted, and including the READ_ONCE() is making it easier for
> > > things like thread sanitizers.  In addition, the READ_ONCE()
> > > makes it clear that the value being loaded is unstable, which can
> > > be useful documentation.
> > 
> > Um, just so I'm clear, because this assumption permeates all our
> > code: load or store tearing can never occur if we're doing load or
> > store of a 32 bit value which is naturally aligned.  Where
> > naturally aligned is within the gift of the CPU to determine but
> > which the compiler or kernel will always ensure for us unless we
> > pack the structure or deliberately misalign the allocation.
> 
> Wait a sec; are there any 64bit architectures where the same is not
> guaranteed for dereferencing properly aligned void **?

Yes, naturally alligned void * dereference shouldn't tear either.  I
was just using 32 bit as my example because 64 bit accesses will tear
on 32 bit architectures but 64 bit naturally aligned accesses shouldn't
tear on 64 bit architectures.  However, since we can't guarantee the 64
bitness of the architecture 32 bit or void * is our gold standard for
not tearing.

James


> If that's the case, I can think of quite a few places that are rather
> dubious, and I don't see how READ_ONCE() could help in those - e.g.
> if an architecture only has 32bit loads, rcu list traversals are
> not going to be doable without one hell of an extra headache.
>