From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gleb Natapov Subject: Re: [PATCHv2] KVM: x86: Fix memory leak in vmx.c Date: Thu, 18 Apr 2013 11:50:37 +0300 Message-ID: <20130418085037.GN8997@redhat.com> References: <516F1A35.5090106@redhat.com> <516FACB5.2040000@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andrew Honig , "kvm@vger.kernel.org" To: Paolo Bonzini Return-path: Received: from mx1.redhat.com ([209.132.183.28]:20801 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965897Ab3DRIuk (ORCPT ); Thu, 18 Apr 2013 04:50:40 -0400 Content-Disposition: inline In-Reply-To: <516FACB5.2040000@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Apr 18, 2013 at 10:20:05AM +0200, Paolo Bonzini wrote: > Il 18/04/2013 01:03, Andrew Honig ha scritto: > > I don't have a significant objection to freeing the memory in > > kvm_arch_free_memslot, although I think it's a little harder to > > understand. I like the idea of being symmetric (memory is allocated > > by calling kvm_set_memory_region and freed using the same technique). > > That way if someone changes from vm_mmap to something else it will be > > obvious that they need to change both. > > > > Also, it looks like your patch is based on something several commits > > behind HEAD on virt/kvm/kvm.git, > > Yeah, it was just whatever version I had checked out on the laptop. :) > So that maintainers can look at both approaches and see what they prefer. > > Gleb, Marcelo, wdyt? > I agree with Andrew. Having kvm_arch_free_memslot() unmap memory, but only for subset of memslots is not cleanest approach. Userspace interface for slot deletion is to "create" the slot with zero size, Andrew patch uses the same, well tested, code path. -- Gleb.