05 Sep, 2017
1 commit
-
Pull locking updates from Ingo Molnar:
- Add 'cross-release' support to lockdep, which allows APIs like
completions, where it's not the 'owner' who releases the lock, to be
tracked. It's all activated automatically under
CONFIG_PROVE_LOCKING=y.- Clean up (restructure) the x86 atomics op implementation to be more
readable, in preparation of KASAN annotations. (Dmitry Vyukov)- Fix static keys (Paolo Bonzini)
- Add killable versions of down_read() et al (Kirill Tkhai)
- Rework and fix jump_label locking (Marc Zyngier, Paolo Bonzini)
- Rework (and fix) tlb_flush_pending() barriers (Peter Zijlstra)
- Remove smp_mb__before_spinlock() and convert its usages, introduce
smp_mb__after_spinlock() (Peter Zijlstra)* 'locking-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (56 commits)
locking/lockdep/selftests: Fix mixed read-write ABBA tests
sched/completion: Avoid unnecessary stack allocation for COMPLETION_INITIALIZER_ONSTACK()
acpi/nfit: Fix COMPLETION_INITIALIZER_ONSTACK() abuse
locking/pvqspinlock: Relax cmpxchg's to improve performance on some architectures
smp: Avoid using two cache lines for struct call_single_data
locking/lockdep: Untangle xhlock history save/restore from task independence
locking/refcounts, x86/asm: Disable CONFIG_ARCH_HAS_REFCOUNT for the time being
futex: Remove duplicated code and fix undefined behaviour
Documentation/locking/atomic: Finish the document...
locking/lockdep: Fix workqueue crossrelease annotation
workqueue/lockdep: 'Fix' flush_work() annotation
locking/lockdep/selftests: Add mixed read-write ABBA tests
mm, locking/barriers: Clarify tlb_flush_pending() barriers
locking/lockdep: Make CONFIG_LOCKDEP_CROSSRELEASE and CONFIG_LOCKDEP_COMPLETIONS truly non-interactive
locking/lockdep: Explicitly initialize wq_barrier::done::map
locking/lockdep: Rename CONFIG_LOCKDEP_COMPLETE to CONFIG_LOCKDEP_COMPLETIONS
locking/lockdep: Reword title of LOCKDEP_CROSSRELEASE config
locking/lockdep: Make CONFIG_LOCKDEP_CROSSRELEASE part of CONFIG_PROVE_LOCKING
locking/refcounts, x86/asm: Implement fast refcount overflow protection
locking/lockdep: Fix the rollback and overwrite detection logic in crossrelease
...
17 Aug, 2017
1 commit
-
The memory-barriers.txt document contains an obsolete passage stating that
smp_read_barrier_depends() is required to force ordering for read-to-write
dependencies. We now know that this is not required, even for DEC Alpha.
This commit therefore updates this passage to state that read-to-write
dependencies are respected even without smp_read_barrier_depends().Reported-by: Lance Roy
Signed-off-by: Paul E. McKenney
Cc: David Howells
Cc: Peter Zijlstra
Cc: Jonathan Corbet
Cc: Alan Stern
Cc: Andrea Parri
Cc: Jade Alglave
Cc: Luc Maranget
[ paulmck: Reference control-dependencies sections and use WRITE_ONCE()
per Will Deacon. Correctly place split-cache paragraph while there. ]
Acked-by: Will Deacon
10 Aug, 2017
2 commits
-
Now that there are no users of smp_mb__before_spinlock() left, remove
it entirely.Signed-off-by: Peter Zijlstra (Intel)
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Signed-off-by: Ingo Molnar -
Since we've vastly expanded the atomic_t interface in recent years the
existing documentation is woefully out of date and people seem to get
confused a bit.Start a new document to hopefully better explain the current state of
affairs.The old atomic_ops.txt also covers bitmaps and a few more details so
this is not a full replacement and we'll therefore keep that document
around until such a time that we've managed to write more text to cover
its entire.Also please, ReST people, go away.
Signed-off-by: Peter Zijlstra (Intel)
Cc: Boqun Feng
Cc: Linus Torvalds
Cc: Paul McKenney
Cc: Peter Zijlstra
Cc: Randy Dunlap
Cc: Thomas Gleixner
Cc: Will Deacon
Signed-off-by: Ingo Molnar
14 Jul, 2017
1 commit
-
Pull documentation fixes from Jonathan Corbet:
"A set of fixes for various warnings, including the one caused by the
removal of kernel/rcu/srcu.c. Also correct a stray pointer in
memory-barriers.txt"* tag '4.13-fixes' of git://git.lwn.net/linux:
kokr/memory-barriers.txt: Fix obsolete link to atomic_ops.txt
memory-barriers.txt: Fix broken link to atomic_ops.txt
docs: Turn off section numbering for the input docs
docs: Include uaccess docs from the right file
docs: Do not include from kernel/rcu/srcu.c
13 Jul, 2017
1 commit
-
Few obsolete links to atomic_ops.txt exist in memory-barriers.txt though
the file has moved to core-api/atomic_ops.rst. This commit fixes the
obsolete links.Signed-off-by: SeongJae Park
Signed-off-by: Jonathan Corbet
04 Jul, 2017
1 commit
-
Pull documentation updates from Jonathan Corbet:
"There has been a fair amount of activity in the docs tree this time
around. Highlights include:- Conversion of a bunch of security documentation into RST
- The conversion of the remaining DocBook templates by The Amazing
Mauro Machine. We can now drop the entire DocBook build chain.- The usual collection of fixes and minor updates"
* tag 'docs-4.13' of git://git.lwn.net/linux: (90 commits)
scripts/kernel-doc: handle DECLARE_HASHTABLE
Documentation: atomic_ops.txt is core-api/atomic_ops.rst
Docs: clean up some DocBook loose ends
Make the main documentation title less Geocities
Docs: Use kernel-figure in vidioc-g-selection.rst
Docs: fix table problems in ras.rst
Docs: Fix breakage with Sphinx 1.5 and upper
Docs: Include the Latex "ifthen" package
doc/kokr/howto: Only send regression fixes after -rc1
docs-rst: fix broken links to dynamic-debug-howto in kernel-parameters
doc: Document suitability of IBM Verse for kernel development
Doc: fix a markup error in coding-style.rst
docs: driver-api: i2c: remove some outdated information
Documentation: DMA API: fix a typo in a function name
Docs: Insert missing space to separate link from text
doc/ko_KR/memory-barriers: Update control-dependencies example
Documentation, kbuild: fix typo "minimun" -> "minimum"
docs: Fix some formatting issues in request-key.rst
doc: ReSTify keys-trusted-encrypted.txt
doc: ReSTify keys-request-key.txt
...
24 Jun, 2017
1 commit
-
I was reading the memory barries documentation in order to make sure the
RISC-V barries were correct, and I found a broken link to the atomic
operations documentation.Signed-off-by: Palmer Dabbelt
Acked-by: Will Deacon
Acked-by: Paul E. McKenney
Signed-off-by: Jonathan Corbet
08 Jun, 2017
1 commit
-
This commit changes "architecure" to the correct spelling,
"architecture".Signed-off-by: Stan Drozd
Signed-off-by: Paul E. McKenney
12 May, 2017
1 commit
-
Pull more documentation updates from Jonathan Corbet:
"Connect the newly RST-formatted documentation to the rest; this had to
wait until the input pull was done. There's also a few small fixes
that wandered in"* tag 'docs-4.12-2' of git://git.lwn.net/linux:
doc: replace FTP URL to kernel.org with HTTPS one
docs: update references to the device io book
Documentation: earlycon: fix Marvell Armada 3700 UART name
docs-rst: add input docs at main index and use kernel-figure
10 May, 2017
1 commit
-
While converting the deviceiobook from DocBook to RST, dangling
references were left behind. This commit updates all remaining
references to the new location. SeongJae Park improved the ko_KR
translation.Fixes: 8a8a602fdb83 ("docs: Convert the deviceio template to RST")
Signed-off-by: Helmut Grohne
Signed-off-by: SeongJae Park
Signed-off-by: Jonathan Corbet
12 Apr, 2017
1 commit
-
In the following example, if MAX is defined to be 1, then the compiler
knows (Q % MAX) is equal to zero. The compiler can therefore throw
away the "then" branch (and the "if"), retaining only the "else" branch.q = READ_ONCE(a);
if (q % MAX) {
WRITE_ONCE(b, 1);
do_something();
} else {
WRITE_ONCE(b, 2);
do_something_else();
}It is therefore necessary to modify the example like this:
q = READ_ONCE(a);
- WRITE_ONCE(b, 1);
+ WRITE_ONCE(b, 2);
do_something_else();Signed-off-by: pierre Kuo
Acked-by: Will Deacon
Signed-off-by: Paul E. McKenney
15 Jan, 2017
1 commit
-
This commit adds consistency to examples, formatting, and a couple of
additional warnings.Signed-off-by: Paul E. McKenney
Reviewed-by: Josh Triplett
12 Aug, 2016
3 commits
-
An example result for data dependent write has a typo. This commit
fixes the wrong typo.Signed-off-by: SeongJae Park
Signed-off-by: Paul E. McKenney
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: dhowells@redhat.com
Cc: linux-arch@vger.kernel.org
Cc: will.deacon@arm.com
Link: http://lkml.kernel.org/r/1470939463-31950-3-git-send-email-paulmck@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar -
Signed-off-by: SeongJae Park
Signed-off-by: Paul E. McKenney
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: dhowells@redhat.com
Cc: linux-arch@vger.kernel.org
Cc: will.deacon@arm.com
Link: http://lkml.kernel.org/r/1470939463-31950-2-git-send-email-paulmck@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar -
Signed-off-by: SeongJae Park
Signed-off-by: Paul E. McKenney
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: dhowells@redhat.com
Cc: linux-arch@vger.kernel.org
Cc: will.deacon@arm.com
Link: http://lkml.kernel.org/r/1470939463-31950-1-git-send-email-paulmck@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar
17 Jun, 2016
1 commit
-
Nothing in the control-dependencies section of memory-barriers.txt
says that control dependencies don't extend beyond the end of the
if-statement containing the control dependency. Worse yet, in many
situations, they do extend beyond that if-statement. In particular,
the compiler cannot destroy the control dependency given proper use of
READ_ONCE() and WRITE_ONCE(). However, a weakly ordered system having
a conditional-move instruction provides the control-dependency guarantee
only to code within the scope of the if-statement itself.This commit therefore adds words and an example demonstrating this
limitation of control dependencies.Reported-by: Will Deacon
Signed-off-by: Paul E. McKenney
Acked-by: Peter Zijlstra (Intel)
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: corbet@lwn.net
Cc: linux-arch@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Link: http://lkml.kernel.org/r/20160615230817.GA18039@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar
28 Apr, 2016
3 commits
-
For compound atomics performing both a load and a store operation, make
it clear that _acquire and _release variants refer only to the load and
store portions of compound atomic. For example, xchg_acquire is an xchg
operation where the load takes on ACQUIRE semantics.Signed-off-by: Will Deacon
Signed-off-by: Paul E. McKenney
Acked-by: Peter Zijlstra (Intel)
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: corbet@lwn.net
Cc: dave@stgolabs.net
Cc: dhowells@redhat.com
Cc: linux-doc@vger.kernel.org
Link: http://lkml.kernel.org/r/1461691328-5429-3-git-send-email-paulmck@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar -
There has been some confusion about the purpose of memory-barriers.txt,
so this commit adds a statement of purpose.Signed-off-by: David Howells
Signed-off-by: Paul E. McKenney
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: corbet@lwn.net
Cc: dave@stgolabs.net
Cc: linux-doc@vger.kernel.org
Cc: will.deacon@arm.com
Link: http://lkml.kernel.org/r/1461691328-5429-2-git-send-email-paulmck@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar -
It appears people are reading this document as a requirements list for
building hardware. This is not the intent of this document. Nor is it
particularly suited for this purpose.The primary purpose of this document is our collective attempt to define
a set of primitives that (hopefully) allow us to write correct code on
the myriad of SMP platforms Linux supports.Its a definite work in progress as our understanding of these platforms,
and memory ordering in general, progresses.Nor does being mentioned in this document mean we think its a
particularly good idea; the data dependency barrier required by Alpha
being a prime example. Yes we have it, no you're insane to require it
when building new hardware.Signed-off-by: Peter Zijlstra (Intel)
Signed-off-by: Paul E. McKenney
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: corbet@lwn.net
Cc: dave@stgolabs.net
Cc: dhowells@redhat.com
Cc: linux-doc@vger.kernel.org
Cc: will.deacon@arm.com
Link: http://lkml.kernel.org/r/1461691328-5429-1-git-send-email-paulmck@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar
13 Apr, 2016
6 commits
-
... do this next to smp_load_acquire() when first mentioning
ACQUIRE. While this call is briefly explained and control
dependencies are mentioned later, it does not hurt the reader.Signed-off-by: Davidlohr Bueso
Signed-off-by: Paul E. McKenney
Cc: Andrew Morton
Cc: Davidlohr Bueso
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: bobby.prani@gmail.com
Cc: dhowells@redhat.com
Cc: dipankar@in.ibm.com
Cc: dvhart@linux.intel.com
Cc: edumazet@google.com
Cc: fweisbec@gmail.com
Cc: jiangshanlai@gmail.com
Cc: josh@joshtriplett.org
Cc: mathieu.desnoyers@efficios.com
Cc: oleg@redhat.com
Cc: rostedt@goodmis.org
Link: http://lkml.kernel.org/r/1460476375-27803-7-git-send-email-paulmck@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar -
The document uses two newlines between sections, one newline between
item and its detailed description, and two spaces between sentences.There are a few places that used these rules inconsistently - fix them.
Signed-off-by: SeongJae Park
Signed-off-by: Paul E. McKenney
Acked-by: David Howells
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: bobby.prani@gmail.com
Cc: dipankar@in.ibm.com
Cc: dvhart@linux.intel.com
Cc: edumazet@google.com
Cc: fweisbec@gmail.com
Cc: jiangshanlai@gmail.com
Cc: josh@joshtriplett.org
Cc: mathieu.desnoyers@efficios.com
Cc: oleg@redhat.com
Cc: rostedt@goodmis.org
Link: http://lkml.kernel.org/r/1460476375-27803-5-git-send-email-paulmck@linux.vnet.ibm.com
[ Fixed the changelog. ]
Signed-off-by: Ingo Molnar -
Signed-off-by: SeongJae Park
Signed-off-by: Paul E. McKenney
Acked-by: David Howells
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: bobby.prani@gmail.com
Cc: dipankar@in.ibm.com
Cc: dvhart@linux.intel.com
Cc: edumazet@google.com
Cc: fweisbec@gmail.com
Cc: jiangshanlai@gmail.com
Cc: josh@joshtriplett.org
Cc: mathieu.desnoyers@efficios.com
Cc: oleg@redhat.com
Cc: rostedt@goodmis.org
Link: http://lkml.kernel.org/r/1460476375-27803-4-git-send-email-paulmck@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar -
A 'Virtual Machine Guests' subsection was added by this commit:
6a65d26385bf487 ("asm-generic: implement virt_xxx memory barriers")
but the TOC was not updated - update it.
Signed-off-by: SeongJae Park
Signed-off-by: Paul E. McKenney
Acked-by: David Howells
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: bobby.prani@gmail.com
Cc: dipankar@in.ibm.com
Cc: dvhart@linux.intel.com
Cc: edumazet@google.com
Cc: fweisbec@gmail.com
Cc: jiangshanlai@gmail.com
Cc: josh@joshtriplett.org
Cc: mathieu.desnoyers@efficios.com
Cc: oleg@redhat.com
Cc: rostedt@goodmis.org
Link: http://lkml.kernel.org/r/1460476375-27803-3-git-send-email-paulmck@linux.vnet.ibm.com
[ Rewrote the changelog. ]
Signed-off-by: Ingo Molnar -
The terms 'lock'/'unlock' were changed to 'acquire'/'release' by the
following commit:2e4f5382d12a4 ("locking/doc: Rename LOCK/UNLOCK to ACQUIRE/RELEASE")
However, the commit missed to change the table of contents - fix that.
Also, the dumb rename changed the section name 'Locking functions' to an
actively misleading 'Acquiring functions' section name.Rename it to 'Lock acquisition functions' instead.
Suggested-by: David Howells
Signed-off-by: SeongJae Park
Signed-off-by: Paul E. McKenney
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: bobby.prani@gmail.com
Cc: dipankar@in.ibm.com
Cc: dvhart@linux.intel.com
Cc: edumazet@google.com
Cc: fweisbec@gmail.com
Cc: jiangshanlai@gmail.com
Cc: josh@joshtriplett.org
Cc: mathieu.desnoyers@efficios.com
Cc: oleg@redhat.com
Cc: rostedt@goodmis.org
Link: http://lkml.kernel.org/r/1460476375-27803-2-git-send-email-paulmck@linux.vnet.ibm.com
[ Rewrote the changelog. ]
Signed-off-by: Ingo Molnar -
The current documentation claims that the compiler ignores barrier(),
which is not the case. Instead, the compiler carefully pays attention
to barrier(), but in a creative way that still manages to destroy
the control dependency. This commit sets the story straight.Reported-by: Mathieu Desnoyers
Signed-off-by: Paul E. McKenney
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: bobby.prani@gmail.com
Cc: dhowells@redhat.com
Cc: dipankar@in.ibm.com
Cc: dvhart@linux.intel.com
Cc: edumazet@google.com
Cc: fweisbec@gmail.com
Cc: jiangshanlai@gmail.com
Cc: josh@joshtriplett.org
Cc: oleg@redhat.com
Cc: rostedt@goodmis.org
Link: http://lkml.kernel.org/r/1460476375-27803-1-git-send-email-paulmck@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar
15 Mar, 2016
8 commits
-
The compiler store-fusion example in memory-barriers.txt uses a C
comment to represent arbitrary code that does not update a given
variable. Unfortunately, someone could reasonably interpret the
comment as instead referring to the following line of code. This
commit therefore replaces the comment with a string that more
clearly represents the arbitrary code.Signed-off-by: SeongJae Park
Acked-by: David Howells
Signed-off-by: Paul E. McKenney -
The "transitivity" section mentions cumulativity in a potentially
confusing way. Contrary to the current wording, cumulativity is
not transitivity, but rather a hardware discipline that can be used
to implement transitivity on ARM and PowerPC CPUs. This commit
therefore deletes the mention of cumulativity.Reported-by: Luc Maranget
Signed-off-by: Paul E. McKenney -
The memory-barriers.txt discussion of local transitivity and
release-acquire chains leaves out discussion of the outcome of
the read from "u". This commit therefore adds an outcome showing
that you can get a "1" from this read even if the release-acquire
pairs don't line up.Reported-by: Will Deacon
Signed-off-by: Paul E. McKenney -
The introduction of smp_load_acquire() and smp_store_release() had
the side effect of introducing a weaker notion of transitivity:
The transitivity of full smp_mb() barriers is global, but that
of smp_store_release()/smp_load_acquire() chains is local. This
commit therefore introduces the notion of local transitivity and
gives an example.Reported-by: Peter Zijlstra
Reported-by: Will Deacon
Signed-off-by: Paul E. McKenney -
The current memory-barriers.txt does not address the possibility of
a write to a dereferenced pointer. This should be rare, but when it
happens, we need that write -not- to be clobbered by the initialization.
This commit therefore adds an example showing a data dependency ordering
a later data-dependent write.Reported-by: Leonid Yegoshin
Signed-off-by: Paul E. McKenney -
Commit #1ebee8017d84 (rcu: Eliminate array-index-based RCU primitives)
eliminated the primitives supporting RCU-protected array indexes, but
failed to update Documentation/memory-barriers.txt accordingly. This
commit therefore removes the discussion of RCU-protected array indexes.Signed-off-by: Paul E. McKenney
-
This commit fixes a couple of "Compiler Barrier" section references to
be "COMPILER BARRIER". This makes it easier to find the section in
the usual text editors.Signed-off-by: Paul E. McKenney
-
The summary of the "CONTROL DEPENDENCIES" section incorrectly states that
barrier() may be used to prevent compiler reordering when more than one
leg of the control-dependent "if" statement start with identical stores.
This is incorrect at high optimization levels. This commit therefore
updates the summary to match the detailed description.Reported by: Jianyu Zhan
Signed-off-by: Paul E. McKenney
19 Jan, 2016
1 commit
-
Pull virtio barrier rework+fixes from Michael Tsirkin:
"This adds a new kind of barrier, and reworks virtio and xen to use it.Plus some fixes here and there"
* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost: (44 commits)
checkpatch: add virt barriers
checkpatch: check for __smp outside barrier.h
checkpatch.pl: add missing memory barriers
virtio: make find_vqs() checkpatch.pl-friendly
virtio_balloon: fix race between migration and ballooning
virtio_balloon: fix race by fill and leak
s390: more efficient smp barriers
s390: use generic memory barriers
xen/events: use virt_xxx barriers
xen/io: use virt_xxx barriers
xenbus: use virt_xxx barriers
virtio_ring: use virt_store_mb
sh: move xchg_cmpxchg to a header by itself
sh: support 1 and 2 byte xchg
virtio_ring: update weak barriers to use virt_xxx
Revert "virtio_ring: Update weak barriers to use dma_wmb/rmb"
asm-generic: implement virt_xxx memory barriers
x86: define __smp_xxx
xtensa: define __smp_xxx
tile: define __smp_xxx
...
13 Jan, 2016
1 commit
-
Guests running within virtual machines might be affected by SMP effects even if
the guest itself is compiled without SMP support. This is an artifact of
interfacing with an SMP host while running an UP kernel. Using mandatory
barriers for this use-case would be possible but is often suboptimal.In particular, virtio uses a bunch of confusing ifdefs to work around
this, while xen just uses the mandatory barriers.To better handle this case, low-level virt_mb() etc macros are made available.
These are implemented trivially using the low-level __smp_xxx macros,
the purpose of these wrappers is to annotate those specific cases.These have the same effect as smp_mb() etc when SMP is enabled, but generate
identical code for SMP and non-SMP systems. For example, virtual machine guests
should use virt_mb() rather than smp_mb() when synchronizing against a
(possibly SMP) host.Suggested-by: David Miller
Signed-off-by: Michael S. Tsirkin
Acked-by: Peter Zijlstra (Intel)
12 Jan, 2016
1 commit
-
Pull locking updates from Ingo Molnar:
"So we have a laundry list of locking subsystem changes:- continuing barrier API and code improvements
- futex enhancements
- atomics API improvements
- pvqspinlock enhancements: in particular lock stealing and adaptive
spinning- qspinlock micro-enhancements"
* 'locking-core-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
futex: Allow FUTEX_CLOCK_REALTIME with FUTEX_WAIT op
futex: Cleanup the goto confusion in requeue_pi()
futex: Remove pointless put_pi_state calls in requeue()
futex: Document pi_state refcounting in requeue code
futex: Rename free_pi_state() to put_pi_state()
futex: Drop refcount if requeue_pi() acquired the rtmutex
locking/barriers, arch: Remove ambiguous statement in the smp_store_mb() documentation
lcoking/barriers, arch: Use smp barriers in smp_store_release()
locking/cmpxchg, arch: Remove tas() definitions
locking/pvqspinlock: Queue node adaptive spinning
locking/pvqspinlock: Allow limited lock stealing
locking/pvqspinlock: Collect slowpath lock statistics
sched/core, locking: Document Program-Order guarantees
locking, sched: Introduce smp_cond_acquire() and use it
locking/pvqspinlock, x86: Optimize the PV unlock code path
locking/qspinlock: Avoid redundant read of next pointer
locking/qspinlock: Prefetch the next node cacheline
locking/qspinlock: Use _acquire/_release() versions of cmpxchg() & xchg()
atomics: Add test for atomic operations with _relaxed variants
06 Dec, 2015
1 commit
-
In commit 2ecf810121c7 ("Documentation/memory-barriers.txt: Add
needed ACCESS_ONCE() calls to memory-barriers.txt") the statement
"Q = P" was converted to "ACCESS_ONCE(Q) = P". This should have
been "Q = ACCESS_ONCE(P)". It later became "WRITE_ONCE(Q, P)".
This doesn't match the following text, which is "Q = LOAD P".
Change the statement to be "Q = READ_ONCE(P)".Signed-off-by: Chris Metcalf
Signed-off-by: Paul E. McKenney
04 Dec, 2015
1 commit
-
It serves no purpose but to confuse readers, and is most
likely a left over from constant memory-barriers.txt
updates. I.e.:http://lists.openwall.net/linux-kernel/2006/07/15/27
Signed-off-by: Davidlohr Bueso
Signed-off-by: Peter Zijlstra (Intel)
Cc:
Cc: Andrew Morton
Cc: Jonathan Corbet
Cc: Linus Torvalds
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link: http://lkml.kernel.org/r/1445975631-17047-5-git-send-email-dave@stgolabs.net
Signed-off-by: Ingo Molnar
04 Nov, 2015
1 commit
-
This seems to be a mis-reading of how alpha memory ordering works, and
is not backed up by the alpha architecture manual. The helper functions
don't do anything special on any other architectures, and the arguments
that support them being safe on other architectures also argue that they
are safe on alpha.Basically, the "control dependency" is between a previous read and a
subsequent write that is dependent on the value read. Even if the
subsequent write is actually done speculatively, there is no way that
such a speculative write could be made visible to other cpu's until it
has been committed, which requires validating the speculation.Note that most weakely ordered architectures (very much including alpha)
do not guarantee any ordering relationship between two loads that depend
on each other on a control dependency:read A
if (val == 1)
read Bbecause the conditional may be predicted, and the "read B" may be
speculatively moved up to before reading the value A. So we require the
user to insert a smp_rmb() between the two accesses to be correct:read A;
if (A == 1)
smp_rmb()
read BAlpha is further special in that it can break that ordering even if the
*address* of B depends on the read of A, because the cacheline that is
read later may be stale unless you have a memory barrier in between the
pointer read and the read of the value behind a pointer:read ptr
read offset(ptr)whereas all other weakly ordered architectures guarantee that the data
dependency (as opposed to just a control dependency) will order the two
accesses. As a result, alpha needs a "smp_read_barrier_depends()" in
between those two reads for them to be ordered.The coontrol dependency that "READ_ONCE_CTRL()" and "atomic_read_ctrl()"
had was a control dependency to a subsequent *write*, however, and
nobody can finalize such a subsequent write without having actually done
the read. And were you to write such a value to a "stale" cacheline
(the way the unordered reads came to be), that would seem to lose the
write entirely.So the things that make alpha able to re-order reads even more
aggressively than other weak architectures do not seem to be relevant
for a subsequent write. Alpha memory ordering may be strange, but
there's no real indication that it is *that* strange.Also, the alpha architecture reference manual very explicitly talks
about the definition of "Dependence Constraints" in section 5.6.1.7,
where a preceding read dominates a subsequent write.Such a dependence constraint admittedly does not impose a BEFORE (alpha
architecture term for globally visible ordering), but it does guarantee
that there can be no "causal loop". I don't see how you could avoid
such a loop if another cpu could see the stored value and then impact
the value of the first read. Put another way: the read and the write
could not be seen as being out of order wrt other cpus.So I do not see how these "x_ctrl()" functions can currently be necessary.
I may have to eat my words at some point, but in the absense of clear
proof that alpha actually needs this, or indeed even an explanation of
how alpha could _possibly_ need it, I do not believe these functions are
called for.And if it turns out that alpha really _does_ need a barrier for this
case, that barrier still should not be "smp_read_barrier_depends()".
We'd have to make up some new speciality barrier just for alpha, along
with the documentation for why it really is necessary.Cc: Peter Zijlstra
Cc: Paul E McKenney
Cc: Dmitry Vyukov
Cc: Will Deacon
Cc: Ingo Molnar
Signed-off-by: Linus Torvalds