From: Al Viro <viro@zeniv.linux.org.uk>
To: James Bottomley <James.Bottomley@hansenpartnership.com>
Cc: paulmck@linux.ibm.com, Eric Biggers <ebiggers@kernel.org>,
"Tobin C. Harding" <me@tobin.cc>,
linux-fsdevel@vger.kernel.org
Subject: Re: dcache locking question
Date: Sun, 17 Mar 2019 03:06:39 +0000 [thread overview]
Message-ID: <20190317030634.GG2217@ZenIV.linux.org.uk> (raw)
In-Reply-To: <1552789220.6551.13.camel@HansenPartnership.com>
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 **?
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.
next prev parent reply other threads:[~2019-03-17 3:07 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-14 22:56 dcache locking question Tobin C. Harding
2019-03-14 23:09 ` Matthew Wilcox
2019-03-15 1:38 ` Tobin C. Harding
2019-03-14 23:19 ` Tobin C. Harding
2019-03-15 1:50 ` Al Viro
2019-03-15 17:38 ` Eric Biggers
2019-03-15 18:54 ` Al Viro
2019-03-16 22:31 ` Paul E. McKenney
2019-03-17 0:18 ` Al Viro
2019-03-17 0:50 ` Paul E. McKenney
2019-03-17 2:20 ` James Bottomley
2019-03-17 3:06 ` Al Viro [this message]
2019-03-17 4:23 ` James Bottomley
2019-03-18 0:35 ` Paul E. McKenney
2019-03-18 16:26 ` James Bottomley
2019-03-18 17:11 ` Paul E. McKenney
2019-03-19 15:45 ` Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190317030634.GG2217@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=James.Bottomley@hansenpartnership.com \
--cc=ebiggers@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=me@tobin.cc \
--cc=paulmck@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.