Received: by 10.213.65.68 with SMTP id h4csp286558imn; Fri, 23 Mar 2018 04:46:30 -0700 (PDT) X-Google-Smtp-Source: AG47ELu5duRYqyVnfU7OQ0DdAg1QJtd4Xyt8SPHPAP6sliSf5BwmLTmP0i8CHI2MsCjXrqCbb/+W X-Received: by 10.101.93.17 with SMTP id e17mr21175800pgr.239.1521805590423; Fri, 23 Mar 2018 04:46:30 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521805590; cv=none; d=google.com; s=arc-20160816; b=E1jhRmMC18Rbz0fIgXRPCwqKMQ9hC3S0WGNeXwVdumSoyhF4g6YBoi2HWocVu4z7Xz B1mdG3EXMsv9uCHhFDbMNMu1Sdp9Jm8ZXSNYtnVbHxSNaPtyn6XuwIhBZnNxyPe6qT8a oAhAFxpFezTAL5wPeE+R35YtcfQHLZB5VsC89eqs/Kh9ajYwxj8nN4o9hJjmjb6cIzTR 2PAmZcPzAl2pH0CmdzUvU2bXkMOTmPIupP7bvF19qcmfLqij+JVR4w0uKJgMkgjjO1xL 3n/sh8TvTSa3mtyK2u7v5m1rBuS+EopzLLryABSv9CIvGx8LBCzbv8jBefYmqLOlQoLx CAVg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :in-reply-to:message-id:date:subject:cc:to:from :arc-authentication-results; bh=u/sTDUHk/9ooaWa/HxYNf3HTJGv/1r90l5DDBMB2cck=; b=Hx7boCwpf/7Cp4TvHYDJsT1xDSEasx5QRosJ1w0YnmzhG+5Wsj4KV+gmlpKAL0I7k8 HEB9SqxQnJZxM5e6f2aGVRPA9yxgcaBWs7201VW5DGcgc+LrbmasTzrxuIYbLu64/LJX 0o3rLjhlai4j9brix2hxZKMxt1BcY7SOZHQR7hHtqWszPm5QDO5sTQ5Z+cV6QtXUQ0Qd 9U6djP0W710kYfSlhJWQNILEWphlM/OM9OnKTl3RHObIGS3qcbVaR5fdInTL6y2Lkem7 ZlChVAkI0tNAMUkGfINrpEfO+43uwZW5Hiwt2SGP2m4hZILq04GmKvtZ80LfXTgpSsy2 xCrw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id e9si5971084pgo.61.2018.03.23.04.46.15; Fri, 23 Mar 2018 04:46:30 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754653AbeCWLpR (ORCPT + 99 others); Fri, 23 Mar 2018 07:45:17 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:38648 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754383AbeCWKDK (ORCPT ); Fri, 23 Mar 2018 06:03:10 -0400 Received: from localhost (LFbn-1-12247-202.w90-92.abo.wanadoo.fr [90.92.61.202]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 69E6A12DC; Fri, 23 Mar 2018 10:03:09 +0000 (UTC) From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Petr Vorel , Alexey Kodanev , "David S. Miller" , Sasha Levin Subject: [PATCH 4.14 52/77] ip6_vti: adjust vti mtu according to mtu of lower device Date: Fri, 23 Mar 2018 10:54:26 +0100 Message-Id: <20180323094145.739285432@linuxfoundation.org> X-Mailer: git-send-email 2.16.2 In-Reply-To: <20180323094142.260022880@linuxfoundation.org> References: <20180323094142.260022880@linuxfoundation.org> User-Agent: quilt/0.65 X-stable: review MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 4.14-stable review patch. If anyone has any objections, please let me know. ------------------ From: Alexey Kodanev [ Upstream commit 53c81e95df1793933f87748d36070a721f6cb287 ] LTP/udp6_ipsec_vti tests fail when sending large UDP datagrams over ip6_vti that require fragmentation and the underlying device has an MTU smaller than 1500 plus some extra space for headers. This happens because ip6_vti, by default, sets MTU to ETH_DATA_LEN and not updating it depending on a destination address or link parameter. Further attempts to send UDP packets may succeed because pmtu gets updated on ICMPV6_PKT_TOOBIG in vti6_err(). In case the lower device has larger MTU size, e.g. 9000, ip6_vti works but not using the possible maximum size, output packets have 1500 limit. The above cases require manual MTU setup after ip6_vti creation. However ip_vti already updates MTU based on lower device with ip_tunnel_bind_dev(). Here is the example when the lower device MTU is set to 9000: # ip a sh ltp_ns_veth2 ltp_ns_veth2@if7: mtu 9000 ... inet 10.0.0.2/24 scope global ltp_ns_veth2 inet6 fd00::2/64 scope global # ip li add vti6 type vti6 local fd00::2 remote fd00::1 # ip li show vti6 vti6@NONE: mtu 1500 ... link/tunnel6 fd00::2 peer fd00::1 After the patch: # ip li add vti6 type vti6 local fd00::2 remote fd00::1 # ip li show vti6 vti6@NONE: mtu 8832 ... link/tunnel6 fd00::2 peer fd00::1 Reported-by: Petr Vorel Signed-off-by: Alexey Kodanev Signed-off-by: David S. Miller Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman --- net/ipv6/ip6_vti.c | 20 ++++++++++++++++++++ 1 file changed, 20 insertions(+) --- a/net/ipv6/ip6_vti.c +++ b/net/ipv6/ip6_vti.c @@ -626,6 +626,7 @@ static void vti6_link_config(struct ip6_ { struct net_device *dev = t->dev; struct __ip6_tnl_parm *p = &t->parms; + struct net_device *tdev = NULL; memcpy(dev->dev_addr, &p->laddr, sizeof(struct in6_addr)); memcpy(dev->broadcast, &p->raddr, sizeof(struct in6_addr)); @@ -638,6 +639,25 @@ static void vti6_link_config(struct ip6_ dev->flags |= IFF_POINTOPOINT; else dev->flags &= ~IFF_POINTOPOINT; + + if (p->flags & IP6_TNL_F_CAP_XMIT) { + int strict = (ipv6_addr_type(&p->raddr) & + (IPV6_ADDR_MULTICAST | IPV6_ADDR_LINKLOCAL)); + struct rt6_info *rt = rt6_lookup(t->net, + &p->raddr, &p->laddr, + p->link, strict); + + if (rt) + tdev = rt->dst.dev; + ip6_rt_put(rt); + } + + if (!tdev && p->link) + tdev = __dev_get_by_index(t->net, p->link); + + if (tdev) + dev->mtu = max_t(int, tdev->mtu - dev->hard_header_len, + IPV6_MIN_MTU); } /**