From nobody Mon Feb 9 03:52:17 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4C0B6135A55; Thu, 4 Apr 2024 19:26:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712258812; cv=none; b=E49Xkp+tbPi0dcRz0loCVeDATPJ0nUgEKU3BkkwbvXx8HQVMn2Fs9wF446LYm0luFJ3S+aa2/vZNq91WSo/qDb6ITsUg3DhA0osjsXYR1dseN4heBPMKkX3pCP+32ImCKm+PQFaw9NHbpsKUBI+vfRB0Uw4cgaywZo1GqG5iU1s= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712258812; c=relaxed/simple; bh=0guQJ43kZOeFK9RaRxxK/HF/2Akt543i2YM1yup2VqY=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=dI3gXCeXLT3u9Zop3jV4rmRxep6hDuI9dOdWWTzPyq8IqVsgBOOzM3ij09asChpTvK+5A+dlqA2/TUBJ46CZho9aYYRhCB0tgIKQwAwVv4Oxdb0nI8LdIYgFXVIV8aSCSnVXhMHFjryam5nqJIZu8Xcf5o7qGKSA7FOwP6tLLfk= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=iK0hUQTw; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="iK0hUQTw" Received: by smtp.kernel.org (Postfix) with ESMTPSA id DB8C7C43399; Thu, 4 Apr 2024 19:26:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1712258811; bh=0guQJ43kZOeFK9RaRxxK/HF/2Akt543i2YM1yup2VqY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=iK0hUQTwRSYy33JiDwuEUeSQBqdgS5YZ1GNoaKUX2jKwdjibAtwKzF3/ScOLNEKsB waNLctbwNPfTnLkOS5FUPocf2RHHfPLzDmzzNAmCHqYyqvH8Ly1BQJhoV8xT8p2pFF cmMVgYIsfD6E9oacNfMRrnZO9kBb9d3VE8pHNLLUVz5zBkatO4s7sUhCG7NiVrM/iv o8SfU/eb5jl+bkR5F6d2KdssDw4GMyeXOcs+7IYBJpSayNfq1UjAG264wNoO9WFu3x +8gqb49hGbAmM2+bwxHSi2yVzi2mCQdIA+so3BH2mkMFue/fHDL/W++rhaa1/ADMhL pMMyMfalYxPuw== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 90EDECE0D0C; Thu, 4 Apr 2024 12:26:51 -0700 (PDT) From: "Paul E. McKenney" To: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, kernel-team@meta.com, mingo@kernel.org Cc: stern@rowland.harvard.edu, parri.andrea@gmail.com, will@kernel.org, peterz@infradead.org, boqun.feng@gmail.com, npiggin@gmail.com, dhowells@redhat.com, j.alglave@ucl.ac.uk, luc.maranget@inria.fr, akiyks@gmail.com, "Paul E. McKenney" , Daniel Lustig , Joel Fernandes , Mark Rutland , Jonathan Corbet , linux-doc@vger.kernel.org Subject: [PATCH memory-model 1/3] Documentation/litmus-tests: Add locking tests to README Date: Thu, 4 Apr 2024 12:26:47 -0700 Message-Id: <20240404192649.531112-1-paulmck@kernel.org> X-Mailer: git-send-email 2.40.1 In-Reply-To: <8550daf1-4bfd-4607-8325-bfb7c1e2d8c7@paulmck-laptop> References: <8550daf1-4bfd-4607-8325-bfb7c1e2d8c7@paulmck-laptop> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" This commit documents the litmus tests in the "locking" directory. Signed-off-by: Paul E. McKenney Cc: Alan Stern Cc: Will Deacon Cc: Peter Zijlstra Cc: Boqun Feng Cc: Nicholas Piggin Cc: David Howells Cc: Jade Alglave Cc: Luc Maranget Cc: "Paul E. McKenney" Cc: Akira Yokosawa Cc: Daniel Lustig Cc: Joel Fernandes Cc: Mark Rutland Cc: Jonathan Corbet Cc: Cc: --- Documentation/litmus-tests/README | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) diff --git a/Documentation/litmus-tests/README b/Documentation/litmus-tests= /README index 658d37860d397..5c8915e6fb684 100644 --- a/Documentation/litmus-tests/README +++ b/Documentation/litmus-tests/README @@ -22,6 +22,35 @@ Atomic-RMW-ops-are-atomic-WRT-atomic_set.litmus NOTE: Require herd7 7.56 or later which supports "(void)expr". =20 =20 +locking (/locking directory) +---------------------------- + +DCL-broken.litmus + Demonstrates that double-checked locking needs more than just + the obvious lock acquisitions and releases. + +DCL-fixed.litmus + Demonstrates corrected double-checked locking that uses + smp_store_release() and smp_load_acquire() in addition to the + obvious lock acquisitions and releases. + +RM-broken.litmus + Demonstrates problems with "roach motel" locking, where code is + freely moved into lock-based critical sections. This example also + shows how to use the "filter" clause to discard executions that + would be excluded by other code not modeled in the litmus test. + Note also that this "roach motel" optimization is emulated by + physically moving P1()'s two reads from x under the lock. + + What is a roach motel? This is from an old advertisement for + a cockroach trap, much later featured in one of the "Men in + Black" movies. "The roaches check in. They don't check out." + +RM-fixed.litmus + The counterpart to RM-broken.litmus, showing P0()'s two loads from + x safely outside of the critical section. + + RCU (/rcu directory) -------------------- =20 --=20 2.40.1 From nobody Mon Feb 9 03:52:17 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 4C06E15EA6; Thu, 4 Apr 2024 19:26:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712258812; cv=none; b=fwuKT3ZlAc7B7bWyZH8Qs5Z/Ha2Vi0xBLjg/qzyeCUfS4bRNnAaD+Dr2k8lBo3qJsZ8hX0OePhaOvGbrFqDlBzIkO+oskF7KqCNeBVmOzMCn3mIPk9JG7xnWr39gZaIB8W3ook/3INNPzLaRrPfd8GVkzRt9xfTzf2fJr3byfyM= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712258812; c=relaxed/simple; bh=EdNvKx2O5c+vvjNaWxfRZSP6Ftir/oLJKykWQvklzVQ=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=r0a9ah9h+Ziq/FZEEbLXCq+dSkFTdbmJszG/Q2OU2d2aPv4tNk/AVuJFKSNCrcFBWIh4P5rh2+JL85hF8+m5b40G/NBSjljmH2mlLCoTWgVt5xh5l7Fu791e/7nNleqO8zC7vjErzgSumeEXrXAd+7byd/DQNtOSNgKHsitvq1Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qB9oAm/x; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qB9oAm/x" Received: by smtp.kernel.org (Postfix) with ESMTPSA id E3C04C433B2; Thu, 4 Apr 2024 19:26:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1712258812; bh=EdNvKx2O5c+vvjNaWxfRZSP6Ftir/oLJKykWQvklzVQ=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qB9oAm/x/mX6qTk2wwOIZrgGmA9qtOMhTYSl/RHf832fEsSKzzpBal7339nvTyiNK c81oPNwKK/++h0VImLjP7ODxw7+CJamPowVr0AsGmfhMwAcPKZUslJzGoYkyWb97vS UDfsHnKwmUbImvjPPyZdSpNuEfgy0+CC5cpS5ul/FvLTL0ncKIicuYTKr4WbsBIaXv CtOwGyspNrKeM28PqF/UI0YWYNf0zDlcNFKlSqMARvVZo5QBnGOcem1vEMHaeUcy4B DGlltj6W+oaeK8pyQSgkkA1olfa9DkX1bcrdRT0rSKl0hGqVFXGXzOzxPFuNM5ILg1 Db0gCbL/N83Yg== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 94D86CE12BF; Thu, 4 Apr 2024 12:26:51 -0700 (PDT) From: "Paul E. McKenney" To: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, kernel-team@meta.com, mingo@kernel.org Cc: stern@rowland.harvard.edu, parri.andrea@gmail.com, will@kernel.org, peterz@infradead.org, boqun.feng@gmail.com, npiggin@gmail.com, dhowells@redhat.com, j.alglave@ucl.ac.uk, luc.maranget@inria.fr, akiyks@gmail.com, "Paul E. McKenney" , Frederic Weisbecker , Daniel Lustig , Joel Fernandes , Mark Rutland , Jonathan Corbet , linux-doc@vger.kernel.org Subject: [PATCH memory-model 2/3] Documentation/litmus-tests: Demonstrate unordered failing cmpxchg Date: Thu, 4 Apr 2024 12:26:48 -0700 Message-Id: <20240404192649.531112-2-paulmck@kernel.org> X-Mailer: git-send-email 2.40.1 In-Reply-To: <8550daf1-4bfd-4607-8325-bfb7c1e2d8c7@paulmck-laptop> References: <8550daf1-4bfd-4607-8325-bfb7c1e2d8c7@paulmck-laptop> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" This commit adds four litmus tests showing that a failing cmpxchg() operation is unordered unless followed by an smp_mb__after_atomic() operation. Suggested-by: Frederic Weisbecker Signed-off-by: Paul E. McKenney Cc: Alan Stern Cc: Will Deacon Cc: Peter Zijlstra Cc: Boqun Feng Cc: Nicholas Piggin Cc: David Howells Cc: Jade Alglave Cc: Luc Maranget Cc: "Paul E. McKenney" Cc: Akira Yokosawa Cc: Daniel Lustig Cc: Joel Fernandes Cc: Mark Rutland Cc: Jonathan Corbet Cc: Cc: --- Documentation/litmus-tests/README | 48 ++++++++++++------- .../atomic/cmpxchg-fail-ordered-1.litmus | 34 +++++++++++++ .../atomic/cmpxchg-fail-ordered-2.litmus | 30 ++++++++++++ .../atomic/cmpxchg-fail-unordered-1.litmus | 33 +++++++++++++ .../atomic/cmpxchg-fail-unordered-2.litmus | 30 ++++++++++++ 5 files changed, 159 insertions(+), 16 deletions(-) create mode 100644 Documentation/litmus-tests/atomic/cmpxchg-fail-ordered-= 1.litmus create mode 100644 Documentation/litmus-tests/atomic/cmpxchg-fail-ordered-= 2.litmus create mode 100644 Documentation/litmus-tests/atomic/cmpxchg-fail-unordere= d-1.litmus create mode 100644 Documentation/litmus-tests/atomic/cmpxchg-fail-unordere= d-2.litmus diff --git a/Documentation/litmus-tests/README b/Documentation/litmus-tests= /README index 5c8915e6fb684..6c666f3422ea3 100644 --- a/Documentation/litmus-tests/README +++ b/Documentation/litmus-tests/README @@ -21,34 +21,50 @@ Atomic-RMW-ops-are-atomic-WRT-atomic_set.litmus Test that atomic_set() cannot break the atomicity of atomic RMWs. NOTE: Require herd7 7.56 or later which supports "(void)expr". =20 +cmpxchg-fail-ordered-1.litmus + Demonstrate that a failing cmpxchg() operation acts as a full barrier + when followed by smp_mb__after_atomic(). + +cmpxchg-fail-ordered-2.litmus + Demonstrate that a failing cmpxchg() operation acts as an acquire + operation when followed by smp_mb__after_atomic(). + +cmpxchg-fail-unordered-1.litmus + Demonstrate that a failing cmpxchg() operation does not act as a + full barrier. + +cmpxchg-fail-unordered-2.litmus + Demonstrate that a failing cmpxchg() operation does not act as an + acquire operation. + =20 locking (/locking directory) ---------------------------- =20 DCL-broken.litmus - Demonstrates that double-checked locking needs more than just - the obvious lock acquisitions and releases. + Demonstrates that double-checked locking needs more than just + the obvious lock acquisitions and releases. =20 DCL-fixed.litmus - Demonstrates corrected double-checked locking that uses - smp_store_release() and smp_load_acquire() in addition to the - obvious lock acquisitions and releases. + Demonstrates corrected double-checked locking that uses + smp_store_release() and smp_load_acquire() in addition to the + obvious lock acquisitions and releases. =20 RM-broken.litmus - Demonstrates problems with "roach motel" locking, where code is - freely moved into lock-based critical sections. This example also - shows how to use the "filter" clause to discard executions that - would be excluded by other code not modeled in the litmus test. - Note also that this "roach motel" optimization is emulated by - physically moving P1()'s two reads from x under the lock. + Demonstrates problems with "roach motel" locking, where code is + freely moved into lock-based critical sections. This example also + shows how to use the "filter" clause to discard executions that + would be excluded by other code not modeled in the litmus test. + Note also that this "roach motel" optimization is emulated by + physically moving P1()'s two reads from x under the lock. =20 - What is a roach motel? This is from an old advertisement for - a cockroach trap, much later featured in one of the "Men in - Black" movies. "The roaches check in. They don't check out." + What is a roach motel? This is from an old advertisement for + a cockroach trap, much later featured in one of the "Men in + Black" movies. "The roaches check in. They don't check out." =20 RM-fixed.litmus - The counterpart to RM-broken.litmus, showing P0()'s two loads from - x safely outside of the critical section. + The counterpart to RM-broken.litmus, showing P0()'s two loads from + x safely outside of the critical section. =20 =20 RCU (/rcu directory) diff --git a/Documentation/litmus-tests/atomic/cmpxchg-fail-ordered-1.litmu= s b/Documentation/litmus-tests/atomic/cmpxchg-fail-ordered-1.litmus new file mode 100644 index 0000000000000..3df1d140b189b --- /dev/null +++ b/Documentation/litmus-tests/atomic/cmpxchg-fail-ordered-1.litmus @@ -0,0 +1,34 @@ +C cmpxchg-fail-ordered-1 + +(* + * Result: Never + * + * Demonstrate that a failing cmpxchg() operation will act as a full + * barrier when followed by smp_mb__after_atomic(). + *) + +{} + +P0(int *x, int *y, int *z) +{ + int r0; + int r1; + + WRITE_ONCE(*x, 1); + r1 =3D cmpxchg(z, 1, 0); + smp_mb__after_atomic(); + r0 =3D READ_ONCE(*y); +} + +P1(int *x, int *y, int *z) +{ + int r0; + + WRITE_ONCE(*y, 1); + r1 =3D cmpxchg(z, 1, 0); + smp_mb__after_atomic(); + r0 =3D READ_ONCE(*x); +} + +locations[0:r1;1:r1] +exists (0:r0=3D0 /\ 1:r0=3D0) diff --git a/Documentation/litmus-tests/atomic/cmpxchg-fail-ordered-2.litmu= s b/Documentation/litmus-tests/atomic/cmpxchg-fail-ordered-2.litmus new file mode 100644 index 0000000000000..54146044a16f6 --- /dev/null +++ b/Documentation/litmus-tests/atomic/cmpxchg-fail-ordered-2.litmus @@ -0,0 +1,30 @@ +C cmpxchg-fail-ordered-2 + +(* + * Result: Never + * + * Demonstrate use of smp_mb__after_atomic() to make a failing cmpxchg + * operation have acquire ordering. + *) + +{} + +P0(int *x, int *y) +{ + int r0; + int r1; + + WRITE_ONCE(*x, 1); + r1 =3D cmpxchg(y, 0, 1); +} + +P1(int *x, int *y) +{ + int r0; + + r1 =3D cmpxchg(y, 0, 1); + smp_mb__after_atomic(); + r2 =3D READ_ONCE(*x); +} + +exists (0:r1=3D0 /\ 1:r1=3D1 /\ 1:r2=3D0) diff --git a/Documentation/litmus-tests/atomic/cmpxchg-fail-unordered-1.lit= mus b/Documentation/litmus-tests/atomic/cmpxchg-fail-unordered-1.litmus new file mode 100644 index 0000000000000..a727ce23b1a6e --- /dev/null +++ b/Documentation/litmus-tests/atomic/cmpxchg-fail-unordered-1.litmus @@ -0,0 +1,33 @@ +C cmpxchg-fail-unordered-1 + +(* + * Result: Sometimes + * + * Demonstrate that a failing cmpxchg() operation does not act as a + * full barrier. (In contrast, a successful cmpxchg() does act as a + * full barrier.) + *) + +{} + +P0(int *x, int *y, int *z) +{ + int r0; + int r1; + + WRITE_ONCE(*x, 1); + r1 =3D cmpxchg(z, 1, 0); + r0 =3D READ_ONCE(*y); +} + +P1(int *x, int *y, int *z) +{ + int r0; + + WRITE_ONCE(*y, 1); + r1 =3D cmpxchg(z, 1, 0); + r0 =3D READ_ONCE(*x); +} + +locations[0:r1;1:r1] +exists (0:r0=3D0 /\ 1:r0=3D0) diff --git a/Documentation/litmus-tests/atomic/cmpxchg-fail-unordered-2.lit= mus b/Documentation/litmus-tests/atomic/cmpxchg-fail-unordered-2.litmus new file mode 100644 index 0000000000000..a245bac55b578 --- /dev/null +++ b/Documentation/litmus-tests/atomic/cmpxchg-fail-unordered-2.litmus @@ -0,0 +1,30 @@ +C cmpxchg-fail-unordered-2 + +(* + * Result: Sometimes + * + * Demonstrate that a failing cmpxchg() operation does not act as either + * an acquire release operation. (In contrast, a successful cmpxchg() + * does act as both an acquire and a release operation.) + *) + +{} + +P0(int *x, int *y) +{ + int r0; + int r1; + + WRITE_ONCE(*x, 1); + r1 =3D cmpxchg(y, 0, 1); +} + +P1(int *x, int *y) +{ + int r0; + + r1 =3D cmpxchg(y, 0, 1); + r2 =3D READ_ONCE(*x); +} + +exists (0:r1=3D0 /\ 1:r1=3D1 /\ 1:r2=3D0) --=20 2.40.1 From nobody Mon Feb 9 03:52:17 2026 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 56699135A5C; Thu, 4 Apr 2024 19:26:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712258812; cv=none; b=QHesjsBH7tzMOcype03eMzq9vckLVJVim2+aEXftRwfTmZvCJv1TnCF7f5pMate4F7PsFH7qh6uTeoOJjwzmkgJQta2mMnYc1kg7zFneEmvYlvQVO2pwvi5INojTmrbabGQwQBDc4nXHbK4yU9Y4Q9l6+ZqWOMJsimQcfwK0H7c= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1712258812; c=relaxed/simple; bh=tN99QeAtJ9rSCHUuXKIZr5kPNcQaT1UKModjibckfc0=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=qRhHp33iyenvwrF8/glXtCDxK4ZEONkblJEmUWCSJflDZFvEJpLJu/nLj0Vk7RSbUTJCSAOv9OFMYbf9tkttgItZHCmsoE0XloflssQdmy6f2/QHxv9ZM/HLxYIGMrMOruQyP8YjJt35e6+NonTPR8eeIj3qQ8wLKALLWdSmEAE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=qT22pEbP; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="qT22pEbP" Received: by smtp.kernel.org (Postfix) with ESMTPSA id EDEC7C433A6; Thu, 4 Apr 2024 19:26:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1712258812; bh=tN99QeAtJ9rSCHUuXKIZr5kPNcQaT1UKModjibckfc0=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=qT22pEbP/E2OyGwVmTYn6ssiRlW0RAqkAHI9aW112G6dZKGZ9fd42U+fUw7SJrzsd tHHUXWOy8nzUcvRDlHdyVUxxUn0T0cEE0QIaC3lNqQoowL0b7cv6glRyXNqNoId9+l fwEUIGRluAnCAYwKPH9a5zln4a7yXL9tT0OzrL3ntFYUPNXv/AzhMQTsge16ohyyWH r420UN+KjmJY+ICpoCD95byx65G1HNVlKGDeueiKpxkQavXt8iojAdjhsBtNL4Jq8Z JBv5mFEaY14qc2B6OYijDeijlDeaQir9ID/mU8WoBJnDkiI0Q3OqEFwsPuSH2zoLka gPALKQ6pNIUqw== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 98770CE13D0; Thu, 4 Apr 2024 12:26:51 -0700 (PDT) From: "Paul E. McKenney" To: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, kernel-team@meta.com, mingo@kernel.org Cc: stern@rowland.harvard.edu, parri.andrea@gmail.com, will@kernel.org, peterz@infradead.org, boqun.feng@gmail.com, npiggin@gmail.com, dhowells@redhat.com, j.alglave@ucl.ac.uk, luc.maranget@inria.fr, akiyks@gmail.com, "Paul E. McKenney" , Anna-Maria Behnsen , Daniel Lustig , Joel Fernandes , Mark Rutland , Jonathan Corbet , linux-doc@vger.kernel.org Subject: [PATCH memory-model 3/3] Documentation/atomic_t: Emphasize that failed atomic operations give no ordering Date: Thu, 4 Apr 2024 12:26:49 -0700 Message-Id: <20240404192649.531112-3-paulmck@kernel.org> X-Mailer: git-send-email 2.40.1 In-Reply-To: <8550daf1-4bfd-4607-8325-bfb7c1e2d8c7@paulmck-laptop> References: <8550daf1-4bfd-4607-8325-bfb7c1e2d8c7@paulmck-laptop> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" 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() suffixes. 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 Signed-off-by: Paul E. McKenney Cc: Alan Stern Cc: Will Deacon Cc: Peter Zijlstra Cc: Boqun Feng Cc: Nicholas Piggin Cc: David Howells Cc: Jade Alglave Cc: Luc Maranget Cc: "Paul E. McKenney" Cc: Akira Yokosawa Cc: Daniel Lustig Cc: Joel Fernandes Cc: Mark Rutland Cc: Jonathan Corbet Cc: Cc: Acked-by: Andrea Parri Acked-by: Mark Rutland --- Documentation/atomic_t.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) 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. =20 -Except of course when an operation has an explicit ordering like: +Except of course when a successful operation has an explicit ordering like: =20 {}_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 =20 Where 'unordered' is against other memory locations. Address dependencies = are -not defeated. +not defeated. Conditional operations are still unordered on FAILURE. =20 Fully ordered primitives are ordered against everything prior and everythi= ng subsequent. Therefore a fully ordered primitive is like having an smp_mb() --=20 2.40.1