From: Chris Snook <csnook@redhat.com>
To: paulmck@linux.vnet.ibm.com
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
torvalds@linux-foundation.org, netdev@vger.kernel.org,
akpm@linux-foundation.org, ak@suse.de, heiko.carstens@de.ibm.com,
davem@davemloft.net, schwidefsky@de.ibm.com,
wensong@linux-vs.org, horms@verge.net.au, wjiang@resilience.com,
cfriesen@nortel.com, zlynx@acm.org, rpjday@mindspring.com,
jesper.juhl@gmail.com
Subject: Re: [PATCH 1/24] make atomic_read() behave consistently on alpha
Date: Thu, 09 Aug 2007 15:24:40 -0400 [thread overview]
Message-ID: <46BB69F8.5000502@redhat.com> (raw)
In-Reply-To: <20070809184531.GH8424@linux.vnet.ibm.com>
Paul E. McKenney wrote:
> On Thu, Aug 09, 2007 at 02:13:52PM -0400, Chris Snook wrote:
>> Paul E. McKenney wrote:
>>> On Thu, Aug 09, 2007 at 01:14:35PM -0400, Chris Snook wrote:
>>>> If you're depending on volatile writes
>>>> being visible to other CPUs, you're screwed either way, because the CPU
>>>> can hold that data in cache as long as it wants before it writes it to
>>>> memory. When this finally does happen, it will happen atomically, which
>>>> is all that atomic_set guarantees. If you need to guarantee that the
>>>> value is written to memory at a particular time in your execution
>>>> sequence, you either have to read it from memory to force the compiler to
>>>> store it first (and a volatile cast in atomic_read will suffice for this)
>>>> or you have to use LOCK_PREFIX instructions which will invalidate remote
>>>> cache lines containing the same variable. This patch doesn't change
>>>> either of these cases.
>>> The case that it -can- change is interactions with interrupt handlers.
>>> And NMI/SMI handlers, for that matter.
>> You have a point here, but only if you can guarantee that the interrupt
>> handler is running on a processor sharing the cache that has the
>> not-yet-written volatile value. That implies a strictly non-SMP
>> architecture. At the moment, none of those have volatile in their
>> declaration of atomic_t, so this patch can't break any of them.
>
> This can also happen when using per-CPU variables. And there are a
> number of per-CPU variables that are either atomic themselves or are
> structures containing atomic fields.
Accessing per-CPU variables in this fashion reliably already requires a suitable
smp/non-smp read/write memory barrier. I maintain that if we break anything
with this change, it was really already broken, if less obviously. Can you give
a real or synthetic example of legitimate code that could break?
-- Chris
next prev parent reply other threads:[~2007-08-09 19:31 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-09 13:24 [PATCH 1/24] make atomic_read() behave consistently on alpha Chris Snook
2007-08-09 14:32 ` Paul E. McKenney
2007-08-09 14:53 ` Chris Snook
2007-08-09 15:04 ` Paul E. McKenney
2007-08-09 15:24 ` Chris Snook
2007-08-09 15:50 ` Segher Boessenkool
2007-08-09 16:20 ` Chris Snook
2007-08-09 18:38 ` Segher Boessenkool
2007-08-09 19:05 ` Chris Snook
2007-08-09 19:19 ` Segher Boessenkool
2007-08-09 19:25 ` Geert Uytterhoeven
2007-08-09 19:47 ` Chris Snook
2007-08-09 23:02 ` Segher Boessenkool
2007-08-09 16:10 ` Paul E. McKenney
2007-08-09 16:36 ` Chris Snook
2007-08-09 16:58 ` Paul E. McKenney
2007-08-09 17:14 ` Chris Snook
2007-08-09 17:41 ` Paul E. McKenney
2007-08-09 18:13 ` Chris Snook
2007-08-09 18:45 ` Paul E. McKenney
2007-08-09 19:24 ` Chris Snook [this message]
2007-08-10 1:28 ` Paul E. McKenney
2007-08-10 19:49 ` Chris Snook
2007-08-10 20:26 ` Paul E. McKenney
2007-08-09 19:17 ` Segher Boessenkool
2007-08-09 18:51 ` Segher Boessenkool
2007-08-09 19:30 ` Chris Snook
2007-08-10 8:21 ` Herbert Xu
2007-08-10 9:08 ` Andi Kleen
2007-08-10 15:02 ` Paul E. McKenney
2007-08-10 20:07 ` Segher Boessenkool
2007-08-11 0:00 ` Herbert Xu
2007-08-11 0:38 ` Segher Boessenkool
2007-08-11 0:43 ` Herbert Xu
2007-08-11 0:50 ` Segher Boessenkool
2007-08-11 4:38 ` Valdis.Kletnieks
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=46BB69F8.5000502@redhat.com \
--to=csnook@redhat.com \
--cc=ak@suse.de \
--cc=akpm@linux-foundation.org \
--cc=cfriesen@nortel.com \
--cc=davem@davemloft.net \
--cc=heiko.carstens@de.ibm.com \
--cc=horms@verge.net.au \
--cc=jesper.juhl@gmail.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=rpjday@mindspring.com \
--cc=schwidefsky@de.ibm.com \
--cc=torvalds@linux-foundation.org \
--cc=wensong@linux-vs.org \
--cc=wjiang@resilience.com \
--cc=zlynx@acm.org \
/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.