similar to: [PATCH] virtio_net: Fix stalled inbound traffic on early packets

Hello Rusty, while implementing and testing virtio on s390 I found a problem in virtio_net: The current virtio_net driver has a startup race, which prevents any incoming traffic: If try_fill_recv submits buffers to the host system data might be filled in and an interrupt is sent, before napi_enable finishes. In that case the interrupt will kick skb_recv_done which will then call

Hello Rusty, while implementing and testing virtio on s390 I found a problem in virtio_net: The current virtio_net driver has a startup race, which prevents any incoming traffic: If try_fill_recv submits buffers to the host system data might be filled in and an interrupt is sent, before napi_enable finishes. In that case the interrupt will kick skb_recv_done which will then call

Please consider this patch for the 2.6.32, 2.6.33, and 2.6.34 stable trees as well as current development trees. (I've only tested on 2.6.32 however) virtio_net: Add schedule check to napi_enable call Under harsh testing conditions, including low memory, the guest would stop receiving packets. With this patch applied we no longer see any problems in the driver while performing

Please consider this patch for the 2.6.32, 2.6.33, and 2.6.34 stable trees as well as current development trees. (I've only tested on 2.6.32 however) virtio_net: Add schedule check to napi_enable call Under harsh testing conditions, including low memory, the guest would stop receiving packets. With this patch applied we no longer see any problems in the driver while performing

From: "Bruce Rogers" <brogers at novell.com> Under harsh testing conditions, including low memory, the guest would stop receiving packets. With this patch applied we no longer see any problems in the driver while performing these tests for extended periods of time. Make sure napi is scheduled subsequent to each napi_enable. Signed-off-by: Bruce Rogers <brogers at

From: "Bruce Rogers" <brogers at novell.com> Under harsh testing conditions, including low memory, the guest would stop receiving packets. With this patch applied we no longer see any problems in the driver while performing these tests for extended periods of time. Make sure napi is scheduled subsequent to each napi_enable. Signed-off-by: Bruce Rogers <brogers at

I got the following oops during interface ifup. Unfortunately its not easily reproducable so I cant say for sure that my fix fixes this problem, but I am confident and I think its correct anyway: <2>kernel BUG at /space/kvm/drivers/virtio/virtio_ring.c:234! <4>illegal operation: 0001 [#1] PREEMPT SMP <4>Modules linked in: <4>CPU: 0 Not tainted

I got the following oops during interface ifup. Unfortunately its not easily reproducable so I cant say for sure that my fix fixes this problem, but I am confident and I think its correct anyway: <2>kernel BUG at /space/kvm/drivers/virtio/virtio_ring.c:234! <4>illegal operation: 0001 [#1] PREEMPT SMP <4>Modules linked in: <4>CPU: 0 Not tainted

On Fri, 2013-12-27 at 12:55 +0800, Jason Wang wrote: > On 12/27/2013 05:56 AM, Eric Dumazet wrote: > > On Thu, 2013-12-26 at 13:28 -0800, Michael Dalton wrote: > >> On Mon, Dec 23, 2013 at 11:37 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > >>> So there isn't a conflict with respect to locking. > >>> > >>> Is it problematic to

On Fri, 2013-12-27 at 12:55 +0800, Jason Wang wrote: > On 12/27/2013 05:56 AM, Eric Dumazet wrote: > > On Thu, 2013-12-26 at 13:28 -0800, Michael Dalton wrote: > >> On Mon, Dec 23, 2013 at 11:37 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > >>> So there isn't a conflict with respect to locking. > >>> > >>> Is it problematic to

Justification: Impact: Under heavy network I/O load virtio-net driver crashes making VM guest unusable. Testcases: 1) Sergey Svishchev reports that servers that run java webapps with high java heap usage (especially when heap size is close to physical memory size) helps trigger one of aforementioned bugs. Unfortunately, I don't have a simple test case. 2) Peter Lieven reports that his

Justification: Impact: Under heavy network I/O load virtio-net driver crashes making VM guest unusable. Testcases: 1) Sergey Svishchev reports that servers that run java webapps with high java heap usage (especially when heap size is close to physical memory size) helps trigger one of aforementioned bugs. Unfortunately, I don't have a simple test case. 2) Peter Lieven reports that his

On Sun, Apr 02, 2017 at 04:10:11PM -0400, Willem de Bruijn wrote: > From: Willem de Bruijn <willemb at google.com> > > Convert virtio-net to a standard napi tx completion path. This enables > better TCP pacing using TCP small queues and increases single stream > throughput. > > The virtio-net driver currently cleans tx descriptors on transmission > of new packets in

On Thu, Dec 29, 2011 at 09:12:38PM +1030, Rusty Russell wrote: > Michael S. Tsirkin noticed that we could run the refill work after > ndo_close, which can re-enable napi - we don't disable it until > virtnet_remove. This is clearly wrong, so move the workqueue control > to ndo_open and ndo_stop (aka. virtnet_open and virtnet_close). > > One subtle point: virtnet_probe()

Since we want to reset the device to remove them, this is simpler (device is reset for us on driver remove). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> --- drivers/net/virtio_net.c | 44 +++++++++++++++++++++++++------------------- 1 file changed, 25 insertions(+), 19 deletions(-) diff -r 7e5b3ff06f60 drivers/net/virtio_net.c --- a/drivers/net/virtio_net.c Wed Jan 23 22:53:14

On Thu, Dec 29, 2011 at 09:12:38PM +1030, Rusty Russell wrote: > Michael S. Tsirkin noticed that we could run the refill work after > ndo_close, which can re-enable napi - we don't disable it until > virtnet_remove. This is clearly wrong, so move the workqueue control > to ndo_open and ndo_stop (aka. virtnet_open and virtnet_close). > > One subtle point: virtnet_probe()

From: Willem de Bruijn <willemb at google.com> Convert virtio-net to a standard napi tx completion path. This enables better TCP pacing using TCP small queues and increases single stream throughput. The virtio-net driver currently cleans tx descriptors on transmission of new packets in ndo_start_xmit. Latency depends on new traffic, so is unbounded. To avoid deadlock when a socket reaches

Since we want to reset the device to remove them, this is simpler (device is reset for us on driver remove). Signed-off-by: Rusty Russell <rusty@rustcorp.com.au> --- drivers/net/virtio_net.c | 44 +++++++++++++++++++++++++------------------- 1 file changed, 25 insertions(+), 19 deletions(-) diff -r 7e5b3ff06f60 drivers/net/virtio_net.c --- a/drivers/net/virtio_net.c Wed Jan 23 22:53:14

Fix theoretical races related to refill work: 1. After napi is disabled by ndo_stop, refill work can run and re-enable it. 2. Refill can reschedule itself, if this happens it can run after cancel_delayed_work_sync, and will access device after it is destroyed. As a solution, add flags to track napi state and to disable refill, and toggle them on start, stop and remove; check these flags

Fix theoretical races related to refill work: 1. After napi is disabled by ndo_stop, refill work can run and re-enable it. 2. Refill can reschedule itself, if this happens it can run after cancel_delayed_work_sync, and will access device after it is destroyed. As a solution, add flags to track napi state and to disable refill, and toggle them on start, stop and remove; check these flags