All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.