Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754221Ab3JBWX1 (ORCPT ); Wed, 2 Oct 2013 18:23:27 -0400 Received: from mail-ie0-f174.google.com ([209.85.223.174]:57574 "EHLO mail-ie0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753279Ab3JBWX0 (ORCPT ); Wed, 2 Oct 2013 18:23:26 -0400 MIME-Version: 1.0 In-Reply-To: References: Date: Wed, 2 Oct 2013 23:23:26 +0100 Message-ID: Subject: Fwd: The check of upper MTU limit when changing it in ip6 gre tunnel seems incorrect. From: Oussama Ghorbel To: linux-kernel@vger.kernel.org Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1018 Lines: 32 The check of upper MTU limit when changing it in ip6 gre tunnel seems incorrect. The function in question is: static int ip6gre_tunnel_change_mtu(struct net_device *dev, int new_mtu) { struct ip6_tnl *tunnel = netdev_priv(dev); if (new_mtu < 68 || new_mtu > 0xFFF8 - dev->hard_header_len - tunnel->hlen) return -EINVAL; dev->mtu = new_mtu; return 0; } However the dev->hard_header_len and tunnel->hlen are initialized in the following way in ip6gre_tnl_link_config(): int addend = sizeof(struct ipv6hdr) + 4; ... dev->hard_header_len = rt->dst.dev->hard_header_len + addend; ... t->hlen = addend; // t is ip6_tnl pointer As you see the information t->hlen is already included in dev->hard_header_len, so why calculate it twice? Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/