Searched refs:outcome (Results 1 – 18 of 18) sorted by relevance
| /Linux-v4.19/tools/memory-model/scripts/ |
| D | checklitmus.sh | 66 if test "$outcome" = DEADLOCK
73 echo " ^^^ Unexpected non-$outcome verification"
74 echo " ^^^ Unexpected non-$outcome verification" >> $litmus.out 2>&1
77 elif grep '^Observation' $litmus.out | grep -q $outcome || test "$outcome" = Maybe
81 echo " ^^^ Unexpected non-$outcome verification"
82 echo " ^^^ Unexpected non-$outcome verification" >> $litmus.out 2>&1
|
| /Linux-v4.19/net/rxrpc/ |
| D | call_event.c | 54 enum rxrpc_propose_ack_outcome outcome = rxrpc_propose_ack_use; in __rxrpc_propose_ACK() local
74 outcome = rxrpc_propose_ack_update; in __rxrpc_propose_ACK()
85 outcome = rxrpc_propose_ack_subsume; in __rxrpc_propose_ACK()
136 background, outcome); in __rxrpc_propose_ACK()
|
| /Linux-v4.19/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-v4.19/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 | 173 happens, the LKMM does predict this outcome can occur, and the example
208 execute before itself, the specified outcome is impossible.
217 Ordering). This model predicts that the undesired outcome for the MP
241 Sequential Consistency predicts that the outcome r0 = 0, r1 = 0 is
243 this outcome to occur, and in fact it does sometimes occur on x86 and
275 and a certain outcome for the loads in a piece of code can happen only
277 that outcome cannot occur.
1319 outcome is impossible -- as it should be.
1447 prevents the r0 = 0, r1 = 0 outcome.
1703 violating the "rcu" axiom. Hence the outcome is not allowed by the
[all …]
|
| /Linux-v4.19/include/trace/events/ |
| D | rxrpc.h | 1222 bool background, enum rxrpc_propose_ack_outcome outcome),
1225 outcome),
1234 __field(enum rxrpc_propose_ack_outcome, outcome )
1244 __entry->outcome = outcome;
1254 __print_symbolic(__entry->outcome, rxrpc_propose_ack_outcomes))
|
| /Linux-v4.19/Documentation/ |
| D | atomic_t.txt | 94 outcome.
229 (void)atomic_fetch_inc_acquire() for instance -- would allow the outcome,
|
| D | memory-barriers.txt | 640 Q with the store into *Q. In other words, this outcome is prohibited,
685 by attempting to predict the outcome in advance, so that other CPUs see
1460 smp_store_release()/smp_load_acquire() pairs, the following outcome
1467 outcome is prohibited:
1473 at least aside from stores. Therefore, the following outcome is possible:
1477 As an aside, the following outcome is also possible:
1494 following outcome is possible:
1498 Note that this outcome can happen even on a mythical sequentially
|
| /Linux-v4.19/Documentation/ABI/obsolete/ |
| D | sysfs-driver-hid-roccat-arvo | 35 windows and application keys, to protect the user from the outcome
|
| /Linux-v4.19/tools/power/cpupower/bench/ |
| D | README-BENCH | 104 the outcome nicely.
|
| /Linux-v4.19/Documentation/i2c/ |
| D | fault-codes | 15 at all, just that the outcome wasn't on the "golden path".
|
| /Linux-v4.19/Documentation/RCU/ |
| D | rcu_dereference.txt | 239 You might be surprised that the outcome (r1 == 143 && r2 == 44) is possible,
|
| /Linux-v4.19/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-v4.19/Documentation/security/ |
| D | credentials.rst | 446 as the ptrace state may alter the outcome, particularly in the case of
|
| /Linux-v4.19/Documentation/driver-api/usb/ |
| D | power-management.rst | 516 wakeup may fail and get lost. Which outcome occurs depends on timing
|
| /Linux-v4.19/Documentation/admin-guide/ |
| D | cgroup-v2.rst | 1390 multiple times, the outcome is undefined.
|
| /Linux-v4.19/Documentation/networking/ |
| D | bonding.txt | 664 in the bond. A problematic outcome of using ARP
|
