Jan,
Thanks for taking a look at that for me. It still looks like it leaks
to me. Could you point me to the actual free? In
kvm_arch_destroy_vm, it calls put_page on apic_access_page and
ept_identity_pagetable, but that doesn't actually free the memory. It
unpins it from the kernel, but doesn't free them. There's also the
tss_addr pages which are not referenced at all in kvm_arch_destroy_vm.
I also wrote a simple program to demonstrate the leak. This program
creates and destroys VMs with a single CPU and a TSS addr. On Intel
platforms this program consumes memory without bound (albeit slowly).
Would you mind taking a look?
thanks,
Andy
#include <asm/kvm.h>
#include <fcntl.h>
#include <linux/kvm.h>
#include <sys/ioctl.h>
int main() {
int kvm_fd = open("/dev/kvm", O_RDWR);
if (kvm_fd < 0) printf("Error opening /dev/kvm\n");
int count = 0;
while (1) {
int vm_fd = ioctl(kvm_fd, KVM_CREATE_VM, 0);
if (vm_fd < 0) printf("Error creating vm\n");
int vcpu_id = ioctl(vm_fd, KVM_CREATE_VCPU, 1);
if (vcpu_id < 0) printf("Error creating vcpu\n");
ioctl(vm_fd, KVM_SET_TSS_ADDR, 0xffc00000);
close(vcpu_id);
close(vm_fd);
printf("Iteration %d\n", ++count);
}
}
On Sat, Dec 8, 2012 at 12:31 AM, Jan Kiszka <[email protected]> wrote:
> On 2012-12-07 20:51, Andrew Honig wrote:
>> I've noticed a memory leak that occurs in vmx.c.
>>
>> In alloc_apic_access_page, it calls __kvm_set_memory_region(kvm,
>> &kvm_userspace_mem, 0). __kvm_set_memory_region calls
>> kvm_arch_prepare_memory_region, which because the user_alloc parameter
>> is 0 will allocate memory for the page with vm_mmap.
>>
>> This memory never gets freed. In kvm_arch_destroy_vm it calls
>> put_page(kvm->arch.apic_access_page), but that only unpins the memory
>> (necessary due to an earlier call to gfn_to_page), it never actually
>> frees the memory. The memory is allocated in the current process
>> context so it's cleaned up when the process exits, but if a process
>> creates and destroys multiple VMs then this leak starts to become a
>> problem.
>>
>> Similar leaks occur in alloc_identity_pagetable and vmx_set_tss_addr
>> for a total of 5 pages of memory leak for a VM. The vmx_set_tss_addr
>> actually leaks each time vmx_set_tss_addr is called so this could also
>> become a problem if a program had occasion to set the tss addr several
>> times.
>
> Both pages are per-vm. Therefore they are freed in kvm_arch_destroy_vm.
> But I have to admit that I dug a while as well to find this out.
>
> Jan
>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
