From: Mark Rutland <mark.rutland@arm.com>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: linux-kernel@vger.kernel.org,
E.@paulmck-thinkpad-p17-gen-1.smtp.subspace.kernel.org,
Alan Stern <stern@rowland.harvard.edu>,
Andrea Parri <parri.andrea@gmail.com>,
Will Deacon <will@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Boqun Feng <boqun.feng@gmail.com>,
Nicholas Piggin <npiggin@gmail.com>,
David Howells <dhowells@redhat.com>,
Jade Alglave <j.alglave@ucl.ac.uk>,
Luc Maranget <luc.maranget@inria.fr>,
Paul@paulmck-thinkpad-p17-gen-1.smtp.subspace.kernel.org,
Akira Yokosawa <akiyks@gmail.com>,
Daniel Lustig <dlustig@nvidia.com>,
Joel Fernandes <joel@joelfernandes.org>,
Jonathan Corbet <corbet@lwn.net>,
linux-arch@vger.kernel.org, linux-doc@vger.kernel.org,
Anna-Maria Behnsen <anna-maria@linutronix.de>
Subject: Re: [PATCH doc] Emphasize that failed atomic operations give no ordering
Date: Tue, 30 Jan 2024 17:12:23 +0000 [thread overview]
Message-ID: <Zbkt94Q8a-xFXrve@FVFF77S0Q05N> (raw)
In-Reply-To: <63d9d6f6-05e8-473d-9d09-ce8d3a33ca39@paulmck-laptop>
On Tue, Jan 30, 2024 at 06:53:38AM -0800, Paul E. McKenney wrote:
> The ORDERING section of Documentation/atomic_t.txt can easily be read as
> saying that conditional atomic RMW operations that fail are ordered when
> those operations have the _acquire() or _release() prefixes. This is
> not the case, therefore update this section to make it clear that failed
> conditional atomic RMW operations provide no ordering.
>
> Reported-by: Anna-Maria Behnsen <anna-maria@linutronix.de>
> Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
> Cc: Alan Stern <stern@rowland.harvard.edu>
> Cc: Andrea Parri <parri.andrea@gmail.com>
> Cc: Will Deacon <will@kernel.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Boqun Feng <boqun.feng@gmail.com>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Cc: David Howells <dhowells@redhat.com>
> Cc: Jade Alglave <j.alglave@ucl.ac.uk>
> Cc: Luc Maranget <luc.maranget@inria.fr>
> Cc: "Paul E. McKenney" <paulmck@kernel.org>
> Cc: Akira Yokosawa <akiyks@gmail.com>
> Cc: Daniel Lustig <dlustig@nvidia.com>
> Cc: Joel Fernandes <joel@joelfernandes.org>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Jonathan Corbet <corbet@lwn.net>
> Cc: <linux-arch@vger.kernel.org>
> Cc: <linux-doc@vger.kernel.org>
>
> diff --git a/Documentation/atomic_t.txt b/Documentation/atomic_t.txt
> index d7adc6d543db4..bee3b1bca9a7b 100644
> --- a/Documentation/atomic_t.txt
> +++ b/Documentation/atomic_t.txt
> @@ -171,14 +171,14 @@ The rule of thumb:
> - RMW operations that are conditional are unordered on FAILURE,
> otherwise the above rules apply.
>
> -Except of course when an operation has an explicit ordering like:
> +Except of course when a successful operation has an explicit ordering like:
>
> {}_relaxed: unordered
> {}_acquire: the R of the RMW (or atomic_read) is an ACQUIRE
> {}_release: the W of the RMW (or atomic_set) is a RELEASE
>
> Where 'unordered' is against other memory locations. Address dependencies are
> -not defeated.
> +not defeated. Conditional operations are still unordered on FAILURE.
>
> Fully ordered primitives are ordered against everything prior and everything
> subsequent. Therefore a fully ordered primitive is like having an smp_mb()
>
FWIW:
Acked-by: Mark Rutland <mark.rutland@arm.com>
Mark.
next prev parent reply other threads:[~2024-01-30 17:12 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-30 14:53 [PATCH doc] Emphasize that failed atomic operations give no ordering Paul E. McKenney
2024-01-30 16:02 ` Andrea Parri
2024-01-30 16:33 ` Paul E. McKenney
2024-01-30 17:12 ` Mark Rutland [this message]
2024-01-30 17:58 ` Paul E. McKenney
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=Zbkt94Q8a-xFXrve@FVFF77S0Q05N \
--to=mark.rutland@arm.com \
--cc="E."@paulmck-thinkpad-p17-gen-1.smtp.subspace.kernel.org \
--cc=Paul@paulmck-thinkpad-p17-gen-1.smtp.subspace.kernel.org \
--cc=akiyks@gmail.com \
--cc=anna-maria@linutronix.de \
--cc=boqun.feng@gmail.com \
--cc=corbet@lwn.net \
--cc=dhowells@redhat.com \
--cc=dlustig@nvidia.com \
--cc=j.alglave@ucl.ac.uk \
--cc=joel@joelfernandes.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luc.maranget@inria.fr \
--cc=npiggin@gmail.com \
--cc=parri.andrea@gmail.com \
--cc=paulmck@kernel.org \
--cc=peterz@infradead.org \
--cc=stern@rowland.harvard.edu \
--cc=will@kernel.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.