From: catalin.marinas@arm.com (Catalin Marinas)
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 18:33:01 +0000 [thread overview]
Message-ID: <20150227183301.GL17949@e104818-lin.cambridge.arm.com> (raw)
In-Reply-To: <CAJhHMCC98dPnx=ng3zp5ZZmzOZkdPXaA1bmcQJuhQj9wb7CRhw@mail.gmail.com>
On Fri, Feb 27, 2015 at 06:25:25PM +0000, Pranith Kumar wrote:
> On Fri, Feb 27, 2015 at 5:06 AM, Will Deacon <will.deacon@arm.com> wrote:
> > On Fri, Feb 27, 2015 at 05:46:55AM +0000, Pranith Kumar wrote:
> >> In cmpxchg(), we do a load exclusive on an address and upon a comparison fail,
> >> we skip the store exclusive instruction. This can result in the exclusive bit
> >> still set. If there was a store exclusive after this to the same address, that
> >> will see the exclusive bit set. This should not happen.
> >
> > ... and the problem with that is?
>
> Consider the following scenario:
>
> P0 P1
> ---------------------------------
> ldxr x7, [B] // exclusive bit set
> add x7, x7, #1
> str ..., [B] // exclusive bit cleared
> cmpxchg:
> ldxr x0, [B] // exclusive bit set
> cmp x0, #0 // cmp fails
> b.ne 1f // branch taken
> stxr x1, [B] // end of cmpxchg
> 1:
> stxr x7, [B] // succeeds?
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).
> The last store exclusive succeeds since the exclusive bit is set which
> should not happen. Clearing the exclusive bit before returning from cmpxchg
> prevents this happening.
>
> Now I am not sure how likely this will happen. One can argue that a cmpxchg()
> will not happen between an external ldxr/stxr. But isn't clearing the exclusive
> bit better?
The only way cmpxchg() could happen between a different ldxr/stxr is
during an interrupt. But ERET automatically clears the exclusive
monitor, so the "stxr x7" would not succeed.
--
Catalin
next prev parent reply other threads:[~2015-02-27 18:33 UTC|newest]
Thread overview: 8+ 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 10:06 ` Will Deacon
2015-02-27 18:25 ` Pranith Kumar
2015-02-27 18:33 ` Catalin Marinas [this message]
2015-02-27 18:44 ` Pranith Kumar
2015-02-27 19:08 ` Mark Rutland
2015-02-27 19:15 ` Pranith Kumar
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=20150227183301.GL17949@e104818-lin.cambridge.arm.com \
--to=catalin.marinas@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox