All of lore.kernel.org
 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 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.