similar to: [PATCH net] virtio-net: correctly delete napi hash

On Thu, Mar 12, 2015 at 01:57:44PM +0800, Jason Wang wrote: > We don't delete napi from hash list during module exit. This will > cause the following panic when doing module load and unload: > > BUG: unable to handle kernel paging request at 0000004e00000075 > IP: [<ffffffff816bd01b>] napi_hash_add+0x6b/0xf0 > PGD 3c5d5067 PUD 0 > Oops: 0000 [#1] SMP > ... >

On Thu, Mar 12, 2015 at 01:57:44PM +0800, Jason Wang wrote: > We don't delete napi from hash list during module exit. This will > cause the following panic when doing module load and unload: > > BUG: unable to handle kernel paging request at 0000004e00000075 > IP: [<ffffffff816bd01b>] napi_hash_add+0x6b/0xf0 > PGD 3c5d5067 PUD 0 > Oops: 0000 [#1] SMP > ... >

When sending control commands, virtio net sets up several buffers for DMA. The buffers are all part of the net device which means it's actually allocated by kvmalloc so in theory (on extreme memory pressure) it's possible to get a vmalloc'ed buffer which on some platforms means we can't DMA there. Fix up by moving the DMA buffers out into a separate structure. Reported-by:

On 12/05/2013 10:36 PM, Andrey Vagin wrote: > free_netdev calls netif_napi_del too, but it's too late, because napi > structures are placed on vi->rq. netif_napi_add() is called from > virtnet_alloc_queues. > > general protection fault: 0000 [#1] SMP > Dumping ftrace buffer: > (ftrace buffer empty) > Modules linked in: ip6table_filter ip6_tables iptable_filter

On 12/05/2013 10:36 PM, Andrey Vagin wrote: > free_netdev calls netif_napi_del too, but it's too late, because napi > structures are placed on vi->rq. netif_napi_add() is called from > virtnet_alloc_queues. > > general protection fault: 0000 [#1] SMP > Dumping ftrace buffer: > (ftrace buffer empty) > Modules linked in: ip6table_filter ip6_tables iptable_filter

When ring size is small (<32 entries) making buffers smaller means a full ring might not be able to hold enough buffers to fit a single large packet. Make sure a ring full of buffers is large enough to allow at least one packet of max size. Fixes: 2613af0ed18a ("virtio_net: migrate mergeable rx buffers to page frag allocators") Signed-off-by: Michael S. Tsirkin <mst at

When ring size is small (<32 entries) making buffers smaller means a full ring might not be able to hold enough buffers to fit a single large packet. Make sure a ring full of buffers is large enough to allow at least one packet of max size. Fixes: 2613af0ed18a ("virtio_net: migrate mergeable rx buffers to page frag allocators") Signed-off-by: Michael S. Tsirkin <mst at

When ring size is small (<32 entries) making buffers smaller means a full ring might not be able to hold enough buffers to fit a single large packet. Make sure a ring full of buffers is large enough to allow at least one packet of max size. Fixes: 2613af0ed18a ("virtio_net: migrate mergeable rx buffers to page frag allocators") Signed-off-by: Michael S. Tsirkin <mst at

When ring size is small (<32 entries) making buffers smaller means a full ring might not be able to hold enough buffers to fit a single large packet. Make sure a ring full of buffers is large enough to allow at least one packet of max size. Fixes: 2613af0ed18a ("virtio_net: migrate mergeable rx buffers to page frag allocators") Signed-off-by: Michael S. Tsirkin <mst at

On 2014/12/1 18:17, Jason Wang wrote: > On newer hosts that support delayed tx interrupts, > we probably don't have much to gain from orphaning > packets early. > > Note: this might degrade performance for > hosts without event idx support. > Should be addressed by the next patch. > > Cc: Rusty Russell <rusty at rustcorp.com.au> > Cc: Michael S. Tsirkin

On 2014/12/1 18:17, Jason Wang wrote: > On newer hosts that support delayed tx interrupts, > we probably don't have much to gain from orphaning > packets early. > > Note: this might degrade performance for > hosts without event idx support. > Should be addressed by the next patch. > > Cc: Rusty Russell <rusty at rustcorp.com.au> > Cc: Michael S. Tsirkin

They can be easy to reproduce, if you try to unload virtio-net Andrey Vagin (2): virtio-net: determine type of bufs correctly virtio: delete napi objects from netdev before releasing memory drivers/net/virtio_net.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) Cc: Rusty Russell <rusty at rustcorp.com.au> Cc: "Michael S. Tsirkin" <mst at redhat.com>

They can be easy to reproduce, if you try to unload virtio-net Andrey Vagin (2): virtio-net: determine type of bufs correctly virtio: delete napi objects from netdev before releasing memory drivers/net/virtio_net.c | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) Cc: Rusty Russell <rusty at rustcorp.com.au> Cc: "Michael S. Tsirkin" <mst at redhat.com>

Commit 2613af0ed18a ("virtio_net: migrate mergeable rx buffers to page frag allocators") changed the mergeable receive buffer size from PAGE_SIZE to MTU-size, introducing a single-stream regression for benchmarks with large average packet size. There is no single optimal buffer size for all workloads. For workloads with packet size <= MTU bytes, MTU + virtio-net header-sized buffers

free_netdev calls netif_napi_del too, but it's too late, because napi structures are placed on vi->rq. netif_napi_add() is called from virtnet_alloc_queues. general protection fault: 0000 [#1] SMP Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: ip6table_filter ip6_tables iptable_filter ip_tables virtio_balloon pcspkr virtio_net(-) i2c_pii CPU: 1 PID: 347 Comm: rmmod Not

When sending control commands, virtio net sets up several buffers for DMA. The buffers are all part of the net device which means it's actually allocated by kvmalloc so it's in theory (on extreme memory pressure) possible to get a vmalloc'ed buffer which on some platforms means we can't DMA there. Fix up by moving the DMA buffers into a separate structure. Reported-by: Mikulas

On newer hosts that support delayed tx interrupts, we probably don't have much to gain from orphaning packets early. Based on patch by Jason Wang. Note: this will likely degrade performance for hosts without event idx support. Various fallback options are available, including orphaning conditionally. Testing TBD. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> ---

On newer hosts that support delayed tx interrupts, we probably don't have much to gain from orphaning packets early. Based on patch by Jason Wang. Note: this will likely degrade performance for hosts without event idx support. Various fallback options are available, including orphaning conditionally. Testing TBD. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> ---

On newer hosts that support delayed tx interrupts, we probably don't have much to gain from orphaning packets early. Based on patch by Jason Wang. Note: this might degrade performance for hosts without event idx support. Should be addressed by the next patch. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/net/virtio_net.c | 137

On newer hosts that support delayed tx interrupts, we probably don't have much to gain from orphaning packets early. Based on patch by Jason Wang. Note: this might degrade performance for hosts without event idx support. Should be addressed by the next patch. Signed-off-by: Michael S. Tsirkin <mst at redhat.com> --- drivers/net/virtio_net.c | 137