[{"id":1772898,"web_url":"http://patchwork.ozlabs.org/comment/1772898/","msgid":"<1506006138.29839.132.camel@edumazet-glaptop3.roam.corp.google.com>","list_archive_url":null,"date":"2017-09-21T15:02:18","subject":"Re: [net-next 1/2] dummy: add device MTU validation check","submitter":{"id":2404,"url":"http://patchwork.ozlabs.org/api/people/2404/","name":"Eric Dumazet","email":"eric.dumazet@gmail.com"},"content":"On Thu, 2017-09-21 at 21:32 +0800, Zhang Shengju wrote:\n> Currently, any mtu value can be assigned when adding a new dummy device:\n> [~]# ip link add name dummy1 mtu 100000 type dummy\n> [~]# ip link show dummy1\n> 15: dummy1: mtu 100000 qdisc noop state DOWN mode DEFAULT group default qlen 1000\n> link/ether 0a:61:6b:16:14:ce brd ff:ff:ff:ff:ff:ff\n> \n> This patch adds device MTU validation check.\n\nWhat is wrong with big MTU on dummy ?\n\nIf this is a generic rule, this check should belong in core network\nstack.\n\n> \n> Signed-off-by: Zhang Shengju \n> ---\n> drivers/net/dummy.c | 8 ++++++++\n> 1 file changed, 8 insertions(+)\n> \n> diff --git a/drivers/net/dummy.c b/drivers/net/dummy.c\n> index e31ab3b..0276b2b 100644\n> --- a/drivers/net/dummy.c\n> +++ b/drivers/net/dummy.c\n> @@ -365,6 +365,14 @@ static int dummy_validate(struct nlattr *tb[], struct nlattr *data[],\n> \t\tif (!is_valid_ether_addr(nla_data(tb[IFLA_ADDRESS])))\n> \t\t\treturn -EADDRNOTAVAIL;\n> \t}\n> +\n> +\tif (tb[IFLA_MTU]) {\n> +\t\tu32 mtu = nla_get_u32(tb[IFLA_MTU]);\n\nYou do not verify/validate nla_len(tb[IFLA_MTU]).\n\nDo not ever trust user space.\n\n> +\n> +\t\tif (mtu > ETH_MAX_MTU)\n> +\t\t\treturn -EINVAL;\n> +\t}\n> +\n> \treturn 0;\n> }\n>","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"iX6VmDzk\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xyfwk283Tz9t3v\n\tfor ;\n\tFri, 22 Sep 2017 01:02:30 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751886AbdIUPC3 (ORCPT );\n\tThu, 21 Sep 2017 11:02:29 -0400","from mail-pg0-f68.google.com ([74.125.83.68]:36514 \"EHLO\n\tmail-pg0-f68.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751653AbdIUPC1 (ORCPT\n\t); Thu, 21 Sep 2017 11:02:27 -0400","by mail-pg0-f68.google.com with SMTP id d8so3570588pgt.3\n\tfor ; Thu, 21 Sep 2017 08:02:27 -0700 (PDT)","from [10.1.104.73] ([207.198.105.19])\n\tby smtp.googlemail.com with ESMTPSA id\n\tf88sm4097078pfh.95.2017.09.21.08.02.22\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tThu, 21 Sep 2017 08:02:26 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=message-id:subject:from:to:cc:date:in-reply-to:references\n\t:mime-version:content-transfer-encoding;\n\tbh=JcAvbSDIYXrtPUxNIj2/ZuUkZsVXsI/9SmKalXJTEzM=;\n\tb=iX6VmDzkhm+SZpKkv0KXI/DjM1R9peSljjYTMvMdPd4nJCHotkXXpRiROtzrZJ+LbW\n\tRJ6RABa5cbvptJhvr3IqKBm3BfxM61kJAprV3W6YFFZPNWKgghMthJLPZIkp6uyo71xt\n\t5vZZykAvB4ye4LPRctivjaahAT3oH5HA/m5TMwXgkjv6MrCPhrPXtURWy3+T2P+yPVk8\n\tq8I42kDLx4LVAFqHcVXRIJ+UbHyNoURa1wnBaaLTz1DExiUNrbtE7f5vdN+SPcao93TN\n\tHLpLo7BXclhNckyUqkPin/73vY8/gRikeqKQUZFfaizgpmRS2sC5tOCXkBFRrsOTi6lS\n\tSNig==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to\n\t:references:mime-version:content-transfer-encoding;\n\tbh=JcAvbSDIYXrtPUxNIj2/ZuUkZsVXsI/9SmKalXJTEzM=;\n\tb=nbRHkFDQG21lnPaQJF+u1OGPqpEynH0utUf6KVehpyy6BZSAaY+mbhlxtfY/v1Rqux\n\t7sPvlImilRGA52O6Y9EbS8j1gi+gFsOpNHQ05tfHYXfMt0qsesdjOQUTKect2jhlCLvf\n\tb7SXWBDFA1zBWjwFNVtNaUf8yFwf2dQmUHikRb+3p5Fnt8vFVgd67FxFiyGLGfL+wCsc\n\t3rglbOVbYPjQ6G3pz9LYs09kvETfn58NQtwUItTQugLj34quHA+qOFeS6KCmuBf/TAyp\n\trTftMFU1kVaJU1MIXSrJ5jYeNf2HpA8XW2T5t/GaGx8TT76iMhwITLcaXyMo6TTVsBuM\n\tqMvQ==","X-Gm-Message-State":"AHPjjUhIe79Skc1pBPYjb/Ir+8RDLYLzduRxG4PONdzqn4OXWxdYRP6r\n\tIUdhxXJkNapazh/PK/XJLR4=","X-Google-Smtp-Source":"AOwi7QCPsJEHasA5dfZdhduDSKzgA7SzbONqLL/I9MJ2yE5sqvo/fgKBg13e4jzq55DOmHjliTU4ag==","X-Received":"by 10.98.166.10 with SMTP id t10mr6010068pfe.181.1506006146982; \n\tThu, 21 Sep 2017 08:02:26 -0700 (PDT)","Message-ID":"<1506006138.29839.132.camel@edumazet-glaptop3.roam.corp.google.com>","Subject":"Re: [net-next 1/2] dummy: add device MTU validation check","From":"Eric Dumazet ","To":"Zhang Shengju ","Cc":"davem@davemloft.net, willemb@google.com,\n\tstephen@networkplumber.org, netdev@vger.kernel.org","Date":"Thu, 21 Sep 2017 08:02:18 -0700","In-Reply-To":"<1506000722-40095-2-git-send-email-zhangshengju@cmss.chinamobile.com>","References":"<1506000722-40095-1-git-send-email-zhangshengju@cmss.chinamobile.com>\n\t<1506000722-40095-2-git-send-email-zhangshengju@cmss.chinamobile.com>","Content-Type":"text/plain; charset=\"UTF-8\"","X-Mailer":"Evolution 3.10.4-0ubuntu2 ","Mime-Version":"1.0","Content-Transfer-Encoding":"7bit","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1773239,"web_url":"http://patchwork.ozlabs.org/comment/1773239/","msgid":"<00b401d33352$cb92d990$62b88cb0$@cmss.chinamobile.com>","list_archive_url":null,"date":"2017-09-22T03:28:01","subject":"RE: [net-next 1/2] dummy: add device MTU validation check","submitter":{"id":66922,"url":"http://patchwork.ozlabs.org/api/people/66922/","name":"Zhang Shengju","email":"zhangshengju@cmss.chinamobile.com"},"content":"> -----Original Message-----\n> From: Eric Dumazet [mailto:eric.dumazet@gmail.com]\n> Sent: 2017年9月21日 23:02\n> To: Zhang Shengju \n> Cc: davem@davemloft.net; willemb@google.com;\n> stephen@networkplumber.org; netdev@vger.kernel.org\n> Subject: Re: [net-next 1/2] dummy: add device MTU validation check\n> \n> On Thu, 2017-09-21 at 21:32 +0800, Zhang Shengju wrote:\n> > Currently, any mtu value can be assigned when adding a new dummy device:\n> > [~]# ip link add name dummy1 mtu 100000 type dummy [~]# ip link show\n> > dummy1\n> > 15: dummy1: mtu 100000 qdisc noop state DOWN\n> mode DEFAULT group default qlen 1000\n> > link/ether 0a:61:6b:16:14:ce brd ff:ff:ff:ff:ff:ff\n> >\n> > This patch adds device MTU validation check.\n> \n> What is wrong with big MTU on dummy ?\n> \n> If this is a generic rule, this check should belong in core network stack.\n> \n\ndummy_setup() function setup mtu range: [0, ETH_MAX_MTU]. \nThis will be checked at dev_set_mtu() function in core network stack.\n\nSo if you add a new dummy device without specify mtu value, you can't set a value out of range [0, ETH_MAX_MTU] afterward.\nBUT you can set any mtu when adding new device. This cause an inconsistence.\n\n> >\n> > Signed-off-by: Zhang Shengju \n> > ---\n> > drivers/net/dummy.c | 8 ++++++++\n> > 1 file changed, 8 insertions(+)\n> >\n> > diff --git a/drivers/net/dummy.c b/drivers/net/dummy.c index\n> > e31ab3b..0276b2b 100644\n> > --- a/drivers/net/dummy.c\n> > +++ b/drivers/net/dummy.c\n> > @@ -365,6 +365,14 @@ static int dummy_validate(struct nlattr *tb[], struct\n> nlattr *data[],\n> > \t\tif (!is_valid_ether_addr(nla_data(tb[IFLA_ADDRESS])))\n> > \t\t\treturn -EADDRNOTAVAIL;\n> > \t}\n> > +\n> > +\tif (tb[IFLA_MTU]) {\n> > +\t\tu32 mtu = nla_get_u32(tb[IFLA_MTU]);\n> \n> You do not verify/validate nla_len(tb[IFLA_MTU]).\n> \n> Do not ever trust user space.\nMTU attribute is just u32, do you think it's necessary to check the length? \nActually I don't see any place to check the length of mtu attribute in network stack code. \n\n> \n> > +\n> > +\t\tif (mtu > ETH_MAX_MTU)\n> > +\t\t\treturn -EINVAL;\n> > +\t}\n> > +\n> > \treturn 0;\n> > }\n> >\n>","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xyzTD2zmdz9t33\n\tfor ;\n\tFri, 22 Sep 2017 13:28:16 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751809AbdIVD2M convert rfc822-to-8bit (ORCPT\n\t);\n\tThu, 21 Sep 2017 23:28:12 -0400","from cmccmta1.chinamobile.com ([221.176.66.79]:57439 \"EHLO\n\tcmccmta1.chinamobile.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751794AbdIVD2L (ORCPT\n\t); Thu, 21 Sep 2017 23:28:11 -0400","from spf.mail.chinamobile.com (unknown[172.16.121.9]) by\n\trmmx-syy-dmz-app01-12001 (RichMail) with SMTP id\n\t2ee159c48343627-fd838; Fri, 22 Sep 2017 11:28:03 +0800 (CST)","from OFFICECOMPUTER01 (unknown[112.25.154.148])\n\tby rmsmtp-syy-appsvr05-12005 (RichMail) with SMTP id\n\t2ee559c48342359-3ce24; Fri, 22 Sep 2017 11:28:03 +0800 (CST)"],"X-RM-TRANSID":["2ee159c48343627-fd838","2ee559c48342359-3ce24"],"X-RM-SPAM-FLAG":"00000000","From":"=?utf-8?b?5byg6IOc5Li+?= ","To":"\"'Eric Dumazet'\" ","Cc":", ,\n\t, ","References":"<1506000722-40095-1-git-send-email-zhangshengju@cmss.chinamobile.com>\n\t<1506000722-40095-2-git-send-email-zhangshengju@cmss.chinamobile.com>\n\t<1506006138.29839.132.camel@edumazet-glaptop3.roam.corp.google.com>","In-Reply-To":"<1506006138.29839.132.camel@edumazet-glaptop3.roam.corp.google.com>","Subject":"RE: [net-next 1/2] dummy: add device MTU validation check","Date":"Fri, 22 Sep 2017 11:28:01 +0800","Message-ID":"<00b401d33352$cb92d990$62b88cb0$@cmss.chinamobile.com>","MIME-Version":"1.0","Content-Type":"text/plain;\n charset=\"utf-8\"","Content-Transfer-Encoding":"8BIT","X-Mailer":"Microsoft Outlook 16.0","Thread-Index":"AQIX0pNGNje6p1BIhCIaYup5PSaO4wIlegkLAcQPKC2iF6v2MA==","Content-Language":"zh-cn","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1773378,"web_url":"http://patchwork.ozlabs.org/comment/1773378/","msgid":"<20170922085610.GA4544@bistromath.localdomain>","list_archive_url":null,"date":"2017-09-22T08:56:10","subject":"Re: [net-next 1/2] dummy: add device MTU validation check","submitter":{"id":47767,"url":"http://patchwork.ozlabs.org/api/people/47767/","name":"Sabrina Dubroca","email":"sd@queasysnail.net"},"content":"2017-09-21, 08:02:18 -0700, Eric Dumazet wrote:\n> On Thu, 2017-09-21 at 21:32 +0800, Zhang Shengju wrote:\n> > Currently, any mtu value can be assigned when adding a new dummy device:\n> > [~]# ip link add name dummy1 mtu 100000 type dummy\n> > [~]# ip link show dummy1\n> > 15: dummy1: mtu 100000 qdisc noop state DOWN mode DEFAULT group default qlen 1000\n> > link/ether 0a:61:6b:16:14:ce brd ff:ff:ff:ff:ff:ff\n> > \n> > This patch adds device MTU validation check.\n> \n> What is wrong with big MTU on dummy ?\n\nIt looks like the \"centralize MTU checking\" series broke that, but\nonly for changing the MTU on an existing dummy device. Commit\na52ad514fdf3 defined min_mtu/max_mtu in ether_setup, which dummy uses,\nbut there was no MTU check in dummy prior to that commit.\n\n\n> If this is a generic rule, this check should belong in core network\n> stack.\n> \n> > \n> > Signed-off-by: Zhang Shengju \n> > ---\n> > drivers/net/dummy.c | 8 ++++++++\n> > 1 file changed, 8 insertions(+)\n> > \n> > diff --git a/drivers/net/dummy.c b/drivers/net/dummy.c\n> > index e31ab3b..0276b2b 100644\n> > --- a/drivers/net/dummy.c\n> > +++ b/drivers/net/dummy.c\n> > @@ -365,6 +365,14 @@ static int dummy_validate(struct nlattr *tb[], struct nlattr *data[],\n> > \t\tif (!is_valid_ether_addr(nla_data(tb[IFLA_ADDRESS])))\n> > \t\t\treturn -EADDRNOTAVAIL;\n> > \t}\n> > +\n> > +\tif (tb[IFLA_MTU]) {\n> > +\t\tu32 mtu = nla_get_u32(tb[IFLA_MTU]);\n> \n> You do not verify/validate nla_len(tb[IFLA_MTU]).\n\nI think ifla_policy already performs that check:\n\n\nstatic const struct nla_policy ifla_policy[IFLA_MAX+1] = {\n[...]\n\t[IFLA_MTU]\t\t= { .type = NLA_U32 },\n\n\nstatic int rtnl_newlink(struct sk_buff *skb, struct nlmsghdr *nlh,\n\t\t\tstruct netlink_ext_ack *extack)\n{\n[...]\n\terr = nlmsg_parse(nlh, sizeof(*ifm), tb, IFLA_MAX, ifla_policy, extack);","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ext-mx04.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none)\n\theader.from=queasysnail.net","ext-mx04.extmail.prod.ext.phx2.redhat.com;\n\tspf=none smtp.mailfrom=sd@queasysnail.net"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xz6lm5zYqz9sPk\n\tfor ;\n\tFri, 22 Sep 2017 18:56:20 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751898AbdIVI4S (ORCPT );\n\tFri, 22 Sep 2017 04:56:18 -0400","from mx1.redhat.com ([209.132.183.28]:49844 \"EHLO mx1.redhat.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1751832AbdIVI4R (ORCPT );\n\tFri, 22 Sep 2017 04:56:17 -0400","from smtp.corp.redhat.com\n\t(int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 82AB37EA9A;\n\tFri, 22 Sep 2017 08:56:16 +0000 (UTC)","from bistromath.localdomain (ovpn-117-175.ams2.redhat.com\n\t[10.36.117.175])\n\tby smtp.corp.redhat.com (Postfix) with ESMTPS id 9EA0960491;\n\tFri, 22 Sep 2017 08:56:12 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 82AB37EA9A","DKIM-Filter":"OpenDKIM Filter v2.11.0 mx1.redhat.com 82AB37EA9A","Date":"Fri, 22 Sep 2017 10:56:10 +0200","From":"Sabrina Dubroca ","To":"Eric Dumazet , Jarod Wilson ","Cc":"Zhang Shengju ,\n\tdavem@davemloft.net, willemb@google.com,\n\tstephen@networkplumber.org, netdev@vger.kernel.org","Subject":"Re: [net-next 1/2] dummy: add device MTU validation check","Message-ID":"<20170922085610.GA4544@bistromath.localdomain>","References":"<1506000722-40095-1-git-send-email-zhangshengju@cmss.chinamobile.com>\n\t<1506000722-40095-2-git-send-email-zhangshengju@cmss.chinamobile.com>\n\t<1506006138.29839.132.camel@edumazet-glaptop3.roam.corp.google.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"<1506006138.29839.132.camel@edumazet-glaptop3.roam.corp.google.com>","User-Agent":"Mutt/1.9.0 (2017-09-02)","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.11","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.28]);\n\tFri, 22 Sep 2017 08:56:17 +0000 (UTC)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1773475,"web_url":"http://patchwork.ozlabs.org/comment/1773475/","msgid":"<1506078309.29839.161.camel@edumazet-glaptop3.roam.corp.google.com>","list_archive_url":null,"date":"2017-09-22T11:05:09","subject":"Re: [net-next 1/2] dummy: add device MTU validation check","submitter":{"id":2404,"url":"http://patchwork.ozlabs.org/api/people/2404/","name":"Eric Dumazet","email":"eric.dumazet@gmail.com"},"content":"On Fri, 2017-09-22 at 10:56 +0200, Sabrina Dubroca wrote:\n> 2017-09-21, 08:02:18 -0700, Eric Dumazet wrote:\n> > On Thu, 2017-09-21 at 21:32 +0800, Zhang Shengju wrote:\n> > > Currently, any mtu value can be assigned when adding a new dummy device:\n> > > [~]# ip link add name dummy1 mtu 100000 type dummy\n> > > [~]# ip link show dummy1\n> > > 15: dummy1: mtu 100000 qdisc noop state DOWN mode DEFAULT group default qlen 1000\n> > > link/ether 0a:61:6b:16:14:ce brd ff:ff:ff:ff:ff:ff\n> > > \n> > > This patch adds device MTU validation check.\n> > \n> > What is wrong with big MTU on dummy ?\n> \n> It looks like the \"centralize MTU checking\" series broke that, but\n> only for changing the MTU on an existing dummy device. Commit\n> a52ad514fdf3 defined min_mtu/max_mtu in ether_setup, which dummy uses,\n> but there was no MTU check in dummy prior to that commit.\n> \n\nIt looks like we accept big mtu on loopback, right ?\n\nlpaa23:~# ifconfig lo mtu 100000\nlpaa23:~# ifconfig lo\nlo Link encap:Local Loopback \n inet addr:127.0.0.1 Mask:255.0.0.0\n inet6 addr: ::1/128 Scope:Host\n UP LOOPBACK RUNNING MTU:100000 Metric:1\n RX packets:3823 errors:0 dropped:0 overruns:0 frame:0\n TX packets:3823 errors:0 dropped:0 overruns:0 carrier:0\n collisions:0 txqueuelen:1000 \n RX bytes:759159 (759.1 KB) TX bytes:759159 (759.1 KB)\n\nAlso we accept very small MTU as well (although this automatically\nremoves IP addresses, as one would expect)\n\nlpaa23:~# ifconfig lo mtu 50\nlpaa23:~# ifconfig lo\nlo Link encap:Local Loopback \n UP LOOPBACK RUNNING MTU:50 Metric:1\n RX packets:4052 errors:0 dropped:0 overruns:0 frame:0\n TX packets:4052 errors:0 dropped:0 overruns:0 carrier:0\n collisions:0 txqueuelen:1000 \n RX bytes:806274 (806.2 KB) TX bytes:806274 (806.2 KB)\n\n\n\nSo, why dummy devices would not accept bit MTU ?\n\nDo we have some fundamental assumption in the stack ?\n\nIf yes, we need to fix loopback urgently, it is more important than\ndummy.\n\nThanks.","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ozlabs.org; dkim=pass (2048-bit key;\n\tunprotected) header.d=gmail.com header.i=@gmail.com\n\theader.b=\"rGZFW9cW\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xz9cX2DqTz9ryr\n\tfor ;\n\tFri, 22 Sep 2017 21:05:16 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752055AbdIVLFO (ORCPT );\n\tFri, 22 Sep 2017 07:05:14 -0400","from mail-io0-f196.google.com ([209.85.223.196]:32856 \"EHLO\n\tmail-io0-f196.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751919AbdIVLFN (ORCPT\n\t); Fri, 22 Sep 2017 07:05:13 -0400","by mail-io0-f196.google.com with SMTP id j26so1192920iod.0\n\tfor ; Fri, 22 Sep 2017 04:05:12 -0700 (PDT)","from [192.168.86.171] (c-67-180-167-114.hsd1.ca.comcast.net.\n\t[67.180.167.114]) by smtp.googlemail.com with ESMTPSA id\n\tn63sm2249469itb.16.2017.09.22.04.05.10\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tFri, 22 Sep 2017 04:05:11 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=gmail.com; s=20161025;\n\th=message-id:subject:from:to:cc:date:in-reply-to:references\n\t:mime-version:content-transfer-encoding;\n\tbh=mumPsZ0MI3x5UCituQSHuxv8zpn2I86kupkS4C6BqGY=;\n\tb=rGZFW9cWG2NT5ji3Zn4Z6+EWdSd7Te3BoBxQgq0l5nG95Gvc8eGTCLSZCwTDzv+Txm\n\tRa/54yQQ7YkQ8WmSPhYTxZAzWqKQTXTR984CQeUefouAgideemZkeBi/dsbU4GB9Z9nE\n\txNOmVh+CzA0UPT+Cwu8KDYWaJm+E2uqnwtAd+ys+1HwR7RhmCpooNwEz1Eh5tdbqqFYA\n\tRUXeDvBmGGZ9yCBRkuJfjA+vzIGrEeEkQfmGp3tYH4k/eby/dlDCIrP14/bZMnMwNyox\n\td5xZsxgUkRjLmLEpF/mc7Fj8KGFs7OyLTG4EMjehfy795qRFg3rVTjCzkA975CrGEhQp\n\tNbxA==","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to\n\t:references:mime-version:content-transfer-encoding;\n\tbh=mumPsZ0MI3x5UCituQSHuxv8zpn2I86kupkS4C6BqGY=;\n\tb=EbNqxvLEOwW+P+8qS6s+XO49hJZ1zzYRoyfNKprJpw7KbetRKG5GR0BhiddNW5O0Rg\n\t4uyO3zgPn/S5ww5+1GXN/KTLf0a7azaYPt/QSgaS3ZLC3ZVk9GpqkL3nwPCAtKbw4+Is\n\tlPFxzuT7D0ALCqFwEfyMuWnI0ZL2mRRF//gWpL2tcXPxK/rblWRm+yOX+d8bql4w2g8v\n\t2bQhoX5SkqVAKiyqoN/dfaeIklIaUhAakzzkQRHNNgF/ODip5orbTK0zPFpNOOG+rifj\n\txNZDavJer4BFRqSHoenE8e2FJwb9djtW7IlwyUmKEVKqSamVwu9YCQICrPe0bMOf8vUy\n\tYqnw==","X-Gm-Message-State":"AHPjjUjCsn5HLKcrFnCXM1nnmxasFsEmMV39wMz6eN8X6OYGsDGGqHcr\n\tSZ4ULFbRpXzfkNy9nscuhekWBw==","X-Google-Smtp-Source":"AOwi7QDzyq3tCcxcFcXzVBQp1A0e0lQ3qGSUFZ73zLF4uTs01PPJyrjhxHQD+IJfQuNnW22SoYIHtA==","X-Received":"by 10.107.198.7 with SMTP id w7mr7507855iof.27.1506078312390;\n\tFri, 22 Sep 2017 04:05:12 -0700 (PDT)","Message-ID":"<1506078309.29839.161.camel@edumazet-glaptop3.roam.corp.google.com>","Subject":"Re: [net-next 1/2] dummy: add device MTU validation check","From":"Eric Dumazet ","To":"Sabrina Dubroca ","Cc":"Jarod Wilson ,\n\tZhang Shengju ,\n\tdavem@davemloft.net, willemb@google.com,\n\tstephen@networkplumber.org, netdev@vger.kernel.org","Date":"Fri, 22 Sep 2017 04:05:09 -0700","In-Reply-To":"<20170922085610.GA4544@bistromath.localdomain>","References":"<1506000722-40095-1-git-send-email-zhangshengju@cmss.chinamobile.com>\n\t<1506000722-40095-2-git-send-email-zhangshengju@cmss.chinamobile.com>\n\t<1506006138.29839.132.camel@edumazet-glaptop3.roam.corp.google.com>\n\t<20170922085610.GA4544@bistromath.localdomain>","Content-Type":"text/plain; charset=\"UTF-8\"","X-Mailer":"Evolution 3.10.4-0ubuntu2 ","Mime-Version":"1.0","Content-Transfer-Encoding":"7bit","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1773545,"web_url":"http://patchwork.ozlabs.org/comment/1773545/","msgid":"<20170922122315.GA3446@bistromath.localdomain>","list_archive_url":null,"date":"2017-09-22T12:23:15","subject":"Re: [net-next 1/2] dummy: add device MTU validation check","submitter":{"id":47767,"url":"http://patchwork.ozlabs.org/api/people/47767/","name":"Sabrina Dubroca","email":"sd@queasysnail.net"},"content":"2017-09-22, 04:05:09 -0700, Eric Dumazet wrote:\n> On Fri, 2017-09-22 at 10:56 +0200, Sabrina Dubroca wrote:\n> > 2017-09-21, 08:02:18 -0700, Eric Dumazet wrote:\n> > > On Thu, 2017-09-21 at 21:32 +0800, Zhang Shengju wrote:\n> > > > Currently, any mtu value can be assigned when adding a new dummy device:\n> > > > [~]# ip link add name dummy1 mtu 100000 type dummy\n> > > > [~]# ip link show dummy1\n> > > > 15: dummy1: mtu 100000 qdisc noop state DOWN mode DEFAULT group default qlen 1000\n> > > > link/ether 0a:61:6b:16:14:ce brd ff:ff:ff:ff:ff:ff\n> > > > \n> > > > This patch adds device MTU validation check.\n> > > \n> > > What is wrong with big MTU on dummy ?\n> > \n> > It looks like the \"centralize MTU checking\" series broke that, but\n> > only for changing the MTU on an existing dummy device. Commit\n> > a52ad514fdf3 defined min_mtu/max_mtu in ether_setup, which dummy uses,\n> > but there was no MTU check in dummy prior to that commit.\n> > \n> \n> It looks like we accept big mtu on loopback, right ?\n\nYes. I only meant that before commit a52ad514fdf3, there was no range\ncheck on dummy's MTU. Commit 25e3e84b183a (\"dummy: expend mtu range\nfor dummy device\") and 8b1efc0f83f1 (\"net: remove MTU limits on a few\nether_setup callers\") fixed that only partially. It's the same with\nifb, btw, it didn't have any check before a52ad514fdf3, so we should\nset min_mtu = max_mtu = 0.","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":["ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","ext-mx07.extmail.prod.ext.phx2.redhat.com;\n\tdmarc=none (p=none dis=none)\n\theader.from=queasysnail.net","ext-mx07.extmail.prod.ext.phx2.redhat.com;\n\tspf=none smtp.mailfrom=sd@queasysnail.net"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xzCLk34lwz9sPk\n\tfor ;\n\tFri, 22 Sep 2017 22:23:26 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1752198AbdIVMXX (ORCPT );\n\tFri, 22 Sep 2017 08:23:23 -0400","from mx1.redhat.com ([209.132.183.28]:32640 \"EHLO mx1.redhat.com\"\n\trhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP\n\tid S1752039AbdIVMXW (ORCPT );\n\tFri, 22 Sep 2017 08:23:22 -0400","from smtp.corp.redhat.com\n\t(int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15])\n\t(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))\n\t(No client certificate requested)\n\tby mx1.redhat.com (Postfix) with ESMTPS id 21553C04B31B;\n\tFri, 22 Sep 2017 12:23:22 +0000 (UTC)","from bistromath.localdomain (ovpn-117-175.ams2.redhat.com\n\t[10.36.117.175])\n\tby smtp.corp.redhat.com (Postfix) with ESMTPS id 4A8D5675B7;\n\tFri, 22 Sep 2017 12:23:16 +0000 (UTC)"],"DMARC-Filter":"OpenDMARC Filter v1.3.2 mx1.redhat.com 21553C04B31B","DKIM-Filter":"OpenDKIM Filter v2.11.0 mx1.redhat.com 21553C04B31B","Date":"Fri, 22 Sep 2017 14:23:15 +0200","From":"Sabrina Dubroca ","To":"Eric Dumazet ","Cc":"Jarod Wilson ,\n\tZhang Shengju ,\n\tdavem@davemloft.net, willemb@google.com,\n\tstephen@networkplumber.org, netdev@vger.kernel.org","Subject":"Re: [net-next 1/2] dummy: add device MTU validation check","Message-ID":"<20170922122315.GA3446@bistromath.localdomain>","References":"<1506000722-40095-1-git-send-email-zhangshengju@cmss.chinamobile.com>\n\t<1506000722-40095-2-git-send-email-zhangshengju@cmss.chinamobile.com>\n\t<1506006138.29839.132.camel@edumazet-glaptop3.roam.corp.google.com>\n\t<20170922085610.GA4544@bistromath.localdomain>\n\t<1506078309.29839.161.camel@edumazet-glaptop3.roam.corp.google.com>","MIME-Version":"1.0","Content-Type":"text/plain; charset=utf-8","Content-Disposition":"inline","In-Reply-To":"<1506078309.29839.161.camel@edumazet-glaptop3.roam.corp.google.com>","User-Agent":"Mutt/1.9.0 (2017-09-02)","X-Scanned-By":"MIMEDefang 2.79 on 10.5.11.15","X-Greylist":"Sender IP whitelisted, not delayed by milter-greylist-4.5.16\n\t(mx1.redhat.com [10.5.110.31]);\n\tFri, 22 Sep 2017 12:23:22 +0000 (UTC)","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1773569,"web_url":"http://patchwork.ozlabs.org/comment/1773569/","msgid":"<000801d333a2$a7666320$f6332960$@cmss.chinamobile.com>","list_archive_url":null,"date":"2017-09-22T12:59:39","subject":"RE: [net-next 1/2] dummy: add device MTU validation check","submitter":{"id":66922,"url":"http://patchwork.ozlabs.org/api/people/66922/","name":"Zhang Shengju","email":"zhangshengju@cmss.chinamobile.com"},"content":"> -----Original Message-----\n> From: Sabrina Dubroca [mailto:sd@queasysnail.net]\n> Sent: 2017年9月22日 20:23\n> To: Eric Dumazet \n> Cc: Jarod Wilson ; Zhang Shengju\n> ; davem@davemloft.net;\n> willemb@google.com; stephen@networkplumber.org;\n> netdev@vger.kernel.org\n> Subject: Re: [net-next 1/2] dummy: add device MTU validation check\n> \n> 2017-09-22, 04:05:09 -0700, Eric Dumazet wrote:\n> > On Fri, 2017-09-22 at 10:56 +0200, Sabrina Dubroca wrote:\n> > > 2017-09-21, 08:02:18 -0700, Eric Dumazet wrote:\n> > > > On Thu, 2017-09-21 at 21:32 +0800, Zhang Shengju wrote:\n> > > > > Currently, any mtu value can be assigned when adding a new dummy\n> device:\n> > > > > [~]# ip link add name dummy1 mtu 100000 type dummy [~]# ip link\n> > > > > show dummy1\n> > > > > 15: dummy1: mtu 100000 qdisc noop state\n> DOWN mode DEFAULT group default qlen 1000\n> > > > > link/ether 0a:61:6b:16:14:ce brd ff:ff:ff:ff:ff:ff\n> > > > >\n> > > > > This patch adds device MTU validation check.\n> > > >\n> > > > What is wrong with big MTU on dummy ?\n> > >\n> > > It looks like the \"centralize MTU checking\" series broke that, but\n> > > only for changing the MTU on an existing dummy device. Commit\n> > > a52ad514fdf3 defined min_mtu/max_mtu in ether_setup, which dummy\n> > > uses, but there was no MTU check in dummy prior to that commit.\n> > >\n> >\n> > It looks like we accept big mtu on loopback, right ?\n> \n> Yes. I only meant that before commit a52ad514fdf3, there was no range check\n> on dummy's MTU. Commit 25e3e84b183a (\"dummy: expend mtu range for\n> dummy device\") and 8b1efc0f83f1 (\"net: remove MTU limits on a few\n> ether_setup callers\") fixed that only partially. It's the same with ifb, btw, it\n> didn't have any check before a52ad514fdf3, so we should set min_mtu =\n> max_mtu = 0.\n> \n> --\n> Sabrina\n\nI agree, dummy and ifb device should not have any limit on mtu, just like loopback device.\nI will send v2 patch, and set min/max_mtu to zero for dummy and ifb device, thanks.\n\nZSJ","headers":{"Return-Path":"","X-Original-To":"patchwork-incoming@ozlabs.org","Delivered-To":"patchwork-incoming@ozlabs.org","Authentication-Results":"ozlabs.org;\n\tspf=none (mailfrom) smtp.mailfrom=vger.kernel.org\n\t(client-ip=209.132.180.67; helo=vger.kernel.org;\n\tenvelope-from=netdev-owner@vger.kernel.org;\n\treceiver=)","Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xzD8n2vHzz9s9Y\n\tfor ;\n\tFri, 22 Sep 2017 22:59:53 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751928AbdIVM7u convert rfc822-to-8bit (ORCPT\n\t);\n\tFri, 22 Sep 2017 08:59:50 -0400","from cmccmta2.chinamobile.com ([221.176.66.80]:12410 \"EHLO\n\tcmccmta2.chinamobile.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1751851AbdIVM7t (ORCPT\n\t); Fri, 22 Sep 2017 08:59:49 -0400","from spf.mail.chinamobile.com (unknown[172.16.121.3]) by\n\trmmx-syy-dmz-app08-12008 (RichMail) with SMTP id\n\t2ee859c5093e419-0c8c0; Fri, 22 Sep 2017 20:59:42 +0800 (CST)","from OFFICECOMPUTER01 (unknown[183.209.108.132])\n\tby rmsmtp-syy-appsvr02-12002 (RichMail) with SMTP id\n\t2ee259c5093c67e-64a71; Fri, 22 Sep 2017 20:59:42 +0800 (CST)"],"X-RM-TRANSID":["2ee859c5093e419-0c8c0","2ee259c5093c67e-64a71"],"X-RM-SPAM-FLAG":"00000000","From":"=?utf-8?b?5byg6IOc5Li+?= ","To":"\"'Sabrina Dubroca'\" ,\n\t\"'Eric Dumazet'\" ","Cc":"\"'Jarod Wilson'\" , ,\n\t, ,\n\t","References":"<1506000722-40095-1-git-send-email-zhangshengju@cmss.chinamobile.com>\n\t<1506000722-40095-2-git-send-email-zhangshengju@cmss.chinamobile.com>\n\t<1506006138.29839.132.camel@edumazet-glaptop3.roam.corp.google.com>\n\t<20170922085610.GA4544@bistromath.localdomain>\n\t<1506078309.29839.161.camel@edumazet-glaptop3.roam.corp.google.com>\n\t<20170922122315.GA3446@bistromath.localdomain>","In-Reply-To":"<20170922122315.GA3446@bistromath.localdomain>","Subject":"RE: [net-next 1/2] dummy: add device MTU validation check","Date":"Fri, 22 Sep 2017 20:59:39 +0800","Message-ID":"<000801d333a2$a7666320$f6332960$@cmss.chinamobile.com>","MIME-Version":"1.0","Content-Type":"text/plain;\n charset=\"UTF-8\"","Content-Transfer-Encoding":"8BIT","X-Mailer":"Microsoft Outlook 16.0","Thread-Index":"AQIX0pNGNje6p1BIhCIaYup5PSaO4wIlegkLAcQPKC0CFe7VdQIhLB41AdnxUqmh58e5AA==","Content-Language":"zh-cn","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}}]