| Message ID | 1249934708.7400.10.camel@localhost.localdomain (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
This is false report. I checked kfree_skb(), it does free all pages in the fraglist in skb_release_data() later. Thanks Shirley On Mon, 2009-08-10 at 13:05 -0700, Shirley Ma wrote: > Whild reading virtio code, I found some memory leak in removing > virtio_net. > > In virtnet_remove, only skb has been freed not the pages in skb > frags. Here is the patch to fix this, please review it. > > Signed-off-by: Shirley Ma <xma@us.ibm.com> > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c > index 2a6e81d..7e629d9 100644 > --- a/drivers/net/virtio_net.c > +++ b/drivers/net/virtio_net.c > @@ -978,6 +978,7 @@ static void virtnet_remove(struct virtio_device *vdev) > > /* Free our skbs in send and recv queues, if any. */ > while ((skb = __skb_dequeue(&vi->recv)) != NULL) { > + trim_pages(vi, skb); > kfree_skb(skb); > vi->num--; > } > > > > -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
(copying Rusty, the virtio maintainer) On 08/10/2009 11:05 PM, Shirley Ma wrote: > Whild reading virtio code, I found some memory leak in removing > virtio_net. > > In virtnet_remove, only skb has been freed not the pages in skb > frags. Here is the patch to fix this, please review it. > > There were indeed reports of virtio ooming; this might be the cause. > Signed-off-by: Shirley Ma<xma@us.ibm.com> > > diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c > index 2a6e81d..7e629d9 100644 > --- a/drivers/net/virtio_net.c > +++ b/drivers/net/virtio_net.c > @@ -978,6 +978,7 @@ static void virtnet_remove(struct virtio_device *vdev) > > /* Free our skbs in send and recv queues, if any. */ > while ((skb = __skb_dequeue(&vi->recv)) != NULL) { > + trim_pages(vi, skb); > kfree_skb(skb); > vi->num--; > } > > > > >
Hello Avi, I do see memory leak after removing virtio_net module. There is 72KB per removal along with free already free IRQ. Maybe the memleak from virtio_pci, seems some lock is missing when accessing the irq list? Trying to free already-free IRQ 26 Modules linked in: virtio_net(-) sunrpc ipv6 virtio_balloon pcspkr virtio_blk virtio_pci virtio_ring virtio [last unloaded: virtio_net] Pid: 1641, comm: rmmod Tainted: G W 2.6.31-rc4 #11 Call Trace: [<c102bc50>] warn_slowpath_common+0x60/0x90 [<c102bcb4>] warn_slowpath_fmt+0x24/0x27 [<c105d472>] __free_irq+0x74/0x134 [<c105d53a>] free_irq+0x8/0xf [<e081012d>] vp_free_vectors+0x42/0x97 [virtio_pci] [<e0810262>] vp_del_vqs+0xe0/0xe8 [virtio_pci] [<e13de253>] virtnet_remove+0xf9/0x125 [virtio_net] [<e0801097>] virtio_dev_remove+0xf/0x33 [virtio] [<c116d5d4>] __device_release_driver+0x58/0x8e [<c116d667>] driver_detach+0x5d/0x7b [<c116cbe6>] bus_remove_driver+0x63/0x89 [<c116da58>] driver_unregister+0x4d/0x54 [<e0801304>] unregister_virtio_driver+0x8/0xa [virtio] [<e13df865>] fini+0xd/0x12 [virtio_net] [<c104d430>] sys_delete_module+0x180/0x1d7 [<c1085033>] ? remove_vma+0x55/0x5b [<c105ac6d>] ? audit_syscall_entry+0x102/0x124 [<c1002aa9>] syscall_call+0x7/0xb When loading the module, the complain is: ------------[ cut here ]------------ WARNING: at lib/list_debug.c:26 __list_add+0x27/0x5c() Hardware name: list_add corruption. next->prev should be prev (df88b3e0), but was df466770. (next=dfbdb8d0). Modules linked in: virtio_net(+) sunrpc ipv6 virtio_balloon pcspkr virtio_blk virtio_pci virtio_ring virtio [last unloaded: virtio_net] Pid: 1674, comm: modprobe Tainted: G W 2.6.31-rc4 #11 Call Trace: [<c102bc50>] warn_slowpath_common+0x60/0x90 [<c102bcb4>] warn_slowpath_fmt+0x24/0x27 [<c1114dcf>] __list_add+0x27/0x5c [<e08107d9>] vp_find_vqs+0x47d/0x53c [virtio_pci] [<e14202b9>] ? skb_recv_done+0x0/0x36 [virtio_net] [<e14210fc>] virtnet_probe+0x24f/0x376 [virtio_net] [<e14202b9>] ? skb_recv_done+0x0/0x36 [virtio_net] [<e142027f>] ? skb_xmit_done+0x0/0x3a [virtio_net] [<e08108cd>] ? vp_set_status+0x20/0x22 [virtio_pci] [<e080105d>] ? add_status+0x1f/0x24 [virtio] [<e080114c>] virtio_dev_probe+0x91/0xb0 [virtio] [<c116d7e3>] driver_probe_device+0x79/0x105 [<c116d8b2>] __driver_attach+0x43/0x5f [<c116d24d>] bus_for_each_dev+0x3d/0x67 [<c116d6bc>] driver_attach+0x14/0x16 [<c116d86f>] ? __driver_attach+0x0/0x5f -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, 11 Aug 2009 09:22:58 pm Avi Kivity wrote: > (copying Rusty, the virtio maintainer) > > On 08/10/2009 11:05 PM, Shirley Ma wrote: > > Whild reading virtio code, I found some memory leak in removing > > virtio_net. > > > > In virtnet_remove, only skb has been freed not the pages in skb > > frags. Here is the patch to fix this, please review it. Nope, kfree_skb() frees the frags. It needs to, otherwise we leak on every received packet! Cheers, Rusty. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Signed-off-by: Shirley Ma <xma@us.ibm.com> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c index 2a6e81d..7e629d9 100644 --- a/drivers/net/virtio_net.c +++ b/drivers/net/virtio_net.c @@ -978,6 +978,7 @@ static void virtnet_remove(struct virtio_device *vdev) /* Free our skbs in send and recv queues, if any. */ while ((skb = __skb_dequeue(&vi->recv)) != NULL) { + trim_pages(vi, skb); kfree_skb(skb); vi->num--; }
Whild reading virtio code, I found some memory leak in removing virtio_net. In virtnet_remove, only skb has been freed not the pages in skb frags. Here is the patch to fix this, please review it. Signed-off-by: Shirley Ma <xma@us.ibm.com>