Re: [PATCH] bridge: orphan frags on local receive

[Jason Wang <jasowang@redhat.com>]

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@huawei.com>
> ---
>  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) ?