On 02/24/2014 09:12 PM, 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 <qinchuanyu@xxxxxxxxxx>
> ---
> 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;
> }
Pretty similar to the issue we found for non-work conserving qdiscs. The
questions is whether or not should we audit all such cases ( I believe
we could find even more ) and does the skb_orphan_frags(), or doing
something like switch to use data copy in this case
I will post a patch that switch to use data copy when the number of
pending DMAs exceed a limit. Looks like it can help here.
Another question is whether or nor do we need a skb_orphan() here now
(at least for packets from tun) ?
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
