From: mark.rutland@arm.com (Mark Rutland)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH] ARM64: cmpxchg.h: Clear the exclusive access bit on fail
Date: Fri, 27 Feb 2015 19:08:03 +0000 [thread overview]
Message-ID: <20150227190800.GE9011@leverpostej> (raw)
In-Reply-To: <CAJhHMCBwgi96jyAi0Sdi_tEephLjKuG2DQcWa=tv7d7aEbKuaA@mail.gmail.com>
On Fri, Feb 27, 2015 at 06:44:19PM +0000, Pranith Kumar wrote:
> On Fri, Feb 27, 2015 at 1:33 PM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
> > It's either badly formatted or I don't get it. Are the "stxr x1" and
> > "stxr x7" happening on the same CPU (P0)? If yes, that's badly written
> > code, not even architecturally compliant (you are not allowed other
> > memory accesses between ldxr and stxr).
>
> OK. Is that the same case with ldaxr (acquire) and stlxr (release)?
> AFAIK, memory accesses between acquire and release exclusive
> operations are allowed.
The restriction on memory accesses in the middle of a load-exclusive
store-exclusive sequence applies to all the load/store-exclusive
variants, including ldaxr and stlxr.
Thanks,
Mark.
WARNING: multiple messages have this Message-ID (diff)
From: Mark Rutland <mark.rutland@arm.com>
To: Pranith Kumar <bobby.prani@gmail.com>
Cc: Catalin Marinas <Catalin.Marinas@arm.com>,
Steve Capper <steve.capper@linaro.org>,
Will Deacon <Will.Deacon@arm.com>,
open list <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [RFC PATCH] ARM64: cmpxchg.h: Clear the exclusive access bit on fail
Date: Fri, 27 Feb 2015 19:08:03 +0000 [thread overview]
Message-ID: <20150227190800.GE9011@leverpostej> (raw)
In-Reply-To: <CAJhHMCBwgi96jyAi0Sdi_tEephLjKuG2DQcWa=tv7d7aEbKuaA@mail.gmail.com>
On Fri, Feb 27, 2015 at 06:44:19PM +0000, Pranith Kumar wrote:
> On Fri, Feb 27, 2015 at 1:33 PM, Catalin Marinas
> <catalin.marinas@arm.com> wrote:
> > It's either badly formatted or I don't get it. Are the "stxr x1" and
> > "stxr x7" happening on the same CPU (P0)? If yes, that's badly written
> > code, not even architecturally compliant (you are not allowed other
> > memory accesses between ldxr and stxr).
>
> OK. Is that the same case with ldaxr (acquire) and stlxr (release)?
> AFAIK, memory accesses between acquire and release exclusive
> operations are allowed.
The restriction on memory accesses in the middle of a load-exclusive
store-exclusive sequence applies to all the load/store-exclusive
variants, including ldaxr and stlxr.
Thanks,
Mark.
next prev parent reply other threads:[~2015-02-27 19:08 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-27 5:46 [RFC PATCH] ARM64: cmpxchg.h: Clear the exclusive access bit on fail Pranith Kumar
2015-02-27 5:46 ` Pranith Kumar
2015-02-27 10:06 ` Will Deacon
2015-02-27 10:06 ` Will Deacon
2015-02-27 18:25 ` Pranith Kumar
2015-02-27 18:25 ` Pranith Kumar
2015-02-27 18:33 ` Catalin Marinas
2015-02-27 18:33 ` Catalin Marinas
2015-02-27 18:44 ` Pranith Kumar
2015-02-27 18:44 ` Pranith Kumar
2015-02-27 19:08 ` Mark Rutland [this message]
2015-02-27 19:08 ` Mark Rutland
2015-02-27 19:15 ` Pranith Kumar
2015-02-27 19:15 ` Pranith Kumar
2015-02-27 19:33 ` Mark Rutland
2015-02-27 19:33 ` Mark Rutland
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=20150227190800.GE9011@leverpostej \
--to=mark.rutland@arm.com \
--cc=linux-arm-kernel@lists.infradead.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.