search for: netif_rx_complete

...;] do_extint+0xcc/0xf8 [<00000000001135d0>] ext_no_vtime+0x16/0x1a [<000000000010a57e>] cpu_idle+0x216/0x238 I think there is a valid code path, triggering this bug: CPU1 CPU2 ----------------------- ----------------------- - virtnet_poll found no more packets on queue - netif_rx_complete allow poll to be called - vq_ops->restart is called - vq Interrupts are enabled . <new packets arrive> <vcpu is scheduled away> . - interrupt is delivered . - poll is called . - poll work is done . - netif_rx_complete . - vq_ops->restart is calle...

...;] do_extint+0xcc/0xf8 [<00000000001135d0>] ext_no_vtime+0x16/0x1a [<000000000010a57e>] cpu_idle+0x216/0x238 I think there is a valid code path, triggering this bug: CPU1 CPU2 ----------------------- ----------------------- - virtnet_poll found no more packets on queue - netif_rx_complete allow poll to be called - vq_ops->restart is called - vq Interrupts are enabled . <new packets arrive> <vcpu is scheduled away> . - interrupt is delivered . - poll is called . - poll work is done . - netif_rx_complete . - vq_ops->restart is calle...

...x1a Last Breaking-Event-Address: [<00000000002d0ec4>] vring_enable_cb+0x18/0x60 I looked into the virtio_net code for some time and I think the following scenario happened. Please look at virtnet_poll: [...] /* Out of packets? */ if (received < budget) { netif_rx_complete(vi->dev, napi); if (unlikely(!vi->rvq->vq_ops->enable_cb(vi->rvq)) && napi_schedule_prep(napi)) { vi->rvq->vq_ops->disable_cb(vi->rvq); __netif_rx_schedule(vi->dev, napi);...

...x1a Last Breaking-Event-Address: [<00000000002d0ec4>] vring_enable_cb+0x18/0x60 I looked into the virtio_net code for some time and I think the following scenario happened. Please look at virtnet_poll: [...] /* Out of packets? */ if (received < budget) { netif_rx_complete(vi->dev, napi); if (unlikely(!vi->rvq->vq_ops->enable_cb(vi->rvq)) && napi_schedule_prep(napi)) { vi->rvq->vq_ops->disable_cb(vi->rvq); __netif_rx_schedule(vi->dev, napi);...

...0>] vring_interrupt+0x5c/0x6c [<000000000010ab08>] do_extint+0xb8/0xf0 [<0000000000110716>] ext_no_vtime+0x16/0x1a [<0000000000107e72>] cpu_idle+0x1c2/0x1e0 The problem can be triggered with a high amount of host->guest traffic. I think its the following race: poll says netif_rx_complete poll calls enable_cb enable_cb opens the interrupt mask a new packet comes, an interrupt is triggered----\ enable_cb sees that there is more work | enable_cb disables the interrupt | . V . int...

...0>] vring_interrupt+0x5c/0x6c [<000000000010ab08>] do_extint+0xb8/0xf0 [<0000000000110716>] ext_no_vtime+0x16/0x1a [<0000000000107e72>] cpu_idle+0x1c2/0x1e0 The problem can be triggered with a high amount of host->guest traffic. I think its the following race: poll says netif_rx_complete poll calls enable_cb enable_cb opens the interrupt mask a new packet comes, an interrupt is triggered----\ enable_cb sees that there is more work | enable_cb disables the interrupt | . V . int...

...- a/drivers/net/virtio_net.c Thu Nov 15 13:47:28 2007 +1100 +++ b/drivers/net/virtio_net.c Thu Nov 15 23:10:44 2007 +1100 @@ -198,8 +198,8 @@ again: if (vi->num < vi->max / 2) try_fill_recv(vi); - /* All done? */ - if (!skb) { + /* Out of packets? */ + if (received < budget) { netif_rx_complete(vi->dev, napi); if (unlikely(!vi->rvq->vq_ops->restart(vi->rvq)) && netif_rx_reschedule(vi->dev, napi))

...- a/drivers/net/virtio_net.c Thu Nov 15 13:47:28 2007 +1100 +++ b/drivers/net/virtio_net.c Thu Nov 15 23:10:44 2007 +1100 @@ -198,8 +198,8 @@ again: if (vi->num < vi->max / 2) try_fill_recv(vi); - /* All done? */ - if (!skb) { + /* Out of packets? */ + if (received < budget) { netif_rx_complete(vi->dev, napi); if (unlikely(!vi->rvq->vq_ops->restart(vi->rvq)) && netif_rx_reschedule(vi->dev, napi))

Hollis Blanchard wrote: > On Tue, 2008-03-25 at 14:45 +0100, Christian Ehrhardt wrote: >> => from one not yet defined point our guest seems to receive absolutely nothing >> => when the guest is hanging it sends nfs requests which are seen externally, but it does not seem to get the respones >> => the arp requests for the guest are repeated - maybe we can add some very

Hollis Blanchard wrote: > On Tue, 2008-03-25 at 14:45 +0100, Christian Ehrhardt wrote: >> => from one not yet defined point our guest seems to receive absolutely nothing >> => when the guest is hanging it sends nfs requests which are seen externally, but it does not seem to get the respones >> => the arp requests for the guest are repeated - maybe we can add some very

...b/hack-module.awk index 580090b..bd63fb9 100644 --- a/hack-module.awk +++ b/hack-module.awk @@ -45,8 +45,8 @@ print " return 1;"; print " }"; print ""; - print " no_work = vi->rvq->vq_ops->enable_cb(vi->rvq);"; print " netif_rx_complete(vi->dev);"; + print " no_work = vi->rvq->vq_ops->enable_cb(vi->rvq);"; print ""; print " if (!no_work && netif_rx_reschedule(vi->dev, received)) {"; print " skb = NULL;"; @@ -62,6 +62,32 @@ virtnet_poll =...

Hi again all, It turns out that networking really wants ordered requests, which the previous patches didn't allow. This patch changes it to a callback mechanism; kudos to Avi. The downside is that locking is more complicated, and after a few dead ends I implemented the simplest solution: the struct virtio_device contains the spinlock to use, and it's held when your callbacks get

Hi again all, It turns out that networking really wants ordered requests, which the previous patches didn't allow. This patch changes it to a callback mechanism; kudos to Avi. The downside is that locking is more complicated, and after a few dead ends I implemented the simplest solution: the struct virtio_device contains the spinlock to use, and it's held when your callbacks get

Hi again all, It turns out that networking really wants ordered requests, which the previous patches didn't allow. This patch changes it to a callback mechanism; kudos to Avi. The downside is that locking is more complicated, and after a few dead ends I implemented the simplest solution: the struct virtio_device contains the spinlock to use, and it's held when your callbacks get

Hi all, These are the patches I'm planning to submit for 2.6.24. Comments gratefully accepted. Along with the usual cleanups and improvements are Jes' de-i386-ification patches, and a new "virtio" mechanism designed to be shared with KVM (and hopefully other hypervisors). Cheers, Rusty. Documentation/lguest/Makefile | 30 Documentation/lguest/lguest.c

Hi all, These are the patches I'm planning to submit for 2.6.24. Comments gratefully accepted. Along with the usual cleanups and improvements are Jes' de-i386-ification patches, and a new "virtio" mechanism designed to be shared with KVM (and hopefully other hypervisors). Cheers, Rusty. Documentation/lguest/Makefile | 30 Documentation/lguest/lguest.c