diff options
author | Carsten Otte <carsteno@de.ibm.com> | 2009-11-30 17:14:41 +0100 |
---|---|---|
committer | Avi Kivity <avi@redhat.com> | 2009-12-03 09:32:26 +0200 |
commit | f50146bd7bdb75435638e60d4960edd9bcdf88b8 (patch) | |
tree | 5c52dfae9dc90d9ae9b07d87d63ca0f4704b0f4b /Documentation/memory-barriers.txt | |
parent | 3548bab501887a698a887639b54d5ecaf35c387b (diff) | |
download | kernel-crypto-f50146bd7bdb75435638e60d4960edd9bcdf88b8.tar.gz kernel-crypto-f50146bd7bdb75435638e60d4960edd9bcdf88b8.tar.xz kernel-crypto-f50146bd7bdb75435638e60d4960edd9bcdf88b8.zip |
KVM: s390: Fix prefix register checking in arch/s390/kvm/sigp.c
This patch corrects the checking of the new address for the prefix register.
On s390, the prefix register is used to address the cpu's lowcore (address
0...8k). This check is supposed to verify that the memory is readable and
present.
copy_from_guest is a helper function, that can be used to read from guest
memory. It applies prefixing, adds the start address of the guest memory in
user, and then calls copy_from_user. Previous code was obviously broken for
two reasons:
- prefixing should not be applied here. The current prefix register is
going to be updated soon, and the address we're looking for will be
0..8k after we've updated the register
- we're adding the guest origin (gmsor) twice: once in subject code
and once in copy_from_guest
With kuli, we did not hit this problem because (a) we were lucky with
previous prefix register content, and (b) our guest memory was mmaped
very low into user address space.
Cc: stable@kernel.org
Signed-off-by: Carsten Otte <cotte@de.ibm.com>
Reported-by: Alexander Graf <agraf@suse.de>
Signed-off-by: Avi Kivity <avi@redhat.com>
Diffstat (limited to 'Documentation/memory-barriers.txt')
0 files changed, 0 insertions, 0 deletions