From: Andrea Parri <parri.andrea@gmail.com>
To: Jonas Oberhauser <jonas.oberhauser@huaweicloud.com>
Cc: Alan Stern <stern@rowland.harvard.edu>,
"Paul E. McKenney" <paulmck@kernel.org>,
linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
kernel-team@meta.com, mingo@kernel.org, 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, Frederic Weisbecker <frederic@kernel.org>,
Daniel Lustig <dlustig@nvidia.com>,
Joel Fernandes <joel@joelfernandes.org>,
Mark Rutland <mark.rutland@arm.com>,
Jonathan Corbet <corbet@lwn.net>,
linux-doc@vger.kernel.org
Subject: Re: [PATCH memory-model 2/4] Documentation/litmus-tests: Demonstrate unordered failing cmpxchg
Date: Wed, 8 May 2024 03:17:15 +0200 [thread overview]
Message-ID: <ZjrSm119+IfIU9eU@andrea> (raw)
In-Reply-To: <fd2369ed-1e84-4e44-ac80-cd316f8e7051@huaweicloud.com>
> > Don't the annotations in linux-kernel.def and linux-kernel.bell (like
> > "noreturn") already make this explicit?
>
> Not that I'm aware. All I can see there is that according to .bell RMW don't
> have an mb mode, but according to .def they do.
>
> How this mb disappears between parsing the code (.def) and interpreting it
> (.bell) is totally implicit. Including how noreturn affects this
> disappeareance.
IIRC, that's more or less implicit ;-) in the herd macros of the .def file;
for example,
(noreturn)
- atomic_add(V,X) { __atomic_op(X,+,V); }
Generates a pair of R*[noreturn] and W*[once] events
(w/ return)
- atomic_add_return_relaxed(V,X) __atomic_op_return{once}(X,+,V)
Generates a pair of R*[once] and W*[once] events
- atomic_add_return_acquire(V,X) __atomic_op_return{acquire}(X,+,V)
Generates a pair of R*[acquire] and W*[once] events
- atomic_add_return_release(V,X) __atomic_op_return{acquire}(X,+,V)
Generates a pair of R*[once] and W*[release] events
- atomic_add_return(V,X) __atomic_op_return{mb}(X,+,V)
Generates a pair of R*[once] and W*[once] events plus two F[mb] events
(possibly failing)
- atomic_cmpxchg_relaxed(X,V,W) __cmpxchg{once}(X,V,W)
Generates a pair of R*[once] and W*[once] events if successful;
a single R*[once] event otherwise.
- atomic_cmpxchg_acquire(X,V,W) __cmpxchg{acquire}(X,V,W)
Generates a pair of R*[acquire] and W*[once] events if successful;
a single R*[once] event otherwise.
- atomic_cmpxchg_release(X,V,W) __cmpxchg{release}(X,V,W)
Generates a pair of R*[once] and W*[release] events if successful;
a single R*[once] event otherwise.
- atomic_cmpxchg(X,V,W) __cmpxchg{mb}(X,V,W)
Generates a pair of R*[once] and W*[once] events plus two F[mb] events
if successful; a single R*[once] event otherwise.
The line
instructions RMW[{'once,'acquire,'release}]
in the .bell file seems to be effectively redundant (perhaps a LISA backward
-compatibility?): consider
$ cat rmw.litmus
C rmw
{}
P0(atomic_t *x)
{
int r0;
r0 = atomic_inc_return_release(x);
}
exists (x=1)
Some experiments:
- Upon removing 'release from "(instructions) RMW"
$ herd7 -conf linux-kernel.cfg rmw.litmus
Test rmw Allowed
States 1
[x]=1;
Ok
Witnesses
Positive: 1 Negative: 0
Condition exists ([x]=1)
Observation rmw Always 1 0
Time rmw 0.00
Hash=3a2dd354c250206d993d31f05f3f595c
- Upon restoring 'release in RMW and removing it from W
$ herd7 -conf linux-kernel.cfg rmw.litmus
Test rmw Allowed
States 1
[x]=1;
Ok
Witnesses
Positive: 1 Negative: 0
Condition exists ([x]=1)
Observation rmw Always 1 0
Time rmw 0.00
Hash=3a2dd354c250206d993d31f05f3f595c
- Upon removing 'release from both W and RMW
$ herd7 -conf linux-kernel.cfg rmw.litmus (herd complains... )
File "./linux-kernel.bell", line 76, characters 32-39: unbound var: Release
But I'd have to defer to Luc/Jade about herd internals and/or recommended style
on this matter.
Andrea
next prev parent reply other threads:[~2024-05-08 1:17 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-04 19:26 [PATCH memory-model 0/3] LKMM updates for v6.10 Paul E. McKenney
2024-04-04 19:26 ` [PATCH memory-model 1/3] Documentation/litmus-tests: Add locking tests to README Paul E. McKenney
2024-04-04 19:26 ` [PATCH memory-model 2/3] Documentation/litmus-tests: Demonstrate unordered failing cmpxchg Paul E. McKenney
2024-04-05 10:05 ` Andrea Parri
2024-04-08 20:46 ` Paul E. McKenney
2024-04-09 10:43 ` Andrea Parri
2024-04-04 19:26 ` [PATCH memory-model 3/3] Documentation/atomic_t: Emphasize that failed atomic operations give no ordering Paul E. McKenney
2024-05-01 23:21 ` [PATCH v2 memory-model 0/3] LKMM updates for v6.10 Paul E. McKenney
2024-05-01 23:21 ` [PATCH memory-model 1/4] Documentation/litmus-tests: Add locking tests to README Paul E. McKenney
2024-05-01 23:21 ` [PATCH memory-model 2/4] Documentation/litmus-tests: Demonstrate unordered failing cmpxchg Paul E. McKenney
2024-05-06 10:05 ` Jonas Oberhauser
2024-05-06 16:30 ` Jonas Oberhauser
2024-05-06 18:00 ` Paul E. McKenney
2024-05-06 19:21 ` Alan Stern
2024-05-07 9:03 ` Jonas Oberhauser
2024-05-08 1:17 ` Andrea Parri [this message]
2024-05-07 9:11 ` Jonas Oberhauser
2024-05-15 6:44 ` Hernan Ponce de Leon
2024-05-15 15:01 ` Paul E. McKenney
2024-05-01 23:21 ` [PATCH memory-model 3/4] Documentation/atomic_t: Emphasize that failed atomic operations give no ordering Paul E. McKenney
2024-05-01 23:21 ` [PATCH memory-model 4/4] Documentation/litmus-tests: Make cmpxchg() tests safe for klitmus Paul E. McKenney
2024-05-02 9:36 ` [PATCH v2 memory-model 0/3] LKMM updates for v6.10 Andrea Parri
2024-05-02 13:46 ` 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=ZjrSm119+IfIU9eU@andrea \
--to=parri.andrea@gmail.com \
--cc=akiyks@gmail.com \
--cc=boqun.feng@gmail.com \
--cc=corbet@lwn.net \
--cc=dhowells@redhat.com \
--cc=dlustig@nvidia.com \
--cc=frederic@kernel.org \
--cc=j.alglave@ucl.ac.uk \
--cc=joel@joelfernandes.org \
--cc=jonas.oberhauser@huaweicloud.com \
--cc=kernel-team@meta.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luc.maranget@inria.fr \
--cc=mark.rutland@arm.com \
--cc=mingo@kernel.org \
--cc=npiggin@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 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 read-only IMAP folder(s) and NNTP newsgroup(s).