linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 02/20] documentation: Clarify failed cmpxchg memory ordering semantics
Date: Mon, 27 Jul 2015 12:58:22 +0100	[thread overview]
Message-ID: <20150727115822.GH3358@arm.com> (raw)
In-Reply-To: <1437734531-10698-3-git-send-email-will.deacon@arm.com>

On Fri, Jul 24, 2015 at 11:41:53AM +0100, Will Deacon wrote:
> A failed cmpxchg does not provide any memory ordering guarantees, a
> property that is used to optimise the cmpxchg implementations on Alpha,
> PowerPC and arm64.
> 
> This patch updates atomic_ops.txt and memory-barriers.txt to reflect
> this.
> 
> Cc: Peter Zijlstra <peterz@infradead.org>
> Signed-off-by: Will Deacon <will.deacon@arm.com>
> ---
>  Documentation/atomic_ops.txt      | 4 +++-
>  Documentation/memory-barriers.txt | 6 +++---
>  2 files changed, 6 insertions(+), 4 deletions(-)

Peter: are you ok with me taking this via the arm64 tree (along with the
rest of the series), or would you prefer this patch routed through -tip?

Will

> diff --git a/Documentation/atomic_ops.txt b/Documentation/atomic_ops.txt
> index dab6da3382d9..b19fc34efdb1 100644
> --- a/Documentation/atomic_ops.txt
> +++ b/Documentation/atomic_ops.txt
> @@ -266,7 +266,9 @@ with the given old and new values. Like all atomic_xxx operations,
>  atomic_cmpxchg will only satisfy its atomicity semantics as long as all
>  other accesses of *v are performed through atomic_xxx operations.
>  
> -atomic_cmpxchg must provide explicit memory barriers around the operation.
> +atomic_cmpxchg must provide explicit memory barriers around the operation,
> +although if the comparison fails then no memory ordering guarantees are
> +required.
>  
>  The semantics for atomic_cmpxchg are the same as those defined for 'cas'
>  below.
> diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt
> index 13feb697271f..18fc860df1be 100644
> --- a/Documentation/memory-barriers.txt
> +++ b/Documentation/memory-barriers.txt
> @@ -2383,9 +2383,7 @@ about the state (old or new) implies an SMP-conditional general memory barrier
>  explicit lock operations, described later).  These include:
>  
>  	xchg();
> -	cmpxchg();
>  	atomic_xchg();			atomic_long_xchg();
> -	atomic_cmpxchg();		atomic_long_cmpxchg();
>  	atomic_inc_return();		atomic_long_inc_return();
>  	atomic_dec_return();		atomic_long_dec_return();
>  	atomic_add_return();		atomic_long_add_return();
> @@ -2398,7 +2396,9 @@ explicit lock operations, described later).  These include:
>  	test_and_clear_bit();
>  	test_and_change_bit();
>  
> -	/* when succeeds (returns 1) */
> +	/* when succeeds */
> +	cmpxchg();
> +	atomic_cmpxchg();		atomic_long_cmpxchg();
>  	atomic_add_unless();		atomic_long_add_unless();
>  
>  These are used for such things as implementing ACQUIRE-class and RELEASE-class
> -- 
> 2.1.4
> 

  parent reply	other threads:[~2015-07-27 11:58 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-24 10:41 [PATCH v2 00/20] arm64: support for 8.1 LSE atomic instructions Will Deacon
2015-07-24 10:41 ` [PATCH v2 01/20] arm64: rwlocks: don't fail trylock purely due to contention Will Deacon
2015-07-24 11:14   ` Catalin Marinas
2015-07-24 10:41 ` [PATCH v2 02/20] documentation: Clarify failed cmpxchg memory ordering semantics Will Deacon
2015-07-24 11:15   ` Catalin Marinas
2015-07-27 11:58   ` Will Deacon [this message]
2015-07-27 12:02     ` Peter Zijlstra
2015-07-27 13:00       ` Will Deacon
2015-07-24 10:41 ` [PATCH v2 03/20] arm64: cpufeature.h: add missing #include of kernel.h Will Deacon
2015-07-24 11:15   ` Catalin Marinas
2015-07-24 10:41 ` [PATCH v2 04/20] arm64: atomics: move ll/sc atomics into separate header file Will Deacon
2015-07-24 11:19   ` Catalin Marinas
2015-07-24 10:41 ` [PATCH v2 05/20] arm64: elf: advertise 8.1 atomic instructions as new hwcap Will Deacon
2015-07-24 11:24   ` Catalin Marinas
2015-07-24 10:41 ` [PATCH v2 06/20] arm64: alternatives: add cpu feature for lse atomics Will Deacon
2015-07-24 11:26   ` Catalin Marinas
2015-07-24 10:41 ` [PATCH v2 07/20] arm64: introduce CONFIG_ARM64_LSE_ATOMICS as fallback to ll/sc atomics Will Deacon
2015-07-24 11:38   ` Catalin Marinas
2015-07-24 10:41 ` [PATCH v2 08/20] arm64: atomics: patch in lse instructions when supported by the CPU Will Deacon
2015-07-24 14:43   ` Catalin Marinas
2015-07-24 10:42 ` [PATCH v2 09/20] arm64: locks: " Will Deacon
2015-07-24 15:08   ` Catalin Marinas
2015-07-24 10:42 ` [PATCH v2 10/20] arm64: bitops: " Will Deacon
2015-07-24 15:19   ` Catalin Marinas
2015-07-24 10:42 ` [PATCH v2 11/20] arm64: xchg: " Will Deacon
2015-07-24 15:19   ` Catalin Marinas
2015-07-24 10:42 ` [PATCH v2 12/20] arm64: cmpxchg: " Will Deacon
2015-07-24 15:21   ` Catalin Marinas
2015-07-24 10:42 ` [PATCH v2 13/20] arm64: cmpxchg_dbl: " Will Deacon
2015-07-24 15:29   ` Catalin Marinas
2015-07-24 10:42 ` [PATCH v2 14/20] arm64: cmpxchg: avoid "cc" clobber in ll/sc routines Will Deacon
2015-07-24 15:30   ` Catalin Marinas
2015-07-24 10:42 ` [PATCH v2 15/20] arm64: cmpxchg: avoid memory barrier on comparison failure Will Deacon
2015-07-24 15:32   ` Catalin Marinas
2015-07-24 10:42 ` [PATCH v2 16/20] arm64: atomics: tidy up common atomic{,64}_* macros Will Deacon
2015-07-24 15:40   ` Catalin Marinas
2015-07-24 10:42 ` [PATCH v2 17/20] arm64: atomics: prefetch the destination word for write prior to stxr Will Deacon
2015-07-24 15:42   ` Catalin Marinas
2015-07-24 10:42 ` [PATCH v2 18/20] arm64: atomics: implement atomic{, 64}_cmpxchg using cmpxchg Will Deacon
2015-07-24 15:44   ` Catalin Marinas
2015-07-24 10:42 ` [PATCH v2 19/20] arm64: atomic64_dec_if_positive: fix incorrect branch condition Will Deacon
2015-07-24 15:45   ` Catalin Marinas
2015-07-24 10:42 ` [PATCH v2 20/20] arm64: kconfig: select HAVE_CMPXCHG_LOCAL Will Deacon
2015-07-24 15:45   ` Catalin Marinas

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=20150727115822.GH3358@arm.com \
    --to=will.deacon@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;
as well as URLs for NNTP newsgroup(s).