Patch "KVM: s390: fix KVM_S390_GET_CMMA_BITS for GFNs in memslot holes" has been added to the 5.4-stable tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This is a note to let you know that I've just added the patch titled

    KVM: s390: fix KVM_S390_GET_CMMA_BITS for GFNs in memslot holes

to the 5.4-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     kvm-s390-fix-kvm_s390_get_cmma_bits-for-gfns-in-mems.patch
and it can be found in the queue-5.4 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.



commit cb77bd4b66fc12acc2a600a8707bcb76709d84d9
Author: Nico Boehr <nrb@xxxxxxxxxxxxx>
Date:   Fri Mar 24 15:54:23 2023 +0100

    KVM: s390: fix KVM_S390_GET_CMMA_BITS for GFNs in memslot holes
    
    [ Upstream commit 285cff4c0454340a4dc53f46e67f2cb1c293bd74 ]
    
    The KVM_S390_GET_CMMA_BITS ioctl may return incorrect values when userspace
    specifies a start_gfn outside of memslots.
    
    This can occur when a VM has multiple memslots with a hole in between:
    
    +-----+----------+--------+--------+
    | ... | Slot N-1 | <hole> | Slot N |
    +-----+----------+--------+--------+
          ^          ^        ^        ^
          |          |        |        |
    GFN   A          A+B      |        |
                              A+B+C    |
                                       A+B+C+D
    
    When userspace specifies a GFN in [A+B, A+B+C), it would expect to get the
    CMMA values of the first dirty page in Slot N. However, userspace may get a
    start_gfn of A+B+C+D with a count of 0, hence completely skipping over any
    dirty pages in slot N.
    
    The error is in kvm_s390_next_dirty_cmma(), which assumes
    gfn_to_memslot_approx() will return the memslot _below_ the specified GFN
    when the specified GFN lies outside a memslot. In reality it may return
    either the memslot below or above the specified GFN.
    
    When a memslot above the specified GFN is returned this happens:
    
    - ofs is calculated, but since the memslot's base_gfn is larger than the
      specified cur_gfn, ofs will underflow to a huge number.
    - ofs is passed to find_next_bit(). Since ofs will exceed the memslot's
      number of pages, the number of pages in the memslot is returned,
      completely skipping over all bits in the memslot userspace would be
      interested in.
    
    Fix this by resetting ofs to zero when a memslot _above_ cur_gfn is
    returned (cur_gfn < ms->base_gfn).
    
    Signed-off-by: Nico Boehr <nrb@xxxxxxxxxxxxx>
    Reviewed-by: Claudio Imbrenda <imbrenda@xxxxxxxxxxxxx>
    Fixes: afdad61615cc ("KVM: s390: Fix storage attributes migration with memory slots")
    Message-Id: <20230324145424.293889-2-nrb@xxxxxxxxxxxxx>
    Signed-off-by: Claudio Imbrenda <imbrenda@xxxxxxxxxxxxx>
    Signed-off-by: Janosch Frank <frankja@xxxxxxxxxxxxx>
    Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx>

diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
index 9ade970b4232c..b11eb11e2f499 100644
--- a/arch/s390/kvm/kvm-s390.c
+++ b/arch/s390/kvm/kvm-s390.c
@@ -1982,6 +1982,10 @@ static unsigned long kvm_s390_next_dirty_cmma(struct kvm_memslots *slots,
 		ms = slots->memslots + slotidx;
 		ofs = 0;
 	}
+
+	if (cur_gfn < ms->base_gfn)
+		ofs = 0;
+
 	ofs = find_next_bit(kvm_second_dirty_bitmap(ms), ms->npages, ofs);
 	while ((slotidx > 0) && (ofs >= ms->npages)) {
 		slotidx--;



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux