From: Christoffer Dall <christoffer.dall@linaro.org>
To: Andrew Jones <drjones@redhat.com>
Cc: kvm@vger.kernel.org, kvmarm@lists.cs.columbia.edu, pbonzini@redhat.com
Subject: Re: [PATCH 1/3] arm/arm64: spinlocks: fix memory barriers
Date: Mon, 29 Jun 2015 12:27:32 +0200 [thread overview]
Message-ID: <20150629102732.GI11332@cbox> (raw)
In-Reply-To: <1435248739-25425-2-git-send-email-drjones@redhat.com>
On Thu, Jun 25, 2015 at 06:12:17PM +0200, Andrew Jones wrote:
> It shouldn't be necessary to use a barrier on the way into
> spin_lock. We'll be focused on a single address until we get
> it (exclusively) set, and then we'll do a barrier on the way
> out. Also, it does make sense to do a barrier on the way in
> to spin_unlock, i.e. ensure what we did in the critical section
> is ordered wrt to what we do outside it, before we announce that
> we're outside.
>
> Signed-off-by: Andrew Jones <drjones@redhat.com>
> ---
> lib/arm/spinlock.c | 8 ++++----
> lib/arm64/spinlock.c | 5 ++---
> 2 files changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/lib/arm/spinlock.c b/lib/arm/spinlock.c
> index 3b023ceaebf71..116ea5d7db930 100644
> --- a/lib/arm/spinlock.c
> +++ b/lib/arm/spinlock.c
> @@ -7,10 +7,9 @@ void spin_lock(struct spinlock *lock)
> {
> u32 val, fail;
>
> - dmb();
> -
> if (!mmu_enabled()) {
> lock->v = 1;
> + smp_mb();
> return;
> }
>
> @@ -25,11 +24,12 @@ void spin_lock(struct spinlock *lock)
> : "r" (&lock->v)
> : "cc" );
> } while (fail);
> - dmb();
> +
> + smp_mb();
> }
>
> void spin_unlock(struct spinlock *lock)
> {
> + smp_mb();
> lock->v = 0;
> - dmb();
> }
> diff --git a/lib/arm64/spinlock.c b/lib/arm64/spinlock.c
> index 68b68b75ba60d..a3907f03cacda 100644
> --- a/lib/arm64/spinlock.c
> +++ b/lib/arm64/spinlock.c
> @@ -13,10 +13,9 @@ void spin_lock(struct spinlock *lock)
> {
> u32 val, fail;
>
> - smp_mb();
> -
> if (!mmu_enabled()) {
> lock->v = 1;
> + smp_mb();
> return;
> }
>
> @@ -35,9 +34,9 @@ void spin_lock(struct spinlock *lock)
>
> void spin_unlock(struct spinlock *lock)
> {
> + smp_mb();
> if (mmu_enabled())
> asm volatile("stlrh wzr, [%0]" :: "r" (&lock->v));
> else
> lock->v = 0;
> - smp_mb();
> }
> --
> 2.4.3
>
looks good to me
-Christoffer
next prev parent reply other threads:[~2015-06-29 10:27 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-25 16:12 [PATCH 0/3] arm/arm64: tcg_baremetal_tests inspired patches Andrew Jones
2015-06-25 16:12 ` [PATCH 1/3] arm/arm64: spinlocks: fix memory barriers Andrew Jones
2015-06-29 10:27 ` Christoffer Dall [this message]
2015-07-03 17:42 ` Paolo Bonzini
2015-06-25 16:12 ` [PATCH 2/3] arm/arm64: speed up spinlocks and atomic ops Andrew Jones
2015-06-25 16:23 ` Paolo Bonzini
2015-06-25 16:55 ` Andrew Jones
2015-06-29 10:28 ` Christoffer Dall
2015-06-29 10:44 ` Andrew Jones
2015-06-29 12:53 ` Christoffer Dall
2015-06-25 16:12 ` [PATCH 3/3] arm/arm64: allow building a single test Andrew Jones
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=20150629102732.GI11332@cbox \
--to=christoffer.dall@linaro.org \
--cc=drjones@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.cs.columbia.edu \
--cc=pbonzini@redhat.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.