VirtFS possible memory leak in 9p virtio mapped

[deleted]

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.

[deleted (to-delete)]

Updated to v2.6.36.6 with https://patchwork.kernel.org/patch/127401/ and it still has the problem. It increases the memory usage not as fast, but it still quite a lot.

I also tried to mount it using -oversion=9p2000.L

/sys/kernel/debug/kmemleak says on unmount:

unreferenced object 0xf791a870 (size 192):
  comm "swapper", pid 1, jiffies 4294892433 (age 784.692s)
  hex dump (first 32 bytes):
    00 00 00 e0 00 00 00 00 ff ff bf fe 00 00 00 00 ................
    00 b9 9d f7 00 02 00 00 6b 6b 6b 6b 6b 6b 6b 6b ........kkkkkkkk
  backtrace:
    [<c1616140>] kmemleak_alloc+0x70/0x160
    [<c1174ad4>] __kmalloc+0x254/0x440
    [<c16210cf>] pci_acpi_scan_root+0x260/0x3b3
    [<c161c98b>] acpi_pci_root_add+0x295/0x4b7
    [<c1343dd7>] acpi_device_probe+0x72/0x277
    [<c1404db5>] driver_probe_device+0x135/0x410
    [<c14051af>] __driver_attach+0x11f/0x130
    [<c14037a2>] bus_for_each_dev+0x92/0x110
    [<c14049b7>] driver_attach+0x27/0x40
    [<c1403ced>] bus_add_driver+0x1bd/0x4e0
    [<c14056bb>] driver_register+0xcb/0x290
    [<c1345129>] acpi_bus_register_driver+0x55/0x65
    [<c196c96e>] acpi_pci_root_init+0x47/0x72
    [<c100105e>] do_one_initcall+0x3e/0x2c0
    [<c1940546>] kernel_init+0x1a6/0x305
    [<c10049c2>] kernel_thread_helper+0x6/0x14
unreferenced object 0xf79db900 (size 16):
  comm "swapper", pid 1, jiffies 4294892433 (age 784.692s)
  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:
    [<c1616140>] kmemleak_alloc+0x70/0x160
    [<c1174ad4>] __kmalloc+0x254/0x440
    [<c12efbb8>] kvasprintf+0x68/0xd0
    [<c12efc4d>] kasprintf+0x2d/0x50
    [<c1621115>] pci_acpi_scan_root+0x2a6/0x3b3
    [<c161c98b>] acpi_pci_root_add+0x295/0x4b7
    [<c1343dd7>] acpi_device_probe+0x72/0x277
    [<c1404db5>] driver_probe_device+0x135/0x410
    [<c14051af>] __driver_attach+0x11f/0x130
    [<c14037a2>] bus_for_each_dev+0x92/0x110
    [<c14049b7>] driver_attach+0x27/0x40
    [<c1403ced>] bus_add_driver+0x1bd/0x4e0
    [<c14056bb>] driver_register+0xcb/0x290
    [<c1345129>] acpi_bus_register_driver+0x55/0x65
    [<c196c96e>] acpi_pci_root_init+0x47/0x72
    [<c100105e>] do_one_initcall+0x3e/0x2c0
unreferenced object 0xf6a12c60 (size 96):
  comm "mount", pid 1191, jiffies 4294893979 (age 778.536s)
  hex dump (first 32 bytes):
    01 00 00 00 ad 4e ad de ff ff ff ff ff ff ff ff .....N..........
    28 65 11 c2 80 e8 b8 c1 8d 2c 78 c1 00 00 00 00 (e.......,x.....
  backtrace:
    [<c1616140>] kmemleak_alloc+0x70/0x160
    [<c117380b>] kmem_cache_alloc+0x21b/0x340
    [<c160c4a9>] p9_idpool_create+0x59/0xf0
    [<c160b4b2>] p9_client_create+0xe2/0x650
    [<c129b1df>] v9fs_session_init+0x35f/0x890
    [<c1295a51>] v9fs_get_sb+0xb1/0x440
    [<c118c60a>] vfs_kern_mount+0xaa/0x240
    [<c118c833>] do_kern_mount+0x53/0x1c0
    [<c11bb41a>] do_mount+0x88a/0x10f0
    [<c11bbd62>] sys_mount+0xe2/0x170
    [<c10043df>] sysenter_do_call+0x12/0x38
    [<ffffffff>] 0xffffffff
unreferenced object 0xf6bb6cc0 (size 148):
  comm "mount", pid 1191, jiffies 4294893979 (age 778.536s)
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
    00 00 00 00 00 00 0...

[Deepak C Shetty (dpkshetty)]

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.