Searched refs:outcome (Results 1 – 19 of 19) sorted by relevance
| /Linux-v5.4/tools/memory-model/scripts/ |
| D | judgelitmus.sh | 53 if test "$outcome" = DEADLOCK
59 echo " !!! Unexpected non-$outcome verification" $litmus
62 echo " !!! Unexpected non-$outcome verification" >> $LKMM_DESTDIR/$litmus.out 2>&1
66 elif grep '^Observation' $LKMM_DESTDIR/$litmus.out | grep -q $outcome || test "$outcome" = Maybe
70 echo " !!! Unexpected non-$outcome verification" $litmus
73 echo " !!! Unexpected non-$outcome verification" >> $LKMM_DESTDIR/$litmus.out 2>&1
|
| /Linux-v5.4/net/rxrpc/ |
| D | call_event.c | 49 enum rxrpc_propose_ack_outcome outcome = rxrpc_propose_ack_use; in __rxrpc_propose_ACK() local
69 outcome = rxrpc_propose_ack_update; in __rxrpc_propose_ACK()
78 outcome = rxrpc_propose_ack_subsume; in __rxrpc_propose_ACK()
130 background, outcome); in __rxrpc_propose_ACK()
|
| /Linux-v5.4/tools/memory-model/litmus-tests/ |
| D | MP+poonceonces.litmus | 6 * Can the counter-intuitive message-passing outcome be prevented with
|
| D | LB+poonceonces.litmus | 6 * Can the counter-intuitive outcome for the load-buffering pattern
|
| /Linux-v5.4/tools/memory-model/Documentation/ |
| D | recipes.txt | 155 value of r1 be 0. The reason for this surprising outcome is that
188 sufficiently to rule out the counter-intuitive outcome.
206 outcome in which the first load sees the value written by the second store
360 One way of avoiding the counter-intuitive outcome is through the use of a
401 the counter-intuitive outcome where the kernel overwrites the data
496 this counter-intuitive outcome.
517 "if (@cond)". The full barriers prevent the undesirable outcome where
550 avoid a counter-intuitive outcome depends on the types of relations
551 linking the memory accesses for the outcome in question:
|
| D | explanation.txt | 175 happens, the LKMM does predict this outcome can occur, and the example
210 execute before itself, the specified outcome is impossible.
219 Ordering). This model predicts that the undesired outcome for the MP
243 Sequential Consistency predicts that the outcome r0 = 0, r1 = 0 is
245 this outcome to occur, and in fact it does sometimes occur on x86 and
277 and a certain outcome for the loads in a piece of code can happen only
279 that outcome cannot occur.
1293 outcome is impossible -- as it should be.
1421 prevents the r0 = 0, r1 = 0 outcome.
1682 forbidden cycle, violating the "rcu" axiom. Hence the outcome is not
[all …]
|
| /Linux-v5.4/include/trace/events/ |
| D | rxrpc.h | 1219 bool background, enum rxrpc_propose_ack_outcome outcome),
1222 outcome),
1231 __field(enum rxrpc_propose_ack_outcome, outcome )
1241 __entry->outcome = outcome;
1251 __print_symbolic(__entry->outcome, rxrpc_propose_ack_outcomes))
|
| /Linux-v5.4/Documentation/ |
| D | atomic_t.txt | 113 outcome.
259 (void)atomic_fetch_inc_acquire() for instance -- would allow the outcome,
|
| D | memory-barriers.txt | 639 Q with the store into *Q. In other words, this outcome is prohibited,
684 by attempting to predict the outcome in advance, so that other CPUs see
1459 smp_store_release()/smp_load_acquire() pairs, the following outcome
1466 outcome is prohibited:
1472 at least aside from stores. Therefore, the following outcome is possible:
1476 As an aside, the following outcome is also possible:
1493 following outcome is possible:
1497 Note that this outcome can happen even on a mythical sequentially
|
| /Linux-v5.4/Documentation/ABI/obsolete/ |
| D | sysfs-driver-hid-roccat-arvo | 35 windows and application keys, to protect the user from the outcome
|
| /Linux-v5.4/tools/power/cpupower/bench/ |
| D | README-BENCH | 104 the outcome nicely.
|
| /Linux-v5.4/Documentation/i2c/ |
| D | fault-codes.rst | 19 at all, just that the outcome wasn't on the "golden path".
|
| /Linux-v5.4/Documentation/admin-guide/ |
| D | perf-security.rst | 75 outcome determines whether monitoring is permitted. So unprivileged
|
| D | cgroup-v2.rst | 1613 multiple times, the outcome is undefined.
|
| /Linux-v5.4/Documentation/filesystems/ |
| D | sharedsubtree.txt | 348 The outcome depends on the type of mount of 'A' and 'B'. The table
459 The outcome depends on the type of the mount of 'A' and 'B'. The table
|
| /Linux-v5.4/Documentation/RCU/ |
| D | rcu_dereference.txt | 239 You might be surprised that the outcome (r1 == 143 && r2 == 44) is possible,
|
| /Linux-v5.4/Documentation/security/ |
| D | credentials.rst | 446 as the ptrace state may alter the outcome, particularly in the case of
|
| /Linux-v5.4/Documentation/driver-api/usb/ |
| D | power-management.rst | 520 wakeup may fail and get lost. Which outcome occurs depends on timing
|
| /Linux-v5.4/Documentation/networking/ |
| D | bonding.txt | 664 in the bond. A problematic outcome of using ARP
|
