lkml.org 
[lkml]   [2013]   [Feb]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 0/2] fix kernel crash with macvtap on top of LRO
On Thu, Feb 07, 2013 at 11:25:13AM +0800, Cong Wang wrote:
> On 02/07/2013 07:02 AM, Michael S. Tsirkin wrote:
> >At the moment, macvtap crashes are observed if macvtap is attached
> >to an interface with LRO enabled.
> >The crash in question is BUG() in macvtap_skb_to_vnet_hdr.
> >This happens because several drivers set gso_size but not gso_type
> >in incoming skbs.
> >The following patches fix this for
> >Additionally, cbf1de72324a8105ddcc3d9ce9acbc613faea17e is required
> >to fix this for broadcom - would it make sense to cherry-pick
> >this patch into 3.8?
>
>
> Doesn't macvtap need to call skb_warn_if_lro() too like bridge and
> openvswitch? Something like...

This is what Ben proposed a year ago
http://thread.gmane.org/gmane.linux.network/221695
but apparently people really want LRO to work with macvtap.

> diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
> index b181dfb..b2c6227 100644
> --- a/drivers/net/macvtap.c
> +++ b/drivers/net/macvtap.c
> @@ -253,6 +253,9 @@ static int macvtap_forward(struct net_device
> *dev, struct sk_buff *skb)
> if (!q)
> goto drop;
>
> + if (unlikely(skb_warn_if_lro(skb)))
> + goto drop;
> +
> if (skb_queue_len(&q->sk.sk_receive_queue) >= dev->tx_queue_len)
> goto drop;
>
>
> I am not saying these drivers don't need to fix, I am just saying if
> we need to fix LRO case.
>
> Thanks.


\
 
 \ /
  Last update: 2013-02-07 10:01    [W:0.130 / U:0.084 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site