05 Sep, 2020
1 commit
-
This commit adds a key entry enumerating the various types of relaxed
operations. While in the area, it also renames the relaxed rows.[ paulmck: Apply Boqun Feng feedback. ]
Acked-by: Boqun Feng
Signed-off-by: Paul E. McKenney
04 Sep, 2020
4 commits
-
Current LKMM documentation assumes that the reader already understands
concurrency in the Linux kernel, which won't necessarily always be the
case. This commit supplies a simple.txt file that provides a starting
point for someone who is new to concurrency in the Linux kernel.
That said, this file might also useful as a reminder to experienced
developers of simpler approaches to dealing with concurrency.Link: Link: https://lwn.net/Articles/827180/
[ paulmck: Apply feedback from Joel Fernandes. ]
Co-developed-by: Dave Chinner
Signed-off-by: Dave Chinner
Co-developed-by: Paul E. McKenney
Signed-off-by: Paul E. McKenney -
The current LKMM documentation says very little about litmus tests, and
worse yet directs people to the herd7 documentation for more information.
Now, the herd7 documentation is quite voluminous and educational,
but it is intended for people creating and modifying memory models,
not those attempting to use them.This commit therefore updates README and creates a litmus-tests.txt
file that gives an overview of litmus-test format and describes ways of
modeling various special cases, illustrated with numerous examples.[ paulmck: Add Alan Stern feedback. ]
[ paulmck: Apply Dave Chinner feedback. ]
[ paulmck: Apply Andrii Nakryiko feedback. ]
[ paulmck: Apply Johannes Weiner feedback. ]
Link: https://lwn.net/Articles/827180/
Reported-by: Dave Chinner
Acked-by: Peter Zijlstra (Intel)
Signed-off-by: Paul E. McKenney -
The expand_to_next_prime() and next_prime_number() functions have moved
from lib/prime_numbers.c to lib/math/prime_numbers.c, so this commit
updates recipes.txt to reflect this change.Signed-off-by: Paul E. McKenney
-
Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.Deterministic algorithm:
For each file:
If not .svg:
For each line:
If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
Replace HTTP with HTTPS.Signed-off-by: Alexander A. Klimov
Signed-off-by: Paul E. McKenney
04 Aug, 2020
1 commit
-
Pull locking updates from Ingo Molnar:
- LKMM updates: mostly documentation changes, but also some new litmus
tests for atomic ops.- KCSAN updates: the most important change is that GCC 11 now has all
fixes in place to support KCSAN, so GCC support can be enabled again.
Also more annotations.- futex updates: minor cleanups and simplifications
- seqlock updates: merge preparatory changes/cleanups for the
'associated locks' facilities.- lockdep updates:
- simplify IRQ trace event handling
- add various new debug checks
- simplify header dependencies, split out ,
decouple lockdep from other low level headers some more
- fix NMI handling- misc cleanups and smaller fixes
* tag 'locking-core-2020-08-03' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (60 commits)
kcsan: Improve IRQ state trace reporting
lockdep: Refactor IRQ trace events fields into struct
seqlock: lockdep assert non-preemptibility on seqcount_t write
lockdep: Add preemption enabled/disabled assertion APIs
seqlock: Implement raw_seqcount_begin() in terms of raw_read_seqcount()
seqlock: Add kernel-doc for seqcount_t and seqlock_t APIs
seqlock: Reorder seqcount_t and seqlock_t API definitions
seqlock: seqcount_t latch: End read sections with read_seqcount_retry()
seqlock: Properly format kernel-doc code samples
Documentation: locking: Describe seqlock design and usage
locking/qspinlock: Do not include atomic.h from qspinlock_types.h
locking/atomic: Move ATOMIC_INIT into linux/types.h
lockdep: Move list.h inclusion into lockdep.h
locking/lockdep: Fix TRACE_IRQFLAGS vs. NMIs
futex: Remove unused or redundant includes
futex: Consistently use fshared as boolean
futex: Remove needless goto's
futex: Remove put_futex_key()
rwsem: fix commas in initialisation
docs: locking: Replace HTTP links with HTTPS ones
...
21 Jul, 2020
1 commit
-
smp_read_barrier_depends() has gone the way of mmiowb() and so many
esoteric memory barriers before it. Drop the two mentions of this
deceased barrier from the LKMM informal explanation document.Acked-by: Peter Zijlstra (Intel)
Acked-by: Alan Stern
Acked-by: Paul E. McKenney
Signed-off-by: Will Deacon
30 Jun, 2020
6 commits
-
herdtools7 7.56 is going to be released in the week of 22 Jun 2020.
This commit therefore adds the exact version in the compatibility table.Acked-by: Andrea Parri
Signed-off-by: Akira Yokosawa
Signed-off-by: Paul E. McKenney -
klitmus7 is independent of the memory model but depends on the
build-target kernel release.
It occasionally lost compatibility due to kernel API changes [1, 2, 3].
It was remedied in a backwards-compatible manner respectively [4, 5, 6].Reflect this fact in README.
[1]: b899a850431e ("compiler.h: Remove ACCESS_ONCE()")
[2]: 0bb95f80a38f ("Makefile: Globally enable VLA warning")
[3]: d56c0d45f0e2 ("proc: decouple proc from VFS with "struct proc_ops"")
[4]: https://github.com/herd/herdtools7/commit/e87d7f9287d1
("klitmus: Use WRITE_ONCE and READ_ONCE in place of deprecated ACCESS_ONCE")
[5]: https://github.com/herd/herdtools7/commit/a0cbb10d02be
("klitmus: Avoid variable length array")
[6]: https://github.com/herd/herdtools7/commit/46b9412d3a58
("klitmus: Linux kernel v5.6.x compat")NOTE: [5] was ahead of herdtools7 7.53, which did not make an
official release. Code generated by klitmus7 without [5] can still be
built targeting Linux 4.20--5.5 if you don't care VLA warnings.Acked-by: Andrea Parri
Signed-off-by: Akira Yokosawa
Signed-off-by: Paul E. McKenney -
The name of litmus test doesn't match the one described below.
Fix the name of litmus test.Acked-by: Andrea Parri
Acked-by: Joel Fernandes (Google)
Signed-off-by: Akira Yokosawa
Signed-off-by: Paul E. McKenney -
According to Luc, atomic_add_unless() is directly provided by herd7,
therefore it can be used in litmus tests. So change the limitation
section in README to unlimit the use of atomic_add_unless().Cc: Luc Maranget
Acked-by: Andrea Parri
Reviewed-by: Joel Fernandes (Google)
Signed-off-by: Boqun Feng
Signed-off-by: Paul E. McKenney -
The definition of "conflict" should not include the type of access nor
whether the accesses are concurrent or not, which this patch addresses.
The definition of "data race" remains unchanged.The definition of "conflict" as we know it and is cited by various
papers on memory consistency models appeared in [1]: "Two accesses to
the same variable conflict if at least one is a write; two operations
conflict if they execute conflicting accesses."The LKMM as well as the C11 memory model are adaptations of
data-race-free, which are based on the work in [2]. Necessarily, we need
both conflicting data operations (plain) and synchronization operations
(marked). For example, C11's definition is based on [3], which defines a
"data race" as: "Two memory operations conflict if they access the same
memory location, and at least one of them is a store, atomic store, or
atomic read-modify-write operation. In a sequentially consistent
execution, two memory operations from different threads form a type 1
data race if they conflict, at least one of them is a data operation,
and they are adjacent in
Co-developed-by: Alan Stern
Signed-off-by: Alan Stern
Acked-by: Andrea Parri
Signed-off-by: Paul E. McKenney -
This commit updates the list of LKMM-related publications in
Documentation/references.txt.Signed-off-by: Paul E. McKenney
Acked-by: Andrea Parri
25 Mar, 2020
1 commit
-
Add SPDX License Identifier to all .gitignore files.
Signed-off-by: Masahiro Yamada
Signed-off-by: Greg Kroah-Hartman
06 Oct, 2019
4 commits
-
This patch updates the Linux Kernel Memory Model's explanation.txt
file by adding a section devoted to the model's handling of plain
accesses and data-race detection.Signed-off-by: Alan Stern
Acked-by: Andrea Parri
Signed-off-by: Paul E. McKenney -
This patch updates the Linux Kernel Memory Model's explanation.txt
file to incorporate the introduction of the rcu-order relation and
the redefinition of rcu-fence made by commit 15aa25cbf0cc
("tools/memory-model: Change definition of rcu-fence").Signed-off-by: Alan Stern
Acked-by: Andrea Parri
Signed-off-by: Paul E. McKenney -
This patch fixes a few minor typos and improves word usage in a few
places in the Linux Kernel Memory Model's explanation.txt file.Signed-off-by: Alan Stern
Reviewed-by: Joel Fernandes (Google)
Acked-by: Andrea Parri
Signed-off-by: Paul E. McKenney -
Currently the Linux Kernel Memory Model gives an incorrect response
for the following litmus test:C plain-WWC
{}
P0(int *x)
{
WRITE_ONCE(*x, 2);
}P1(int *x, int *y)
{
int r1;
int r2;
int r3;r1 = READ_ONCE(*x);
if (r1 == 2) {
smp_rmb();
r2 = *x;
}
smp_rmb();
r3 = READ_ONCE(*x);
WRITE_ONCE(*y, r3 - 1);
}P2(int *x, int *y)
{
int r4;r4 = READ_ONCE(*y);
if (r4 > 0)
WRITE_ONCE(*x, 1);
}exists (x=2 /\ 1:r2=2 /\ 2:r4=1)
The memory model says that the plain read of *x in P1 races with the
WRITE_ONCE(*x) in P2.The problem is that we have a write W and a read R related by neither
fre or rfe, but rather W ->coe W' ->rfe R, where W' is an intermediate
write (the WRITE_ONCE() in P0). In this situation there is no
particular ordering between W and R, so either a wr-vis link from W to
R or an rw-xbstar link from R to W would prove that the accesses
aren't concurrent.But the LKMM only looks for a wr-vis link, which is equivalent to
assuming that W must execute before R. This is not necessarily true
on non-multicopy-atomic systems, as the WWC pattern demonstrates.This patch changes the LKMM to accept either a wr-vis or a reverse
rw-xbstar link as a proof of non-concurrency.Signed-off-by: Alan Stern
Acked-by: Andrea Parri
Signed-off-by: Paul E. McKenney
10 Aug, 2019
2 commits
-
The formal memory consistency model has added support for plain accesses
(and data races). While updating the informal documentation to describe
this addition to the model is highly desirable and important future work,
update the informal documentation to at least acknowledge such addition.Signed-off-by: Andrea Parri
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
Signed-off-by: Paul E. McKenney
Acked-by: Alan Stern -
To reduce ambiguity in the more exotic ->prop ordering example, this
commit uses the term cumul-fence instead of the term fence for the two
fences, so that the implict ->rfe on loads/stores to Y are covered by
the description.Link: https://lore.kernel.org/lkml/20190729121745.GA140682@google.com
Suggested-by: Alan Stern
Signed-off-by: Joel Fernandes (Google)
Acked-by: Alan Stern
Signed-off-by: Paul E. McKenney
01 Aug, 2019
1 commit
-
This commit simplifies life a bit by making all of the scripts in
tools/memory-model/scripts be executable.Signed-off-by: Paul E. McKenney
25 Jun, 2019
1 commit
-
Herbert Xu recently reported a problem concerning RCU and compiler
barriers. In the course of discussing the problem, he put forth a
litmus test which illustrated a serious defect in the Linux Kernel
Memory Model's data-race-detection code [1].The defect was that the LKMM assumed visibility and executes-before
ordering of plain accesses had to be mediated by marked accesses. In
Herbert's litmus test this wasn't so, and the LKMM claimed the litmus
test was allowed and contained a data race although neither is true.In fact, plain accesses can be ordered by fences even in the absence
of marked accesses. In most cases this doesn't matter, because most
fences only order accesses within a single thread. But the rcu-fence
relation is different; it can order (and induce visibility between)
accesses in different threads -- events which otherwise might be
concurrent. This makes it relevant to data-race detection.This patch makes two changes to the memory model to incorporate the
new insight:If a store is separated by a fence from another access,
the store is necessarily visible to the other access (as
reflected in the ww-vis and wr-vis relations). Similarly,
if a load is separated by a fence from another access then
the load necessarily executes before the other access (as
reflected in the rw-xbstar relation).If a store is separated by a strong fence from a marked access
then it is necessarily visible to any access that executes
after the marked access (as reflected in the ww-vis and wr-vis
relations).With these changes, the LKMM gives the desired result for Herbert's
litmus test and other related ones [2].[1] https://lore.kernel.org/lkml/Pine.LNX.4.44L0.1906041026570.1731-100000@iolanthe.rowland.org/
[2] https://github.com/paulmckrcu/litmus/blob/master/manual/plain/C-S-rcunoderef-1.litmus
https://github.com/paulmckrcu/litmus/blob/master/manual/plain/C-S-rcunoderef-2.litmus
https://github.com/paulmckrcu/litmus/blob/master/manual/plain/C-S-rcunoderef-3.litmus
https://github.com/paulmckrcu/litmus/blob/master/manual/plain/C-S-rcunoderef-4.litmus
https://github.com/paulmckrcu/litmus/blob/master/manual/plain/strong-vis.litmusReported-by: Herbert Xu
Signed-off-by: Alan Stern
Acked-by: Andrea Parri
Signed-off-by: Paul E. McKenney
Tested-by: Akira Yokosawa
22 Jun, 2019
2 commits
-
The rcu-fence relation in the Linux Kernel Memory Model is not well
named. It doesn't act like any other fence relation, in that it does
not relate events before a fence to events after that fence. All it
does is relate certain RCU events to one another (those that are
ordered by the RCU Guarantee); this induces an actual
strong-fence-like relation linking events preceding the first RCU
event to those following the second.This patch renames rcu-fence, now called rcu-order. It adds a new
definition of rcu-fence, something which should have been present all
along because it is used in the rb relation. And it modifies the
fence and strong-fence relations by making them incorporate the new
rcu-fence.As a result of this change, there is no longer any need to define
full-fence in the section for detecting data races. It can simply be
replaced by the updated strong-fence relation.This change should have no effect on the operation of the memory model.
Signed-off-by: Alan Stern
Acked-by: Andrea Parri
Signed-off-by: Paul E. McKenney -
Commit 66be4e66a7f4 ("rcu: locking and unlocking need to always be at
least barriers") added compiler barriers back into rcu_read_lock() and
rcu_read_unlock(). Furthermore, srcu_read_lock() and
srcu_read_unlock() have always contained compiler barriers.The Linux Kernel Memory Model ought to know about these barriers.
This patch adds them into the memory model.Signed-off-by: Alan Stern
Acked-by: Andrea Parri
Signed-off-by: Paul E. McKenney
20 Jun, 2019
2 commits
-
Use "herd7" in each such reference.
Signed-off-by: Andrea Parri
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
Acked-by: Alan Stern
Signed-off-by: Paul E. McKenney -
The comment should say "Sometimes" for the result.
Signed-off-by: Andrea Parri
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
Acked-by: Alan Stern
Signed-off-by: Paul E. McKenney
28 May, 2019
3 commits
-
This patch adds data-race detection to the Linux-Kernel Memory Model.
As part of this effort, support is added for:compiler barriers (the barrier() function), and
a new Preserved Program Order term: (addr ; [Plain] ; wmb)
Data races are marked with a special Flag warning in herd. It is
not guaranteed that the model will provide accurate predictions when a
data race is present.The patch does not include documentation for the data-race detection
facility. The basic design has been explained in various emails, and
a separate documentation patch will be submitted later.This work is based on an earlier formulation of data races for the
LKMM by Andrea Parri.Signed-off-by: Alan Stern
Reviewed-by: Andrea Parri
Signed-off-by: Paul E. McKenney -
This patch adds definitions for marked and plain accesses to the
Linux-Kernel Memory Model. It also modifies the definitions of the
existing parts of the model (including the cumul-fence, prop, hb, pb,
and rb relations) so as to make them apply only to marked accesses.Signed-off-by: Alan Stern
Reviewed-by: Andrea Parri
Signed-off-by: Paul E. McKenney -
This patch makes some slight alterations to linux-kernel.cat in
preparation for adding support for data-race detection to the
Linux-Kernel Memory Model.The definitions of relations involved in Acquire, Release, and
unlock-lock ordering are moved up earlier in the source file.The rmb relation is factored through the new R4rmb class: the
class of reads to which rmb will apply.The definition of the fence relation is moved earlier, and it
is split up into read- and write-fences (rmb and wmb) and all
the others.This should not make any functional changes.
Signed-off-by: Alan Stern
Reviewed-by: Andrea Parri
Signed-off-by: Paul E. McKenney
05 Apr, 2019
1 commit
-
Given that synchronize_rcu_expedited() is supported, this commit adds
support for synchronize_srcu_expedited().Signed-off-by: Paul E. McKenney
Acked-by: Andrea Parri
19 Mar, 2019
7 commits
-
Currently, herdtools version information appears no fewer than three
times in the LKMM source, which is difficult to maintain. This commit
therefore places the required version in one place, namely the
tools/memory-model/README file.Signed-off-by: Andrea Parri
Signed-off-by: Paul E. McKenney
Acked-by: Alan Stern -
This commit checks that the return value of srcu_read_lock() is passed
to the matching srcu_read_unlock(), where "matching" is determined by
nesting. This check operates as follows:1. srcu_read_lock() creates an integer token, which is stored into
the generated events.
2. srcu_read_unlock() records its second (token) argument into the
generated event.
3. A new herd primitive 'different-values' filters out pairs of events
with identical values from the relation passed as its argument.
4. The bell file applies the above primitive to the (srcu)
read-side-critical-section relation 'srcu-rscs' and flags non-empty
results.BEWARE: Works only with herd version 7.51+6 and onwards.
Signed-off-by: Luc Maranget
Signed-off-by: Paul E. McKenney
[ paulmck: Apply Andrea Parri's off-list feedback. ]
Acked-by: Alan Stern -
The recent commit adding support for SRCU to the Linux Kernel Memory
Model ended up changing the names and meanings of several relations.
This patch updates the explanation.txt documentation file to reflect
those changes.It also revises the statement of the RCU Guarantee to a more accurate
form, and it adds a short paragraph mentioning the new support for SRCU.Signed-off-by: Alan Stern
Cc: Akira Yokosawa
Cc: Andrea Parri
Cc: Boqun Feng
Cc: Daniel Lustig
Cc: David Howells
Cc: Jade Alglave
Cc: Luc Maranget
Cc: Nicholas Piggin
Cc: "Paul E. McKenney"
Cc: Peter Zijlstra
Cc: Will Deacon
Signed-off-by: Paul E. McKenney
Acked-by: Andrea Parri -
This commit updates the section on LKMM limitations to no longer say
that SRCU is not modeled, but instead describe how LKMM's modeling of
SRCU departs from the Linux-kernel implementation.TL;DR: There is no known valid use case that cares about the Linux
kernel's ability to have partially overlapping SRCU read-side critical
sections.Signed-off-by: Paul E. McKenney
Acked-by: Andrea Parri -
Add support for SRCU. Herd creates srcu events and linux-kernel.def
associates them with three possible annotations (srcu-lock,
srcu-unlock, and sync-srcu) corresponding to the API routines
srcu_read_lock(), srcu_read_unlock(), and synchronize_srcu().The linux-kernel.bell file now declares the annotations
and determines matching lock/unlock pairs delimiting SRCU read-side
critical sections, and it also checks for synchronize_srcu() calls
inside an RCU critical section (which would generate a "sleeping in
atomic context" error in real kernel code). The linux-kernel.cat file
now adds SRCU-induced ordering, analogous to the existing RCU-induced
ordering, to the gp and rcu-fence relations.Curiously enough, these small changes to the model's .cat code are all
that is needed to describe SRCU.Portions of this patch (linux-kernel.def and the first hunk in
linux-kernel.bell) were written by Luc Maranget.Signed-off-by: Alan Stern
CC: Luc Maranget
Signed-off-by: Paul E. McKenney
Tested-by: Andrea Parri -
In preparation for adding support for SRCU, refactor the definitions
of rcu-fence, rcu-rscsi, rcu-link, and rb by moving the po and po?
terms from the first two to the second two. An rcu-gp relation is
added; it is equivalent to gp with the po and po? terms removed.This is necessary because for SRCU, we will have to use the loc
relation to check that the terms at the start and end of each disjunct
in the definition of rcu-fence refer to the same srcu_struct
location. If these terms are hidden behind po and po?, there's no way
to carry out this check.Signed-off-by: Alan Stern
Signed-off-by: Paul E. McKenney
Tested-by: Andrea Parri -
In preparation for adding support for SRCU, rename "crit" to
"rcu-rscs", rename "rscs" to "rcu-rscsi", and remove the restriction
to only the outermost level of nesting.The name change is needed for disambiguating RCU read-side critical
sections from SRCU read-side critical sections. Adding the "i" at the
end of "rcu-rscsi" emphasizes that the relation is inverted; it links
rcu_read_unlock() events to their corresponding preceding
rcu_read_lock() events.The restriction to outermost nesting levels was never essential; it
was included mostly to show that it could be done. Rather than add
equivalent unnecessary code for SRCU lock nesting, it seemed better to
remove the existing code.Signed-off-by: Alan Stern
Signed-off-by: Paul E. McKenney
Tested-by: Andrea Parri
21 Jan, 2019
3 commits
-
The "--jobs" argument to the litmus-test scripts is similar to the "-jN"
argument to "make", so this commit allows the "-jN" form as well. While
in the area, it also prohibits the various forms of "-j0".Suggested-by: Alan Stern
Signed-off-by: Paul E. McKenney
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: akiyks@gmail.com
Cc: boqun.feng@gmail.com
Cc: dhowells@redhat.com
Cc: j.alglave@ucl.ac.uk
Cc: linux-arch@vger.kernel.org
Cc: luc.maranget@inria.fr
Cc: npiggin@gmail.com
Cc: parri.andrea@gmail.com
Cc: will.deacon@arm.com
Link: http://lkml.kernel.org/r/20181203230451.28921-3-paulmck@linux.ibm.com
Signed-off-by: Ingo Molnar -
The https://github.com/paulmckrcu/litmus repository contains a large
number of C-language litmus tests that include "Result:" comments
predicting the verification result. This commit adds a number of scripts
that run tests on these litmus tests:checkghlitmus.sh:
Runs all litmus tests in the https://github.com/paulmckrcu/litmus
archive that are C-language and that have "Result:" comment lines
documenting expected results, comparing the actual results to
those expected. Clones the repository if it has not already
been cloned into the "tools/memory-model/litmus" directory.initlitmushist.sh
Run all litmus tests having no more than the specified number
of processes given a specified timeout, recording the results in
.litmus.out files. Clones the repository if it has not already
been cloned into the "tools/memory-model/litmus" directory.newlitmushist.sh
For all new or updated litmus tests having no more than the
specified number of processes given a specified timeout, run
and record the results in .litmus.out files.checklitmushist.sh
Run all litmus tests having .litmus.out files from previous
initlitmushist.sh or newlitmushist.sh runs, comparing the
herd output to that of the original runs.The above scripts will run litmus tests concurrently, by default with
one job per available CPU. Giving any of these scripts the --help
argument will cause them to print usage information.This commit also adds a number of helper scripts that are not intended
to be invoked from the command line:cmplitmushist.sh: Compare the output of two different runs of the same
litmus test.judgelitmus.sh: Compare the output of a litmus test to its "Result:"
comment line.parseargs.sh: Parse command-line arguments.
runlitmushist.sh: Run the litmus tests whose pathnames are provided one
per line on standard input.While in the area, this commit also makes the existing checklitmus.sh
and checkalllitmus.sh scripts use parseargs.sh in order to provide a
bit of uniformity. In addition, per-litmus-test status output is directed
to stdout, while end-of-test summary information is directed to stderr.
Finally, the error flag standardizes on "!!!" to assist those familiar
with rcutorture output.The defaults for the parseargs.sh arguments may be overridden by using
environment variables: LKMM_DESTDIR for --destdir, LKMM_HERD_OPTIONS
for --herdoptions, LKMM_JOBS for --jobs, LKMM_PROCS for --procs, and
LKMM_TIMEOUT for --timeout.[ paulmck: History-check summary-line changes per Alan Stern feedback. ]
Signed-off-by: Paul E. McKenney
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: akiyks@gmail.com
Cc: boqun.feng@gmail.com
Cc: dhowells@redhat.com
Cc: j.alglave@ucl.ac.uk
Cc: linux-arch@vger.kernel.org
Cc: luc.maranget@inria.fr
Cc: npiggin@gmail.com
Cc: parri.andrea@gmail.com
Cc: stern@rowland.harvard.edu
Cc: will.deacon@arm.com
Link: http://lkml.kernel.org/r/20181203230451.28921-2-paulmck@linux.ibm.com
Signed-off-by: Ingo Molnar -
The kernel documents smp_mb__after_unlock_lock() the following way:
"Place this after a lock-acquisition primitive to guarantee that
an UNLOCK+LOCK pair acts as a full barrier. This guarantee applies
if the UNLOCK and LOCK are executed by the same CPU or if the
UNLOCK and LOCK operate on the same lock variable."Formalize in LKMM the above guarantee by defining (new) mb-links according
to the law:([M] ; po ; [UL] ; (co | po) ; [LKW] ;
fencerel(After-unlock-lock) ; [M])where the component ([UL] ; co ; [LKW]) identifies "UNLOCK+LOCK pairs on
the same lock variable" and the component ([UL] ; po ; [LKW]) identifies
"UNLOCK+LOCK pairs executed by the same CPU".In particular, the LKMM forbids the following two behaviors (the second
litmus test below is based on:Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.html
c.f., Section "Tree RCU Grace Period Memory Ordering Building Blocks"):
C after-unlock-lock-same-cpu
(*
* Result: Never
*){}
P0(spinlock_t *s, spinlock_t *t, int *x, int *y)
{
int r0;spin_lock(s);
WRITE_ONCE(*x, 1);
spin_unlock(s);
spin_lock(t);
smp_mb__after_unlock_lock();
r0 = READ_ONCE(*y);
spin_unlock(t);
}P1(int *x, int *y)
{
int r0;WRITE_ONCE(*y, 1);
smp_mb();
r0 = READ_ONCE(*x);
}exists (0:r0=0 /\ 1:r0=0)
C after-unlock-lock-same-lock-variable
(*
* Result: Never
*){}
P0(spinlock_t *s, int *x, int *y)
{
int r0;spin_lock(s);
WRITE_ONCE(*x, 1);
r0 = READ_ONCE(*y);
spin_unlock(s);
}P1(spinlock_t *s, int *y, int *z)
{
int r0;spin_lock(s);
smp_mb__after_unlock_lock();
WRITE_ONCE(*y, 1);
r0 = READ_ONCE(*z);
spin_unlock(s);
}P2(int *z, int *x)
{
int r0;WRITE_ONCE(*z, 1);
smp_mb();
r0 = READ_ONCE(*x);
}exists (0:r0=0 /\ 1:r0=0 /\ 2:r0=0)
Signed-off-by: Andrea Parri
Signed-off-by: Paul E. McKenney
Cc: Akira Yokosawa
Cc: Alan Stern
Cc: Boqun Feng
Cc: Daniel Lustig
Cc: David Howells
Cc: Jade Alglave
Cc: Linus Torvalds
Cc: Luc Maranget
Cc: Nicholas Piggin
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: Will Deacon
Cc: linux-arch@vger.kernel.org
Cc: parri.andrea@gmail.com
Link: http://lkml.kernel.org/r/20181203230451.28921-1-paulmck@linux.ibm.com
Signed-off-by: Ingo Molnar
