Received: by 10.213.65.68 with SMTP id h4csp2081181imn; Thu, 5 Apr 2018 08:38:59 -0700 (PDT) X-Google-Smtp-Source: AIpwx49Jx3zQgQubHiIwRRj+B7nWZ/3fgfu9JN3lWknTmeKXFh39Rwn/ZxvtRVUCyfzs+7A/Mrpv X-Received: by 10.101.69.133 with SMTP id o5mr15039426pgq.156.1522942739453; Thu, 05 Apr 2018 08:38:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522942739; cv=none; d=google.com; s=arc-20160816; b=Tcn0eisLyTpd2MZN/cusJ9h9IgEA7W54PsRXC+sK2lx9pw7jMKFmNh/40T3Ijy89DU E9nAswGmjacPRwLSUSldlmhiXWEyrR7Y8mEltLxxYlIq1BNn/TXYivAcdTGy4mBe3xBu P63i9Ke88J4t5wGa3UjOVAKWe9CJQFr+O1qozfBwUmuu5Cxq/XHcjU3S31DnyoEJ+DyY 5QDuwNMhynio3OOxtXeZ7+xoyEEUIcYTRY5DDuh3D+PbVaHuLRLQ7DbgqK9QnL5KGXp2 R6fpHK7bMHLR5s4QDCQfpflbGlfpExfNGg5tUTWSgKNrdiHheJebwYBPdF/APEWWQM96 aRDA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date:arc-authentication-results; bh=VBVKA3bu9GZg9OV13EcEDgCIGEpcYOK5dxPxS80MxIs=; b=P6TTrzuLoI9ySI5q0ZY6gQwy78vZIXSXsts9gTEcTwRPjYHHlCzoFtDu9ORSNFFmIj FnefjFPNYOs5uv9y+WSBs6AcHhvMtoeR3vs3WzHxKvvVtTDYjvv3Rde5Z6Auea6C03PS jq6Ez5TD/v44Dr9porEGnz4k1LCvfh+85JjZEAw1r2FxRHhIjM11CCRVypcFkZrBF+Or UOCq2elhBA1tZaikzbWLcPE/3wkeIp0tot1DaY5ng1Iziubtx5rRuf6gf0jP/xJkuBJg 2MHWjJCqZK8mjyjykKenJu6YpXMsgCbhXMcT8WMW0mUmm8QnUHr8HNPt1/pryLy8fRA+ T+Uw== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 91-v6si6066496plh.127.2018.04.05.08.38.45; Thu, 05 Apr 2018 08:38:59 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751443AbeDEPgp convert rfc822-to-8bit (ORCPT + 99 others); Thu, 5 Apr 2018 11:36:45 -0400 Received: from mx3-rdu2.redhat.com ([66.187.233.73]:59324 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1750835AbeDEPgn (ORCPT ); Thu, 5 Apr 2018 11:36:43 -0400 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 26BDA4005F9A; Thu, 5 Apr 2018 15:36:43 +0000 (UTC) Received: from epycfail (ovpn-112-18.ams2.redhat.com [10.36.112.18]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C5539215CDC6; Thu, 5 Apr 2018 15:36:40 +0000 (UTC) Date: Thu, 5 Apr 2018 17:36:36 +0200 From: Stefano Brivio To: Ben Hutchings , Greg Kroah-Hartman Cc: linux-kernel@vger.kernel.org, stable@vger.kernel.org, Petr Vorel , Alexey Kodanev , "David S. Miller" , Sasha Levin , Steffen Klassert Subject: Re: [PATCH 4.4 92/97] ip6_vti: adjust vti mtu according to mtu of lower device Message-ID: <20180405173636.5765efcf@epycfail> In-Reply-To: <1522800556.2654.158.camel@codethink.co.uk> References: <20180323094157.535925724@linuxfoundation.org> <20180323094202.622913188@linuxfoundation.org> <1522800556.2654.158.camel@codethink.co.uk> Organization: Red Hat MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Thu, 05 Apr 2018 15:36:43 +0000 (UTC) X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.6]); Thu, 05 Apr 2018 15:36:43 +0000 (UTC) for IP:'10.11.54.6' DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'sbrivio@redhat.com' RCPT:'' Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 04 Apr 2018 01:09:16 +0100 Ben Hutchings wrote: > On Fri, 2018-03-23 at 10:55 +0100, Greg Kroah-Hartman wrote: > > 4.4-stable review patch.  If anyone has any objections, please let me know. > > > > ------------------ > > > > From: Alexey Kodanev > > > > > > [ Upstream commit 53c81e95df1793933f87748d36070a721f6cb287 ] > [...] > > There are a couple of follow-ups to this: > > c6741fbed6dc vti6: Properly adjust vti6 MTU from MTU of lower device > 7a67e69a339a vti6: Keep set MTU on link creation or change, validate it > > The second of those will fail to build on branches older than 4.10 > though. It might be better to revert this one instead. Thanks Ben for spotting this. Actually, 53c81e95df17 ("ip6_vti: adjust vti mtu according to mtu of lower device") alone improves things already, despite being "fixed" by c6741fbed6dc ("vti6: Properly adjust vti6 MTU from MTU of lower device") With just 53c81e95df17 the MTU of a vti6 interface will be somewhat linked to the MTU of the lower layer, but will be underestimated. With c6741fbed6dc the calculation of MTU from lower layer will be accurate instead. However, without 7a67e69a339a ("vti6: Keep set MTU on link creation or change, validate it") but with 53c81e95df17 ("ip6_vti: adjust vti mtu according to mtu of lower device") assignment of MTU on link change is discarded, so this would actually introduce a bug. Fixing 7a67e69a339a ("vti6: Keep set MTU on link creation or change, validate it") for 4.4 up to 4.9 is trivial, we simply need to adjust for the lack of b96f9afee4eb ("ipv4/6: use core net MTU range checking") and reflect the change introduced by f8a554b4aa96 ("vti6: Fix dev->max_mtu setting"). So, Greg, here comes the backport of 7a67e69a339a ("vti6: Keep set MTU on link creation or change, validate it") based on latest linux-4.4.y branch, in case you want to keep the existing change and add the follow-ups on top. Please let me know if I should submit it formally. diff --git a/net/ipv6/ip6_vti.c b/net/ipv6/ip6_vti.c index 176e79076fb1..f388f54b4162 100644 --- a/net/ipv6/ip6_vti.c +++ b/net/ipv6/ip6_vti.c @@ -610,7 +610,7 @@ static int vti6_err(struct sk_buff *skb, struct inet6_skb_parm *opt, return 0; } -static void vti6_link_config(struct ip6_tnl *t) +static void vti6_link_config(struct ip6_tnl *t, bool keep_mtu) { struct net_device *dev = t->dev; struct __ip6_tnl_parm *p = &t->parms; @@ -629,6 +629,13 @@ static void vti6_link_config(struct ip6_tnl *t) else dev->flags &= ~IFF_POINTOPOINT; + if (keep_mtu && dev->mtu) { + dev->mtu = clamp(dev->mtu, (unsigned)IPV6_MIN_MTU, + (unsigned)(IP_MAX_MTU - + sizeof(struct ipv6hdr))); + return; + } + if (p->flags & IP6_TNL_F_CAP_XMIT) { int strict = (ipv6_addr_type(&p->raddr) & (IPV6_ADDR_MULTICAST | IPV6_ADDR_LINKLOCAL)); @@ -656,12 +663,14 @@ static void vti6_link_config(struct ip6_tnl *t) * vti6_tnl_change - update the tunnel parameters * @t: tunnel to be changed * @p: tunnel configuration parameters + * @keep_mtu: MTU was set from userspace, don't re-compute it * * Description: * vti6_tnl_change() updates the tunnel parameters **/ static int -vti6_tnl_change(struct ip6_tnl *t, const struct __ip6_tnl_parm *p) +vti6_tnl_change(struct ip6_tnl *t, const struct __ip6_tnl_parm *p, + bool keep_mtu) { t->parms.laddr = p->laddr; t->parms.raddr = p->raddr; @@ -670,11 +679,12 @@ vti6_tnl_change(struct ip6_tnl *t, const struct __ip6_tnl_parm *p) t->parms.o_key = p->o_key; t->parms.proto = p->proto; dst_cache_reset(&t->dst_cache); - vti6_link_config(t); + vti6_link_config(t, keep_mtu); return 0; } -static int vti6_update(struct ip6_tnl *t, struct __ip6_tnl_parm *p) +static int vti6_update(struct ip6_tnl *t, struct __ip6_tnl_parm *p, + bool keep_mtu) { struct net *net = dev_net(t->dev); struct vti6_net *ip6n = net_generic(net, vti6_net_id); @@ -682,7 +692,7 @@ static int vti6_update(struct ip6_tnl *t, struct __ip6_tnl_parm *p) vti6_tnl_unlink(ip6n, t); synchronize_net(); - err = vti6_tnl_change(t, p); + err = vti6_tnl_change(t, p, keep_mtu); vti6_tnl_link(ip6n, t); netdev_state_change(t->dev); return err; @@ -795,7 +805,7 @@ vti6_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd) } else t = netdev_priv(dev); - err = vti6_update(t, &p1); + err = vti6_update(t, &p1, false); } if (t) { err = 0; @@ -907,7 +917,7 @@ static int vti6_dev_init(struct net_device *dev) if (err) return err; - vti6_link_config(t); + vti6_link_config(t, true); return 0; } @@ -1006,7 +1016,7 @@ static int vti6_changelink(struct net_device *dev, struct nlattr *tb[], } else t = netdev_priv(dev); - return vti6_update(t, &p); + return vti6_update(t, &p, tb && tb[IFLA_MTU]); } static size_t vti6_get_size(const struct net_device *dev) -- Stefano