From patchwork Sun Apr 7 06:46:26 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Miaohe Lin X-Patchwork-Id: 1079861 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming-netdev@ozlabs.org Delivered-To: patchwork-incoming-netdev@ozlabs.org Authentication-Results: ozlabs.org; spf=none (mailfrom) smtp.mailfrom=vger.kernel.org (client-ip=209.132.180.67; helo=vger.kernel.org; envelope-from=netdev-owner@vger.kernel.org; receiver=) Authentication-Results: ozlabs.org; dmarc=none (p=none dis=none) header.from=huawei.com Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 44cPHJ4tqTz9sQp for ; Sun, 7 Apr 2019 16:47:08 +1000 (AEST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726123AbfDGGqp (ORCPT ); Sun, 7 Apr 2019 02:46:45 -0400 Received: from szxga05-in.huawei.com ([45.249.212.191]:6262 "EHLO huawei.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1725942AbfDGGqp (ORCPT ); Sun, 7 Apr 2019 02:46:45 -0400 Received: from DGGEMS406-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 83CDA5650AA3E257D21D; Sun, 7 Apr 2019 14:46:33 +0800 (CST) Received: from [127.0.0.1] (10.184.189.20) by DGGEMS406-HUB.china.huawei.com (10.3.19.206) with Microsoft SMTP Server id 14.3.408.0; Sun, 7 Apr 2019 14:46:26 +0800 To: David Ahern , Shrijeet Mukherjee , , , CC: Mingfangsen From: linmiaohe Subject: [PATCH net v2] net: vrf: Fix ping failed when vrf mtu is set to 0 Message-ID: Date: Sun, 7 Apr 2019 14:46:26 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 Content-Language: en-US X-Originating-IP: [10.184.189.20] X-CFilter-Loop: Reflected Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org From: Miaohe Lin When the mtu of a vrf device is set to 0, it would cause ping failed. So I think we should limit vrf mtu in a reasonable range to solve this problem. I set dev->min_mtu to 1280, so it will works for both ipv4 and ipv6. And if dev->max_mtu still be 0 can be confusing, so I set dev->max_mtu to 0xFFFFU. Here is the reproduce step: 1.Config vrf interface and set mtu to 0: 3: enp4s0: mtu 1500 qdisc fq_codel master vrf1 state UP mode DEFAULT group default qlen 1000 link/ether 52:54:00:9e:dd:c1 brd ff:ff:ff:ff:ff:ff 2.Ping peer: 3: enp4s0: mtu 1500 qdisc fq_codel master vrf1 state UP group default qlen 1000 link/ether 52:54:00:9e:dd:c1 brd ff:ff:ff:ff:ff:ff inet 10.0.0.1/16 scope global enp4s0 valid_lft forever preferred_lft forever connect: Network is unreachable 3.Set mtu to default value, ping works: PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data. 64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=1.88 ms Fixes: ad49bc6361ca2 ("net: vrf: remove MTU limits for vrf device") Signed-off-by: Miaohe Lin --- V1->V2: - fix patch commit message - adjust to work for ipv6 drivers/net/vrf.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c index 7c1430ed0244..4d35d37f225a 100644 --- a/drivers/net/vrf.c +++ b/drivers/net/vrf.c @@ -43,6 +43,12 @@ #define FIB_RULE_PREF 1000 /* default preference for FIB rules */ +/* The MTU is really irrelevant for VRF except for odd cases, so limit it + * to a reasonable range which both works for IPV4 and IPV6. + */ +#define VRF_MIN_MTU 1280 /* same as IPV6_MIN_MTU */ +#define VRF_MAX_MTU 0xFFFFU /* same as IP_MAX_MTU */ + static unsigned int vrf_net_id; struct net_vrf { @@ -1274,8 +1280,8 @@ static void vrf_setup(struct net_device *dev) /* default to no qdisc; user can add if desired */ dev->priv_flags |= IFF_NO_QUEUE; - dev->min_mtu = 0; - dev->max_mtu = 0; + dev->min_mtu = VRF_MIN_MTU; + dev->max_mtu = VRF_MAX_MTU; } static int vrf_validate(struct nlattr *tb[], struct nlattr *data[],