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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <530C13AE.9030906@redhat.com>
Date:	Tue, 25 Feb 2014 11:53:18 +0800
From:	Jason Wang <jasowang@...hat.com>
To:	Qin Chuanyu <qinchuanyu@...wei.com>, davem@...emloft.net,
	"Michael S. Tsirkin" <mst@...hat.com>
CC:	KVM list <kvm@...r.kernel.org>, netdev@...r.kernel.org
Subject: Re: [PATCH] bridge: orphan frags on local receive

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@...wei.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) ?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html