[Qemu-devel] [Bug 648356] Re: VirtFS possible memory leak in 9p virtio mapped

[Deepak Shetty]

1) Host memory consumption is not the right measure to conclude on VM
mem leaks, esp. because QEMU does a mmap for the VM memory so as pages
are touched inside the guest, host will allocate and this will be seen
as increase in QEMU RSS size, as long as we don't get OOM, it should not
be considered as mem leak.

2) Since the time this bug was reported and now,  there are loads of mem leaks
fixes in kernel's 9p client code (fs/9p) and qemu 9p server code... 

3)In a while true kind of script, when one would do a Ctrl-C, it could 
potentially cut-off the umount operation in between, causing
kmemleak to show false positives.

4) We  ran the modified version of the submiited script ( instead of
while true, ran it for a defined number of iterations) and then invoked
kmemleak and did not find anything reported which relates to 9p. See the
log below...

     [<ffffffff810fbada>] __kmalloc+0xf7/0x122
     [<ffffffff81668680>] pci_acpi_scan_root+0x10f/0x2c6
     [<ffffffff81658f35>] acpi_pci_root_add+0x1d5/0x41f
     [<ffffffff813cd649>] acpi_device_probe+0x49/0x117
     [<ffffffff8147d378>] driver_probe_device+0xa5/0x135
     [<ffffffff8147d461>] __driver_attach+0x59/0x7c
     [<ffffffff8147be21>] bus_for_each_dev+0x57/0x83
     [<ffffffff8147d070>] driver_attach+0x19/0x1b
     [<ffffffff8147ccf2>] bus_add_driver+0xab/0x201
     [<ffffffff8147d8db>] driver_register+0x93/0x100
     [<ffffffff813cdd81>] acpi_bus_register_driver+0x3e/0x40
     [<ffffffff81cde2f8>] acpi_pci_root_init+0x20/0x28
     [<ffffffff8100020a>] do_one_initcall+0x7a/0x130
     [<ffffffff81cbab44>] kernel_init+0x9a/0x114
     [<ffffffff81680b64>] kernel_thread_helper+0x4/0x10
 unreferenced object 0xffff88001faf06e0 (size 16):
   comm "swapper/0", pid 1, jiffies 4294667775 (age 135.226s)
   hex dump (first 16 bytes):
     50 43 49 20 42 75 73 20 30 30 30 30 3a 30 30 00  PCI Bus 0000:00.
   backtrace:
     [<ffffffff8165460a>] kmemleak_alloc+0x21/0x3e
     [<ffffffff810fbada>] __kmalloc+0xf7/0x122
     [<ffffffff8138fd5d>] kvasprintf+0x45/0x6e
     [<ffffffff8138fdbe>] kasprintf+0x38/0x3a
     [<ffffffff816686a6>] pci_acpi_scan_root+0x135/0x2c6
     [<ffffffff81658f35>] acpi_pci_root_add+0x1d5/0x41f
     [<ffffffff813cd649>] acpi_device_probe+0x49/0x117
     [<ffffffff8147d378>] driver_probe_device+0xa5/0x135
     [<ffffffff8147d461>] __driver_attach+0x59/0x7c
     [<ffffffff8147be21>] bus_for_each_dev+0x57/0x83
     [<ffffffff8147d070>] driver_attach+0x19/0x1b
     [<ffffffff8147ccf2>] bus_add_driver+0xab/0x201
     [<ffffffff8147d8db>] dri

5) Lastly we also ran the exact same script (while true... ) for a long
duration ( few days) on 9p exported path and did not find any OOM

So this makes me believe that there aren't any mem leaks in the 9p virtio 
mapped flow.
This bug can be closed.

** Changed in: qemu
       Status: New => Invalid

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/648356

Title:
  VirtFS possible memory leak in 9p virtio mapped

Status in QEMU:
  Invalid

Bug description:
  I use as client Debian squeeze i386 with a custom kernel:
  Linux (none) 2.6.35.5 #3 Thu Sep 23 18:36:02 UTC 2010 i686 GNU/Linux

  And as host Debian squeeze amd64
  Linux asd 2.6.32-5-amd64 #1 SMP Fri Sep 17 21:50:19 UTC 2010 x86_64 GNU/Linux

  kvm version is:
  kvm-88-5908-gdd67374

  Started the client using:
  sudo /usr/local/kvm/bin/qemu-system-x86_64 -m 1024 -kernel 
linux-2.6.35.5.qemu -drive file=root.img,if=virtio -net 
nic,macaddr=02:ca:ff:ee:ba:be,model=virtio,vlan=1 -net 
tap,ifname=tap1,vlan=1,script=no -virtfs 
local,path=/host,security_model=mapped,mount_tag=host -nographic

  I've done following inside the guest:

  $  mount -t 9p -o trans=virtio host /mnt
  $ rm -f /mnt/test
  $ touch /mnt/test
  $ ls -l /mnt/test
  $ while true ;do ls -l /mnt/test > /dev/null; done

  Now I can see on my host system that the memory consumption starts at
  90MB and after a minute it raises to 130MB.  The extra memory
  consumption stops when I stop the while-loop.

  $ while true ;do ls -l /tmp > /dev/null; done

  Doesn't show that behaviour.

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/648356/+subscriptions