Searched refs:outcome (Results 1 – 24 of 24) sorted by relevance
| /kernel/linux/linux-5.10/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
|
| /kernel/linux/linux-5.10/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()
|
| /kernel/linux/linux-5.10/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
|
| /kernel/linux/linux-5.10/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.
1295 outcome is impossible -- as it should be.
1423 prevents the r0 = 0, r1 = 0 outcome.
1703 forbidden cycle, violating the "rcu" axiom. Hence the outcome is not
[all …]
|
| D | litmus-tests.txt | 66 suffices to avoid this bad outcome:
487 the outcome! For one example, please see the C-READ_ONCE.litmus and
|
| /kernel/linux/linux-5.10/include/trace/events/ |
| D | rxrpc.h | 1208 bool background, enum rxrpc_propose_ack_outcome outcome),
1211 outcome),
1220 __field(enum rxrpc_propose_ack_outcome, outcome )
1230 __entry->outcome = outcome;
1240 __print_symbolic(__entry->outcome, rxrpc_propose_ack_outcomes))
|
| /kernel/linux/linux-5.10/Documentation/ |
| D | atomic_t.txt | 113 outcome.
259 (void)atomic_fetch_inc_acquire() for instance -- would allow the outcome,
|
| D | memory-barriers.txt | 636 Q with the store into *Q. In other words, this outcome is prohibited,
681 by attempting to predict the outcome in advance, so that other CPUs see
1456 smp_store_release()/smp_load_acquire() pairs, the following outcome
1463 outcome is prohibited:
1469 at least aside from stores. Therefore, the following outcome is possible:
1473 As an aside, the following outcome is also possible:
1490 following outcome is possible:
1494 Note that this outcome can happen even on a mythical sequentially
|
| /kernel/linux/linux-5.10/Documentation/ABI/obsolete/ |
| D | sysfs-driver-hid-roccat-arvo | 35 windows and application keys, to protect the user from the outcome
|
| /kernel/linux/linux-5.10/Documentation/networking/ |
| D | page_pool.rst | 77 * page_pool_put_page(): The outcome of this depends on the page refcnt. If the
|
| D | bonding.rst | 673 in the bond. A problematic outcome of using ARP
|
| /kernel/linux/linux-5.10/tools/power/cpupower/bench/ |
| D | README-BENCH | 104 the outcome nicely.
|
| /kernel/linux/linux-5.10/Documentation/i2c/ |
| D | fault-codes.rst | 19 at all, just that the outcome wasn't on the "golden path".
|
| /kernel/linux/linux-5.10/Documentation/virt/kvm/ |
| D | s390-pv.rst | 47 been intercepted into KVM. The exceptions need to be a valid outcome
|
| /kernel/linux/linux-5.10/Documentation/admin-guide/ |
| D | perf-security.rst | 89 outcome determines whether monitoring is permitted. So unprivileged
|
| D | cgroup-v2.rst | 1684 multiple times, the outcome is undefined.
|
| /kernel/linux/linux-5.10/Documentation/filesystems/ |
| D | sharedsubtree.rst | 366 The outcome depends on the type of mount of 'A' and 'B'. The table
480 The outcome depends on the type of the mount of 'A' and 'B'. The table
|
| /kernel/linux/linux-5.10/Documentation/RCU/ |
| D | rcu_dereference.rst | 243 You might be surprised that the outcome (r1 == 143 && r2 == 44) is possible,
|
| /kernel/linux/linux-5.10/Documentation/security/ |
| D | credentials.rst | 445 as the ptrace state may alter the outcome, particularly in the case of
|
| /kernel/linux/linux-5.10/Documentation/RCU/Design/Requirements/ |
| D | Requirements.rst | 111 load a value of one from ``x``. Therefore, the outcome:
845 It turns out that the outcome:
902 that ``(r3 == 1)``. As a result, the outcome:
961 In this case, the outcome:
|
| /kernel/linux/linux-5.10/Documentation/driver-api/usb/ |
| D | power-management.rst | 520 wakeup may fail and get lost. Which outcome occurs depends on timing
|
| /kernel/linux/patches/linux-5.10/imx8mm_patch/patches/drivers/ |
| D | 0033_linux_drivers_soc_scsi_spi_tee_thermal.patch | 590 + /* Decode the outcome */
|