forked from Minki/linux
fdbbe8e791
the kernel locks have aqcuire/release semantics. No operation done after the lock can be "moved" before the lock and no operation before the unlock can be moved after the unlock. But it is perfectly fine that memory accesses which happen code wise after unlock are performed within the critical section. On s390x, reads are in-order with other reads (PoP section "Storage-Operand Fetch References") and writes are in-order with other writes (PoP section "Storage-Operand Store References"). Writes are also in-order with reads to the same memory location (PoP section "Storage-Operand Store References"). To other CPUs (and the channel subsystem), reads additionally appear to be performed prior to reads or writes that happen after them in the conceptual sequence (PoP section "Relation between Operand Accesses"). So at least as observed by other CPUs and the channel subsystem, reads inside the critical sections will not happen after unlock (and writes are in-order anyway). That's exactly what we need for "RELEASE operations" (memory-barriers.txt): "It guarantees that all memory operations before the RELEASE operation will appear to happen before the RELEASE operation with respect to the other components of the system." Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com> Reviewed-By: Sascha Silbe <silbe@linux.vnet.ibm.com> [cross-reading and lot of improvements for the patch description] Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com> |
||
|---|---|---|
| .. | ||
| appldata | ||
| boot | ||
| configs | ||
| crypto | ||
| hypfs | ||
| include | ||
| kernel | ||
| kvm | ||
| lib | ||
| mm | ||
| net | ||
| numa | ||
| oprofile | ||
| pci | ||
| defconfig | ||
| Kbuild | ||
| Kconfig | ||
| Kconfig.debug | ||
| Makefile | ||