| /openbmc/linux/include/linux/atomic/ |
| H A D | atomic-instrumented.h | 20 * atomic_read() - atomic load with relaxed ordering
23 * Atomically loads the value of @v with relaxed ordering.
37 * atomic_read_acquire() - atomic load with acquire ordering
40 * Atomically loads the value of @v with acquire ordering.
54 * atomic_set() - atomic set with relaxed ordering
58 * Atomically sets @v to @i with relaxed ordering.
72 * atomic_set_release() - atomic set with release ordering
76 * Atomically sets @v to @i with release ordering.
91 * atomic_add() - atomic add with relaxed ordering
95 * Atomically updates @v to (@v + @i) with relaxed ordering.
[all …]
|
| H A D | atomic-long.h | 25 * raw_atomic_long_read() - atomic load with relaxed ordering
28 * Atomically loads the value of @v with relaxed ordering.
45 * raw_atomic_long_read_acquire() - atomic load with acquire ordering
48 * Atomically loads the value of @v with acquire ordering.
65 * raw_atomic_long_set() - atomic set with relaxed ordering
69 * Atomically sets @v to @i with relaxed ordering.
86 * raw_atomic_long_set_release() - atomic set with release ordering
90 * Atomically sets @v to @i with release ordering.
107 * raw_atomic_long_add() - atomic add with relaxed ordering
111 * Atomically updates @v to (@v + @i) with relaxed ordering.
[all …]
|
| H A D | atomic-arch-fallback.h | 432 * raw_atomic_read() - atomic load with relaxed ordering
435 * Atomically loads the value of @v with relaxed ordering.
448 * raw_atomic_read_acquire() - atomic load with acquire ordering
451 * Atomically loads the value of @v with acquire ordering.
477 * raw_atomic_set() - atomic set with relaxed ordering
481 * Atomically sets @v to @i with relaxed ordering.
494 * raw_atomic_set_release() - atomic set with release ordering
498 * Atomically sets @v to @i with release ordering.
520 * raw_atomic_add() - atomic add with relaxed ordering
524 * Atomically updates @v to (@v + @i) with relaxed ordering.
[all …]
|
| /openbmc/linux/tools/memory-model/Documentation/ |
| H A D | ordering.txt | 1 This document gives an overview of the categories of memory-ordering
5 Categories of Ordering
8 This section lists LKMM's three top-level categories of memory-ordering
20 3. Unordered accesses, as the name indicates, have no ordering
23 some of these "unordered" operations provide limited ordering
38 b. Read-modify-write (RMW) ordering augmentation barriers.
50 ordering primitives provided for that purpose. For example, instead of
58 The Linux-kernel primitives that provide full ordering include:
79 memory-ordering primitives. It is surprisingly hard to remember their
82 Second, some RMW atomic operations provide full ordering. These
[all …]
|
| H A D | control-dependencies.txt | 12 Therefore, a load-load control dependency will not preserve ordering
19 This is not guaranteed to provide any ordering because some types of CPUs
31 However, stores are not speculated. This means that ordering is
40 of ordering. But please note that neither the READ_ONCE() nor the
59 It is tempting to try use control dependencies to enforce ordering on
78 WRITE_ONCE(b, 1); /* BUG: No ordering vs. load from a!!! */
91 have been applied. Therefore, if you need ordering in this example,
92 you must use explicit memory ordering, for example, smp_store_release():
103 Without explicit memory ordering, control-dependency-based ordering is
121 preserve ordering. For example:
[all …]
|
| H A D | simple.txt | 2 memory-ordering lives simple, as is necessary for those whose domain
3 is complex. After all, there are bugs other than memory-ordering bugs,
4 and the time spent gaining memory-ordering knowledge is not available
139 memory ordering.
175 2. Operations that did not return a value and provided no ordering,
178 3. Operations that returned a value and provided full ordering, such as
180 value-returning operations provide full ordering only conditionally.
181 For example, cmpxchg() provides ordering only upon success.
184 provide full ordering. These are flagged with either a _relaxed()
185 suffix (providing no ordering), or an _acquire() or _release() suffix
[all …]
|
| H A D | cheatsheet.txt | 25 C: Ordering is cumulative
26 P: Ordering propagates
29 Y: Provides ordering
30 a: Provides ordering given intervening RMW atomic operation
|
| H A D | README | 16 that the Linux kernel provides: ordering.txt
64 ordering.txt
65 Overview of the Linux kernel's low-level memory-ordering
69 Common memory-ordering patterns.
|
| H A D | recipes.txt | 41 your full-ordering warranty, as do undersized accesses that load
157 lock's ordering properties.
159 Ordering can be extended to CPUs not holding the lock by careful use
208 In the absence of any ordering, this goal may not be met, as can be seen
217 the desired MP ordering. The general approach is shown below:
272 The rcu_assign_pointer() macro has the same ordering properties as does
357 absence of any ordering it is quite possible that this may happen, as
434 The ordering in this example is stronger than it needs to be. For
435 example, ordering would still be preserved if CPU1()'s smp_load_acquire()
468 well as simple and powerful, at least as memory-ordering mechanisms go.
[all …]
|
| H A D | locking.txt | 110 There are two problems. First, there is no ordering between the first
112 no ordering between the two WRITE_ONCE() calls. It should therefore be
140 that the ordering provided by each actually takes effect. Again, a
144 corresponding lock, you will need to provide additional ordering, in
148 Ordering Provided by a Lock to CPUs Not Holding That Lock
182 ordering properties.
184 Ordering can be extended to CPUs not holding the lock by careful use
|
| /openbmc/linux/Documentation/core-api/ |
| H A D | refcount-vs-atomic.rst | 14 ``atomic_*()`` functions with regards to the memory ordering guarantees.
17 these memory ordering guarantees.
23 memory ordering in general and for atomic operations specifically.
25 Relevant types of memory ordering
29 ordering types that are relevant for the atomics and reference
33 In the absence of any memory ordering guarantees (i.e. fully unordered)
41 A strong (full) memory ordering guarantees that all prior loads and
49 A RELEASE memory ordering guarantees that all prior loads and
57 An ACQUIRE memory ordering guarantees that all post loads and
84 Memory ordering guarantee changes:
[all …]
|
| /openbmc/linux/include/linux/ |
| H A D | refcount.h | 60 * Memory ordering
63 * Memory ordering rules are slightly relaxed wrt regular atomic_t functions
66 * The increments are fully relaxed; these will not provide ordering. The
68 * reference count on will provide the ordering. For locked data structures,
84 * Note that the allocator is responsible for ordering things between free()
88 * ordering on success.
175 * Provides no memory ordering, it is assumed the caller has guaranteed the
211 * Provides no memory ordering, it is assumed the caller has guaranteed the
237 * Provides no memory ordering, it is assumed the caller has guaranteed the
259 * Provides no memory ordering, it is assumed the caller already has a
[all …]
|
| H A D | rcuref.h | 51 * Provides no memory ordering, it is assumed the caller has guaranteed the
104 * Provides release memory ordering, such that prior loads and stores are done
105 * before, and provides an acquire ordering on success such that free()
133 * Provides release memory ordering, such that prior loads and stores are done
134 * before, and provides an acquire ordering on success such that free()
|
| /openbmc/linux/tools/include/linux/ |
| H A D | refcount.h | 15 * Memory ordering rules are slightly relaxed wrt regular atomic_t functions
18 * The increments are fully relaxed; these will not provide ordering. The
20 * reference count on will provide the ordering. For locked data structures,
36 * Note that the allocator is responsible for ordering things between free()
71 * Provides no memory ordering, it is assumed the caller has guaranteed the
104 * Provides no memory ordering, it is assumed the caller already has a
116 * Provides release memory ordering, such that prior loads and stores are done
|
| /openbmc/linux/arch/mips/include/asm/ |
| H A D | sync.h | 16 * 2) Ordering barriers, which only ensure that affected memory operations
20 * Ordering barriers can be more efficient than completion barriers, since:
22 * a) Ordering barriers only require memory access instructions which preceed
31 * b) Multiple variants of ordering barrier are provided which allow the
35 * barrier & don't care about the ordering of loads then the 'wmb'
36 * ordering barrier can be used. Limiting the barrier's effects to stores
57 * we're satisfied that lightweight ordering barriers defined by MIPSr6 are
65 * ...except on Cavium Octeon CPUs, which have been using the 'wmb' ordering
153 * Some Cavium Octeon CPUs suffer from a bug that causes a single wmb ordering
|
| /openbmc/linux/Documentation/RCU/Design/Memory-Ordering/ |
| H A D | Tree-RCU-Memory-Ordering.rst | 2 A Tour Through TREE_RCU's Grace-Period Memory Ordering
13 grace-period memory ordering guarantee is provided.
15 What Is Tree RCU's Grace Period Memory Ordering Guarantee?
18 RCU grace periods provide extremely strong memory-ordering guarantees
46 Tree RCU Grace Period Memory Ordering Building Blocks
49 The workhorse for RCU's grace-period memory ordering is the
72 Tree RCU uses these two ordering guarantees to form an ordering
77 The following litmus test exhibits the ordering effects of these
126 | Because we must provide ordering for RCU's polling grace-period |
145 RCU's grace-period memory ordering guarantee to extend to any
[all …]
|
| /openbmc/openbmc/poky/meta/lib/oeqa/files/maturin/guessing-game/src/ |
| H A D | lib.rs | 3 use std::cmp::Ordering;
29 Ordering::Less => println!("Too small!"), in guess_the_number()
30 Ordering::Greater => println!("Too big!"), in guess_the_number()
31 Ordering::Equal => { in guess_the_number()
|
| /openbmc/linux/tools/perf/pmu-events/arch/x86/goldmont/ |
| H A D | memory.json | 3 "BriefDescription": "Machine clears due to memory ordering issue",
6 …e clears due to memory ordering issues. This occurs when a snoop request happens and the machine …
|
| /openbmc/linux/tools/perf/pmu-events/arch/x86/goldmontplus/ |
| H A D | memory.json | 3 "BriefDescription": "Machine clears due to memory ordering issue",
6 …e clears due to memory ordering issues. This occurs when a snoop request happens and the machine …
|
| /openbmc/linux/lib/ |
| H A D | rcuref.c | 153 * Memory ordering
156 * Memory ordering rules are slightly relaxed wrt regular atomic_t functions
159 * The increments are fully relaxed; these will not provide ordering. The
161 * reference count on will provide the ordering. For locked data
165 * rcuref_get() provides a control dependency ordering future stores which
170 * will be issued before. It also provides a control dependency ordering
174 * object DEAD it also provides acquire ordering.
255 * deconstruction. Provide acquire ordering. in rcuref_put_slowpath()
|
| /openbmc/linux/include/asm-generic/ |
| H A D | rwonce.h | 6 * particular ordering. One way to make the compiler aware of ordering is to
16 * mutilate accesses that either do not require ordering or that interact
18 * required ordering.
|
| /openbmc/linux/drivers/staging/rtl8723bs/include/ |
| H A D | basic_types.h | 38 /* Convert little data endian to host ordering */
49 /* Read le16 data from memory and convert to host ordering */
60 /* Write le data to memory in host ordering */
98 * Return 4-byte value in host byte ordering from
111 /* 4-byte value in host byte ordering. */
132 /* and return the result in 4-byte value in host byte ordering. */
|
| /openbmc/linux/fs/jffs2/ |
| H A D | README.Locking | 37 Ordering constraints: See f->sem.
62 Ordering constraints:
67 No ordering rules have been made for doing so.
115 Ordering constraints:
147 Ordering constraints:
168 Ordering constraints:
|
| /openbmc/linux/Documentation/ |
| H A D | memory-barriers.txt | 87 (*) Assumed minimum execution ordering model.
137 abstract CPU, memory operation ordering is very relaxed, and a CPU may actually
365 ordering over the memory operations on either side of the barrier.
387 A write barrier is a partial ordering on stores only; it is not required
407 An address-dependency barrier is a partial ordering on interdependent
421 showing the ordering constraints.
445 A read barrier is a partial ordering on loads only; it is not required to
462 A general memory barrier is a partial ordering over both loads and stores.
653 of dependency ordering is to -prevent- writes to the data structure, along
656 naturally occurring ordering prevents such records from being lost.
[all …]
|
| /openbmc/linux/tools/memory-model/litmus-tests/ |
| H A D | README | 39 Tests whether the ordering provided by a lock-protected S
67 Does a unlock+lock pair provides ordering guarantee between a
98 Does a unlock+lock pair provides ordering guarantee between a
148 Is the ordering provided by a spin_unlock() and a subsequent
149 spin_lock() sufficient to make ordering apparent to accesses
157 Is the ordering provided by a release-acquire chain sufficient
158 to make ordering apparent to accesses by a process that does
|