From mboxrd@z Thu Jan 1 00:00:00 1970 From: Brian Rak Subject: Re: Repeatable IPv6 crash in 3.19.0-1 Date: Fri, 27 Feb 2015 20:54:16 -0500 Message-ID: <54F11FC8.7010100@vultr.com> References: <54F0E38C.5060203@vultr.com> <1425084533.5130.54.camel@edumazet-glaptop2.roam.corp.google.com> <1425086169.5130.57.camel@edumazet-glaptop2.roam.corp.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: netdev@vger.kernel.org To: Eric Dumazet Return-path: Received: from mail.choopa.net ([216.155.136.52]:59902 "EHLO mail.choopa.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750778AbbB1ByQ (ORCPT ); Fri, 27 Feb 2015 20:54:16 -0500 In-Reply-To: <1425086169.5130.57.camel@edumazet-glaptop2.roam.corp.google.com> Sender: netdev-owner@vger.kernel.org List-ID: On 2/27/2015 8:16 PM, Eric Dumazet wrote: > On Fri, 2015-02-27 at 16:48 -0800, Eric Dumazet wrote: >> On Fri, 2015-02-27 at 16:37 -0500, Brian Rak wrote: >>> I've been seeing a crash under 3.19.0 that seems to occur when I put >>> heavy traffic across a macvtap/veth interface. >>> >>> We have a KVM guest attached to a veth pair using macvtap. We're >>> routing IPv6 traffic into one end of the veth pair using some static >>> routes. We do *not* have proxy_ndp enabled (though, we are using some >>> software to do neighbor proxying - http://priv.nu/projects/ndppd/ ). >>> >>> I've been able to reproduce this pretty easily by downloading some large >>> files from the guest. We see two traces in a row when this occurs: >> >> >> Nice ! >> >> Crash is in neigh_hh_output() >> >> -> memcpy(skb->data - HH_DATA_MOD, hh->hh_data, HH_DATA_MOD); >> >> And there is only 14 bytes of headroom instead of 16. >> >> Some layer did not align skb_headroom(skb) to HH_DATA_MOD for ethernet >> header. > > Could you try following patch ? > > diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c > index e40fdfccc9c10df4ea8676a1dd59275d5d9c6b88..27ecc5c4fa2665cd42ac1ca81717255f85507113 100644 > --- a/drivers/net/macvtap.c > +++ b/drivers/net/macvtap.c > @@ -654,11 +654,14 @@ static void macvtap_skb_to_vnet_hdr(struct macvtap_queue *q, > } /* else everything is zero */ > } > > +/* Neighbour code has some assumptions on HH_DATA_MOD alignment */ > +#define MACVTAP_RESERVE HH_DATA_OFF(ETH_HLEN) > + > /* Get packet from user space buffer */ > static ssize_t macvtap_get_user(struct macvtap_queue *q, struct msghdr *m, > struct iov_iter *from, int noblock) > { > - int good_linear = SKB_MAX_HEAD(NET_IP_ALIGN); > + int good_linear = SKB_MAX_HEAD(MACVTAP_RESERVE); > struct sk_buff *skb; > struct macvlan_dev *vlan; > unsigned long total_len = iov_iter_count(from); > @@ -722,7 +725,7 @@ static ssize_t macvtap_get_user(struct macvtap_queue *q, struct msghdr *m, > linear = macvtap16_to_cpu(q, vnet_hdr.hdr_len); > } > > - skb = macvtap_alloc_skb(&q->sk, NET_IP_ALIGN, copylen, > + skb = macvtap_alloc_skb(&q->sk, MACVTAP_RESERVE, copylen, > linear, noblock, &err); > if (!skb) > goto err; > > Wow, that was *much* faster then I was expecting, thanks a bunch! I can confirm that resolves the issue.. I've tested this and it fixes the issue perfectly. I've been able to put a whole bunch of IPv6 traffic through the interface now, whereas before even a minor amount of traffic would crash the host. Thanks again!