From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: Andi Kleen <ak@suse.de>
Cc: patches@x86-64.org, Jeremy Fitzhardinge <jeremy@goop.org>,
Zachary Amsden <zach@vmware.com>,
Rusty Russell <rusty@rustcorp.com.au>,
linux-kernel@vger.kernel.org,
"S. P. Prasanna" <prasanna@in.ibm.com>,
Chris Wright <chrisw@sous-sol.org>
Subject: Non atomic unaligned writes
Date: Sun, 19 Aug 2007 20:55:22 -0400 [thread overview]
Message-ID: <20070820005522.GA5069@Krystal> (raw)
In-Reply-To: <200707192246.58047.ak@suse.de>
* Andi Kleen (ak@suse.de) wrote:
> Normally there are not that many NMIs or MCEs at boot, but it would
> be still good to avoid the very rare crash by auditing the code first
> [better than try to debug it on some production system later]
>
> > > - smp lock patching only ever changes a single byte (lock prefix) of
> > > a single instruction
> > > - kprobes only ever change a single byte
> > >
> > > For the immediate value patching it also cannot happen because
> > > you'll never modify multiple instructions and all immediate values
> > > can be changed atomically.
> > >
> >
> > Are misaligned/cross-cache-line updates atomic?
>
> In theory yes, in practice there can be errata of course. There tend
> to be a couple with self modifying code, especially cross modifying
> (from another CPU) -- but you don't do that.
>
> -Andi
I must disagree with Andi on this point. Considering the quoted
paragraph below, misaligned/cross-cache-line updates are not atomic.
This is why I align the immediate values in such a way that the
immediate value within the mov instruction is itself aligned.
Intel System Programming Guide
7.1.1 Guaranteed Atomic Operations
The Intel386™, Intel486™, Pentium®, and P6 family processors guarantee
that the following basic memory operations will always be carried out
atomically:
• Reading or writing a byte.
• Reading or writing a word aligned on a 16-bit boundary.
• Reading or writing a doubleword aligned on a 32-bit boundary.
The P6 family processors guarantee that the following additional memory
operations will always be carried out atomically:
• Reading or writing a quadword aligned on a 64-bit boundary. (This
operation is also guaranteed on the Pentium® processor.)
• 16-bit accesses to uncached memory locations that fit within a 32-bit
data bus.
• 16-, 32-, and 64-bit accesses to cached memory that fit within a
32-Byte cache line.
Accesses to cacheable memory that are split across bus widths, cache
lines, and page boundaries are not guaranteed to be atomic by the
Intel486™, Pentium®, or P6 family processors. The P6 family processors
provide bus control signals that permit external memory subsystems to
make split accesses atomic; however, nonaligned data accesses will
seriously impact the performance of the processor and should be avoided
where possible.
Mathieu
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
next prev parent reply other threads:[~2007-08-20 1:00 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-19 9:05 new text patching for review Andi Kleen
2007-07-19 13:38 ` Mathieu Desnoyers
2007-07-19 13:46 ` Andi Kleen
2007-07-19 17:35 ` Mathieu Desnoyers
2007-07-19 21:14 ` Andi Kleen
2007-07-19 20:30 ` Jeremy Fitzhardinge
2007-07-19 20:46 ` [patches] " Andi Kleen
2007-07-19 20:51 ` Jeremy Fitzhardinge
2007-07-19 21:06 ` Andi Kleen
2007-07-19 21:08 ` Jeremy Fitzhardinge
2007-07-19 23:53 ` Mathieu Desnoyers
2007-08-20 0:55 ` Mathieu Desnoyers [this message]
2007-08-20 5:03 ` Non atomic unaligned writes Arjan van de Ven
2007-08-20 10:23 ` Andi Kleen
2007-07-19 23:51 ` new text patching for review Mathieu Desnoyers
2007-07-19 23:49 ` Mathieu Desnoyers
2007-07-20 1:15 ` Zachary Amsden
2007-07-20 7:37 ` Andi Kleen
2007-07-20 15:17 ` Mathieu Desnoyers
2007-07-21 6:19 ` Andi Kleen
2007-07-20 8:28 ` Andi Kleen
2007-07-20 14:36 ` Mathieu Desnoyers
2007-07-20 0:37 ` Zachary Amsden
2007-07-20 8:23 ` Andi Kleen
2007-08-10 19:00 ` Mathieu Desnoyers
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=20070820005522.GA5069@Krystal \
--to=mathieu.desnoyers@polymtl.ca \
--cc=ak@suse.de \
--cc=chrisw@sous-sol.org \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=patches@x86-64.org \
--cc=prasanna@in.ibm.com \
--cc=rusty@rustcorp.com.au \
--cc=zach@vmware.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.