On Mon, Feb 24, 2014 at 09:52:11PM +0800, Qin Chuanyu wrote:
> On 2014/2/24 21:29, Michael S. Tsirkin wrote:
> >On Mon, Feb 24, 2014 at 09:12:20PM +0800, Qin Chuanyu wrote:
> >>with vhost tx zero_copy, guest nic might get hang when host reserving
> >>skb in socket queue delivered by guest, the case has been solved in
> >>tun, it also been needed by bridge. This could easily happened when a
> >>LAST_ACK state tcp occuring between guest and host.
> >>
> >>Signed-off-by: Chuanyu Qin <[email protected]>
> >
> >Do you actually observe guest hang?
> >
> yes, guest nic could not xmit any more until the skb holded by host has
> been freed, the mainly reason is that though virtio-net could use vring
> desc out of order, but ubufs is been used by vhost in order. so only
> one skb could cause guest nic hang.
> >I would expect orphan frags in
> >__netif_receive_skb_core to be enough.
> >
> yes, it would be better. I would deliver another patch soon.

well __netif_receive_skb_core already calls orphan frags already.
What's left to do?

> >
> >>---
> >>  net/bridge/br_input.c |    3 +++
> >>  1 files changed, 3 insertions(+), 0 deletions(-)
> >>
> >>diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
> >>index 28d5446..744e27a 100644
> >>--- a/net/bridge/br_input.c
> >>+++ b/net/bridge/br_input.c
> >>@@ -117,6 +117,8 @@ int br_handle_frame_finish(struct sk_buff *skb)
> >>            br->dev->stats.multicast++;
> >>    } else if ((dst = __br_fdb_get(br, dest, vid)) &&
> >>                    dst->is_local) {
> >>+           if (unlikely(skb_orphan_frags(skb, GFP_ATOMIC)))
> >>+                   goto drop;
> >>            skb2 = skb;
> >>            /* Do not forward the packet since it's local. */
> >>            skb = NULL;
> >>@@ -136,6 +138,7 @@ int br_handle_frame_finish(struct sk_buff *skb)
> >>  out:
> >>    return 0;
> >>  drop:
> >>+   skb_tx_error(skb);
> >>    kfree_skb(skb);
> >>    goto out;
> >>  }
> >>--
> >>1.7.3.1.msysgit.0
> >
> >
> 
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to