On 12/22/2017 02:35 PM, Cornelia Huck wrote: > On Fri, 22 Dec 2017 12:21:45 +0100 > Christian Borntraeger <borntraeger@xxxxxxxxxx> wrote: > >> Some parts of the cmma migration bitmap is already protected >> with the kvm->lock (e.g. the migration start). On the other >> hand the read of the cmma bits is not protected against a >> concurrent free, neither is the emulation of the ESSA instruction. >> Let's extend the locking to all related ioctls by using >> the slots lock and wait for the freeing until all unlocked >> users have finished (those hold kvm->srcu for read). >> >> Reported-by: David Hildenbrand <david@xxxxxxxxxx> >> Signed-off-by: Christian Borntraeger <borntraeger@xxxxxxxxxx> >> Cc: stable@xxxxxxxxxxxxxxx # 4.13+ >> Fixes: 190df4a212a7 (KVM: s390: CMMA tracking, ESSA emulation, migration mode) >> --- >> arch/s390/kvm/kvm-s390.c | 14 +++++++++----- >> 1 file changed, 9 insertions(+), 5 deletions(-) > > I'm way too confused by the locking rules to give this a good review > before Christmas... do we have a general writeup somewhere? The hiararchy is documented (Documentation/virtual/locking) but not the purpose and what is locked by what. the slots_lock basically protects the memory slots as it is used for memslot changes (normally you would use rcu but the mutex is the big hammer to prevent concurrent memslot changes). Lets defer this to after christmas. I will do a pull request for the other 2 patches. -- To unsubscribe from this list: send the line "unsubscribe linux-s390" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
