From: Brian Rak <brak@vultr.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: netdev@vger.kernel.org
Subject: Re: Repeatable IPv6 crash in 3.19.0-1
Date: Fri, 27 Feb 2015 20:54:16 -0500 [thread overview]
Message-ID: <54F11FC8.7010100@vultr.com> (raw)
In-Reply-To: <1425086169.5130.57.camel@edumazet-glaptop2.roam.corp.google.com>
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!
next prev parent reply other threads:[~2015-02-28 1:54 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-27 21:37 Repeatable IPv6 crash in 3.19.0-1 Brian Rak
2015-02-28 0:48 ` Eric Dumazet
2015-02-28 1:16 ` Eric Dumazet
2015-02-28 1:54 ` Brian Rak [this message]
2015-02-28 2:01 ` Eric Dumazet
2015-02-28 2:03 ` Eric Dumazet
2015-02-28 2:11 ` Brian Rak
2015-02-28 2:21 ` Eric Dumazet
2015-02-28 2:35 ` [PATCH net] macvtap: make sure neighbour code can push ethernet header Eric Dumazet
2015-03-01 5:30 ` David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=54F11FC8.7010100@vultr.com \
--to=brak@vultr.com \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.