From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kiszka Subject: Re: Memory leak in vmx.c Date: Sat, 15 Dec 2012 11:09:18 +0100 Message-ID: <50CC4C4E.5060506@web.de> References: <50C2FAC8.2070303@web.de> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigE31D3BA75D0DE04895E3B283" Cc: kvm@vger.kernel.org To: Andrew Honig Return-path: Received: from mout.web.de ([212.227.15.4]:55676 "EHLO mout.web.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751057Ab2LOKJ3 (ORCPT ); Sat, 15 Dec 2012 05:09:29 -0500 In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigE31D3BA75D0DE04895E3B283 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 2012-12-10 19:36, Andrew Honig wrote: > Jan, >=20 > 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. >=20 > 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? I can confirm that the memory usage increases as long as the program runs. However, once I terminate it, all is fine again as the last user of the mapped pages then disappears and the resources are freed. The reason for the continuous growth of mapped memory is the lack of releasing the TSS mapping on vm destruction. I'm not seeing an easy way yet how to resolve this as - apparently - we cannot vm_munmap the pages on fd release (kvm destruction) when triggered on process exit. >=20 > thanks, > Andy >=20 > #include > #include > #include > #include >=20 > int main() { >=20 > int kvm_fd =3D open("/dev/kvm", O_RDWR); >=20 > if (kvm_fd < 0) printf("Error opening /dev/kvm\n"); >=20 > int count =3D 0; >=20 > while (1) { > int vm_fd =3D ioctl(kvm_fd, KVM_CREATE_VM, 0); > if (vm_fd < 0) printf("Error creating vm\n"); > int vcpu_id =3D 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); > } > } > But you test case also triggers a warning of lockdep after a few thousand cycles. Not sure yet what it means: [ 227.061010]=20 [ 227.061016] =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D [ 227.061020] [ BUG: bad unlock balance detected! ] [ 227.061025] 3.7.0-dbg+ #25 Not tainted [ 227.061028] ------------------------------------- [ 227.061031] kvm-leak/4624 is trying to release lock (&mapping->i_mmap_= mutex) at: [ 227.061043] [] mutex_unlock+0xe/0x10 [ 227.061046] but there are no more locks to release! [ 227.061050]=20 [ 227.061050] other info that might help us debug this: [ 227.061054] 3 locks held by kvm-leak/4624: [ 227.061057] #0: (&mm->mmap_sem){++++++}, at: [] do= _mmu_notifier_register+0x6d/0x12b [ 227.061070] #1: (mm_all_locks_mutex){+.+...}, at: [] mm_take_all_locks+0x40/0x168 [ 227.061080] #2: (&anon_vma->mutex){+.+...}, at: []= mm_take_all_locks+0x110/0x168 [ 227.061090]=20 [ 227.061090] stack backtrace: [ 227.061094] Pid: 4624, comm: kvm-leak Not tainted 3.7.0-dbg+ #25 [ 227.061098] Call Trace: [ 227.061103] [] ? mutex_unlock+0xe/0x10 [ 227.061109] [] print_unlock_inbalance_bug+0xe9/0xf4= [ 227.061115] [] lock_release_non_nested+0xc4/0x293 [ 227.061121] [] ? mm_take_all_locks+0x110/0x168 [ 227.061126] [] ? _mutex_lock_nest_lock+0x2c0/0x2e2 [ 227.061131] [] ? mutex_unlock+0xe/0x10 [ 227.061161] [] ? mutex_unlock+0xe/0x10 [ 227.061167] [] lock_release+0x1a7/0x1f9 [ 227.061172] [] __mutex_unlock_slowpath+0xcb/0x12f [ 227.061179] [] mutex_unlock+0xe/0x10 [ 227.061184] [] mm_drop_all_locks+0xc7/0xfb [ 227.061193] [] do_mmu_notifier_register+0xfa/0x12b [ 227.061198] [] mmu_notifier_register+0x13/0x15 [ 227.061219] [] kvm_dev_ioctl+0x298/0x3ef [kvm] [ 227.061225] [] do_vfs_ioctl+0x484/0x4c3 [ 227.061232] [] ? fget_light+0x120/0x383 [ 227.061238] [] ? sysret_check+0x22/0x5d [ 227.061243] [] sys_ioctl+0x5e/0x82 [ 227.061249] [] ? trace_hardirqs_on_thunk+0x3a/0x3f [ 227.061255] [] system_call_fastpath+0x16/0x1b Jan --------------enigE31D3BA75D0DE04895E3B283 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEYEARECAAYFAlDMTFIACgkQitSsb3rl5xTykwCdHpeYGyUqoaE5ZoQd0d697LW6 8+oAn1Bw/yb/QU/trpn61DQIlfGgonR9 =Uki4 -----END PGP SIGNATURE----- --------------enigE31D3BA75D0DE04895E3B283--