Messages in this thread | | | Date | Thu, 7 Feb 2013 10:15:29 +0200 | From | "Michael S. Tsirkin" <> | Subject | Re: [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.
| |