similar to: [PATCH RFC] virtio_net: fix refill related races

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 get scheduled on many cpus in parallel. if this happens it will corrupt the vq linked list as there's no locking 3. refill work is cancelled after unregister netdev For small bufs this means it can alloc an skb for a device which is

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 get scheduled on many cpus in parallel. if this happens it will corrupt the vq linked list as there's no locking 3. refill work is cancelled after unregister netdev For small bufs this means it can alloc an skb for a device which is

Please consider this for the 2.6.32 stable tree: commit 39d321577405e8e269fd238b278aaf2425fa788a Author: Herbert Xu <herbert at gondor.apana.org.au> Date: Mon Jan 25 15:51:01 2010 -0800 virtio_net: Make delayed refill more reliable I have seen RX stalls on a machine that experienced a suspected OOM. After the stall, the RX buffer is empty on the guest side and there are

Please consider this for the 2.6.32 stable tree: commit 39d321577405e8e269fd238b278aaf2425fa788a Author: Herbert Xu <herbert at gondor.apana.org.au> Date: Mon Jan 25 15:51:01 2010 -0800 virtio_net: Make delayed refill more reliable I have seen RX stalls on a machine that experienced a suspected OOM. After the stall, the RX buffer is empty on the guest side and there are

As hypervior does not have the knowledge of guest network configuration, it's better to ask guest to send gratuitous packet when needed. Guest test VIRTIO_NET_S_ANNOUNCE bit during config change interrupt and when it is set, a workqueue is scheduled to send gratuitous packet through NETDEV_NOTIFY_PEERS. This feature is negotiated through bit VIRTIO_NET_F_GUEST_ANNOUNCE. Changes from v3: -

As hypervior does not have the knowledge of guest network configuration, it's better to ask guest to send gratuitous packet when needed. Guest test VIRTIO_NET_S_ANNOUNCE bit during config change interrupt and when it is set, a workqueue is scheduled to send gratuitous packet through NETDEV_NOTIFY_PEERS. This feature is negotiated through bit VIRTIO_NET_F_GUEST_ANNOUNCE. Changes from v3: -

As hypervior does not have the knowledge of guest network configuration, it's better to ask guest to send gratuitous packets when needed. Guest tests VIRTIO_NET_S_ANNOUNCE bit during config change interrupt and when it is set, a workqueue is scheduled to send gratuitous packet through NETDEV_NOTIFY_PEERS. This feature is negotiated through bit VIRTIO_NET_F_GUEST_ANNOUNCE. Changes from v4: -

As hypervior does not have the knowledge of guest network configuration, it's better to ask guest to send gratuitous packets when needed. Guest tests VIRTIO_NET_S_ANNOUNCE bit during config change interrupt and when it is set, a workqueue is scheduled to send gratuitous packet through NETDEV_NOTIFY_PEERS. This feature is negotiated through bit VIRTIO_NET_F_GUEST_ANNOUNCE. Changes from v4: -

As hypervior does not have the knowledge of guest network configuration, it's better to ask guest to send gratuitous packets when needed. Guest tests VIRTIO_NET_S_ANNOUNCE bit during config change interrupt and when it is set, a workqueue is scheduled to send gratuitous packet through NETDEV_NOTIFY_PEERS. This feature is negotiated through bit VIRTIO_NET_F_GUEST_ANNOUNCE. Changes from v5: -

As hypervior does not have the knowledge of guest network configuration, it's better to ask guest to send gratuitous packets when needed. Guest tests VIRTIO_NET_S_ANNOUNCE bit during config change interrupt and when it is set, a workqueue is scheduled to send gratuitous packet through NETDEV_NOTIFY_PEERS. This feature is negotiated through bit VIRTIO_NET_F_GUEST_ANNOUNCE. Changes from v5: -

Remove wrapper functions. This makes the allocation type explicit in all callers; I used GPF_KERNEL where it seemed obvious, left it at GFP_ATOMIC otherwise. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c --- a/drivers/block/virtio_blk.c +++ b/drivers/block/virtio_blk.c @@ -171,7 +171,7 @@ static bool

Remove wrapper functions. This makes the allocation type explicit in all callers; I used GPF_KERNEL where it seemed obvious, left it at GFP_ATOMIC otherwise. Signed-off-by: Rusty Russell <rusty at rustcorp.com.au> diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c --- a/drivers/block/virtio_blk.c +++ b/drivers/block/virtio_blk.c @@ -171,7 +171,7 @@ static bool

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

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

Use per-cpu variables to maintain 64 bit statistics. Compile tested only. Signed-off-by: Stephen Hemminger <shemminger at vyatta.com> --- a/drivers/net/virtio_net.c 2011-06-14 15:18:46.448596355 -0400 +++ b/drivers/net/virtio_net.c 2011-06-15 09:54:22.914426067 -0400 @@ -40,6 +40,15 @@ module_param(gso, bool, 0444); #define VIRTNET_SEND_COMMAND_SG_MAX 2 +struct virtnet_stats { +

Use per-cpu variables to maintain 64 bit statistics. Compile tested only. Signed-off-by: Stephen Hemminger <shemminger at vyatta.com> --- a/drivers/net/virtio_net.c 2011-06-14 15:18:46.448596355 -0400 +++ b/drivers/net/virtio_net.c 2011-06-15 09:54:22.914426067 -0400 @@ -40,6 +40,15 @@ module_param(gso, bool, 0444); #define VIRTNET_SEND_COMMAND_SG_MAX 2 +struct virtnet_stats { +

As hypervior does not have the knowledge of guest network configuration, it's better to ask guest to send gratuitous packets when needed. This patch implements VIRTIO_NET_F_GUEST_ANNOUNCE feature: hypervisor would notice the guest when it thinks it's time for guest to announce the link presnece. Guest tests VIRTIO_NET_S_ANNOUNCE bit during config change interrupt and woule send gratuitous

As hypervior does not have the knowledge of guest network configuration, it's better to ask guest to send gratuitous packets when needed. This patch implements VIRTIO_NET_F_GUEST_ANNOUNCE feature: hypervisor would notice the guest when it thinks it's time for guest to announce the link presnece. Guest tests VIRTIO_NET_S_ANNOUNCE bit during config change interrupt and woule send gratuitous