[{"id":1760665,"web_url":"http://patchwork.ozlabs.org/comment/1760665/","msgid":"<1504159341.15310.6.camel@edumazet-glaptop3.roam.corp.google.com>","list_archive_url":null,"date":"2017-08-31T06:02:21","subject":"Re: [PATCH] bnx2x: drop packets where gso_size is too big for\n\thardware","submitter":{"id":2404,"url":"http://patchwork.ozlabs.org/api/people/2404/","name":"Eric Dumazet","email":"eric.dumazet@gmail.com"},"content":"On Thu, 2017-08-31 at 15:46 +1000, Daniel Axtens wrote:\n> If a bnx2x card is passed a GSO packet with a gso_size larger than\n> ~9700 bytes, it will cause a firmware error that will bring the card\n> down:\n> \n> bnx2x: [bnx2x_attn_int_deasserted3:4323(enP24p1s0f0)]MC assert!\n> bnx2x: [bnx2x_mc_assert:720(enP24p1s0f0)]XSTORM_ASSERT_LIST_INDEX 0x2\n> bnx2x: [bnx2x_mc_assert:736(enP24p1s0f0)]XSTORM_ASSERT_INDEX 0x0 = 0x00000000 0x25e43e47 0x00463e01 0x00010052\n> bnx2x: [bnx2x_mc_assert:750(enP24p1s0f0)]Chip Revision: everest3, FW Version: 7_13_1\n> ... (dump of values continues) ...\n> \n> Detect when gso_size + header length is greater than the maximum\n> packet size (9700 bytes) and drop the packet.\n> \n> This raises the obvious question - how do we end up with a packet with\n> a gso_size that's greater than 9700? This has been observed on an\n> powerpc system when Open vSwitch is forwarding a packet from an\n> ibmveth device.\n> \n> ibmveth is a bit special. It's the driver for communication between\n> virtual machines (aka 'partitions'/LPARs) running under IBM's\n> proprietary hypervisor on ppc machines. It allows sending very large\n> packets (up to 64kB) between LPARs. This involves some quite\n> 'interesting' things: for example, when talking TCP, the MSS is stored\n> the checksum field (see ibmveth_rx_mss_helper() in ibmveth.c).\n> \n> Normally on a box like this, there would be a Virtual I/O Server\n> (VIOS) partition that owns the physical network card. VIOS lets the\n> AIX partitions know when they're talking to a real network and that\n> they should drop their MSS. This works fine if VIOS owns the physical\n> network card.\n> \n> However, in this case, a Linux partition owns the card (this is known\n> as a NovaLink setup). The negotiation between VIOS and AIX uses a\n> non-standard TCP option, so Linux has never supported that. Instead,\n> Linux just supports receiving large packets. It doesn't support any\n> form of messaging/MSS negotiation back to other LPARs.\n> \n> To get some clarity about where the large MSS was coming from, I asked\n> Thomas Falcon, the maintainer of ibmveth, for some background:\n> \n> \"In most cases, large segments are an aggregation of smaller packets\n> by the Virtual I/O Server (VIOS) partition and then are forwarded to\n> the Linux LPAR / ibmveth driver. These segments can be as large as\n> 64KB. In this case, since the customer is using Novalink, I believe\n> what is happening is pretty straightforward: the large segments are\n> created by the AIX partition and then forwarded to the Linux\n> partition, ... The ibmveth driver doesn't do any aggregation itself\n> but just ensures the proper bits are set before sending the frame up\n> to avoid giving the upper layers indigestion.\"\n> \n> It is possible to stop AIX from sending these large segments, but it\n> requires configuration on each LPAR. While ibmveth's behaviour is\n> admittedly weird, we should fix this here: it shouldn't be possible\n> for it to cause a firmware panic on another card.\n> \n\n\n\nThis is so weird :/\n\n> Cc: Thomas Falcon # ibmveth\n> Cc: Yuval Mintz # bnx2x\n> Thanks-to: Jay Vosburgh # veth info\n> Signed-off-by: Daniel Axtens \n> ---\n> drivers/net/ethernet/broadcom/bnx2x/bnx2x.h | 2 ++\n> drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c | 33 +++++++++++++++---------\n> drivers/net/ethernet/broadcom/bnx2x/bnx2x_link.c | 1 -\n> 3 files changed, 23 insertions(+), 13 deletions(-)\n> \n> diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h\n> index 352beff796ae..b36d54737d70 100644\n> --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h\n> +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x.h\n> @@ -2517,4 +2517,6 @@ void bnx2x_set_rx_ts(struct bnx2x *bp, struct sk_buff *skb);\n> */\n> int bnx2x_vlan_reconfigure_vid(struct bnx2x *bp);\n> \n> +#define MAX_PACKET_SIZE\t(9700)\n> +\n> #endif /* bnx2x.h */\n> diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c\n> index 1216c1f1e052..1c5517a9348c 100644\n> --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c\n> +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c\n> @@ -3742,6 +3742,7 @@ netdev_tx_t bnx2x_start_xmit(struct sk_buff *skb, struct net_device *dev)\n> \t__le16 pkt_size = 0;\n> \tstruct ethhdr *eth;\n> \tu8 mac_type = UNICAST_ADDRESS;\n> +\tunsigned int pkts_compl = 0, bytes_compl = 0;\n> \n> #ifdef BNX2X_STOP_ON_ERROR\n> \tif (unlikely(bp->panic))\n> @@ -4029,6 +4030,14 @@ netdev_tx_t bnx2x_start_xmit(struct sk_buff *skb, struct net_device *dev)\n> \t\t skb->len, hlen, skb_headlen(skb),\n> \t\t skb_shinfo(skb)->gso_size);\n> \n> +\t\tif (unlikely(skb_shinfo(skb)->gso_size + hlen > MAX_PACKET_SIZE)) {\n> +\t\t\tBNX2X_ERR(\"reported gso segment size plus headers \"\n> +\t\t\t\t \"(%d + %d) > MAX_PACKET_SIZE; dropping pkt!\",\n> +\t\t\t\t skb_shinfo(skb)->gso_size, hlen);\n> +\n> +\t\t\tgoto free_and_drop;\n> +\t\t}\n> +\n\n\nIf you had this test in bnx2x_features_check(), packet could be\nsegmented by core networking stack before reaching bnx2x_start_xmit() by\nclearing NETIF_F_GSO_MASK\n\n-> No drop would be involved.\n\ncheck i40evf_features_check() for similar logic.","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=\"JKLD4Sk9\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xjWxK0dtgz9s83\n\tfor ;\n\tThu, 31 Aug 2017 16:02:29 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751375AbdHaGC0 (ORCPT );\n\tThu, 31 Aug 2017 02:02:26 -0400","from mail-io0-f193.google.com ([209.85.223.193]:32876 \"EHLO\n\tmail-io0-f193.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750828AbdHaGCZ (ORCPT\n\t); Thu, 31 Aug 2017 02:02:25 -0400","by mail-io0-f193.google.com with SMTP id f99so296757ioi.0\n\tfor ; Wed, 30 Aug 2017 23:02:25 -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\te17sm5421iod.10.2017.08.30.23.02.22\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tWed, 30 Aug 2017 23:02:23 -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=VAkcMG0NQS4NatNwUBWcviMy6ldYJnWAb0jHKknvmG4=;\n\tb=JKLD4Sk9RHwzYVmFFZ/yYq22SEJU7vmwuCMJOS7AzuTTQ9qOC1YWvaRwCGudGdxdUV\n\txMmK5H0Axf8whZa2hABgwAyIQhjodWA4Ah5KqGxFHF5tavrT7EJRpcL6eGkVe7yMRtWx\n\tjjN8Lcn0U+y9PrtlbSi7mrTUcHYppquEylbdzp2fbIeE7hBJTSwCW5GPJ+sV/YJIgtTl\n\t1pCmC7cwwb3dvXUWbYI+KTbcvUccTKyNrcm9VJ2qCrhHDgOn/y2ZD9BsyIuLBY4Zq4qG\n\t0+Oh+31Qp02olnqDsDo6KEvJ4+PgkZgWu4sHCw8Qz0Bjtz02c2aHeQM9LPxAmpzBY3qL\n\t/YvQ==","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=VAkcMG0NQS4NatNwUBWcviMy6ldYJnWAb0jHKknvmG4=;\n\tb=SAG6+ZV+XLwvO1EqB/C6B4hiy9b8GHset0IW4QFdxIXby9HOS1r8haRgf4OX7YBuLH\n\tZ199Uwat8Krq8V+/O+u5rDmX6cwmvWWcRhYpu5geUNGPwfiu2QnG8RrywoNl4DOoA6Sx\n\tTUDAThfqZrQ5OCpqEp5YMkFazv0fzB9oqhU2hVqWHR8EufDPr4evrU+xuUHAODHktUi4\n\tYQlnJcGdiCA/hCTK+DYgCfpLC6LxBm6ZMVeHfMoSPubEd2MA9+vuhmvAKa8JwhS+xAY4\n\tP7glMj6IXXLtrj4AMINIxE2gPGM/CDyNFZdpOagKkW8viFXOlf6RKbfNHRzskANLt75W\n\ttsmA==","X-Gm-Message-State":"AHPjjUi8+ThS5tPmrYpZP8Xo/NwSQ1FHlpnOtWmFc8XMHPMVpuSm3eJ7\n\trpv9nWE/reT7fg==","X-Received":"by 10.107.13.143 with SMTP id 137mr3631315ion.94.1504159344488; \n\tWed, 30 Aug 2017 23:02:24 -0700 (PDT)","Message-ID":"<1504159341.15310.6.camel@edumazet-glaptop3.roam.corp.google.com>","Subject":"Re: [PATCH] bnx2x: drop packets where gso_size is too big for\n\thardware","From":"Eric Dumazet ","To":"Daniel Axtens ","Cc":"netdev@vger.kernel.org, tlfalcon@linux.vnet.ibm.com,\n\tYuval.Mintz@cavium.com, ariel.elior@cavium.com,\n\teverest-linux-l2@cavium.com, jay.vosburgh@canonical.com","Date":"Wed, 30 Aug 2017 23:02:21 -0700","In-Reply-To":"<20170831054642.13721-1-dja@axtens.net>","References":"<20170831054642.13721-1-dja@axtens.net>","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":1761442,"web_url":"http://patchwork.ozlabs.org/comment/1761442/","msgid":"<87a82f3zry.fsf@linkitivity.dja.id.au>","list_archive_url":null,"date":"2017-09-01T02:42:41","subject":"Re: [PATCH] bnx2x: drop packets where gso_size is too big for\n\thardware","submitter":{"id":65792,"url":"http://patchwork.ozlabs.org/api/people/65792/","name":"Daniel Axtens","email":"dja@axtens.net"},"content":"Eric Dumazet writes:\n\n> If you had this test in bnx2x_features_check(), packet could be\n> segmented by core networking stack before reaching bnx2x_start_xmit() by\n> clearing NETIF_F_GSO_MASK\n>\n> -> No drop would be involved.\n\nThanks for the pointer - networking code is all a bit new to me.\n\nI'm just struggling at the moment to figure out what the right way to\ncalculate the length. My original patch uses gso_size + hlen, but:\n\n - On reflection, while this solves the immediate bug, I'm not 100% sure\n this is the right thing to be calculating\n\n - If it is, then we have the problem that hlen is calculated in a bunch\n of weird and wonderful ways which make it a nightmare to extract.\n\nYuval (or anyone else who groks the driver properly) - what's the right\ntest to be doing here to make sure we don't write to much data to the\ncard?\n\nRegards,\nDaniel","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 (1024-bit key;\n\tunprotected) header.d=axtens.net header.i=@axtens.net\n\theader.b=\"RdcuOGW9\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xk3Sj1JjSz9s83\n\tfor ;\n\tFri, 1 Sep 2017 12:43:01 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1751227AbdIACms (ORCPT );\n\tThu, 31 Aug 2017 22:42:48 -0400","from mail-pf0-f181.google.com ([209.85.192.181]:36412 \"EHLO\n\tmail-pf0-f181.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750996AbdIACmq (ORCPT\n\t); Thu, 31 Aug 2017 22:42:46 -0400","by mail-pf0-f181.google.com with SMTP id r187so4118625pfr.3\n\tfor ; Thu, 31 Aug 2017 19:42:46 -0700 (PDT)","from localhost (124-171-202-56.dyn.iinet.net.au. [124.171.202.56])\n\tby smtp.gmail.com with ESMTPSA id\n\tc9sm1121375pfe.155.2017.08.31.19.42.44\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tThu, 31 Aug 2017 19:42:45 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=axtens.net; s=google;\n\th=from:to:cc:subject:in-reply-to:references:date:message-id\n\t:mime-version;\n\tbh=zXtiUAKBAEGelA8pmkh7zRKzzN8IF2aCdfvhuJDej8g=;\n\tb=RdcuOGW9tNgcUX4KPxo6tnxKudlsgyCXSaTnJ0IFgWJkEACEriKHjSbvL1c1RF8Jis\n\tOL9P9jTKdVRa83Z3vT1nYO8hOHaccdC0EdCqx6uj7RijSFEOAM5qh+5LgkVjwhuKXPcd\n\tVZQWtrWq/D69m9xQDtM5lzzCArNq+D53G/n6Q=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date\n\t:message-id:mime-version;\n\tbh=zXtiUAKBAEGelA8pmkh7zRKzzN8IF2aCdfvhuJDej8g=;\n\tb=sVTbgc6AP9Aews4jeNZ2rqLN6BwfP+jy/uXzL2+CVRifz7I52kyyNp5f/yFy0G2tAH\n\t+iyEnPXDcHqUIdpl5TsIPqtsjRwalA6uMJNWKoIqQSURXvzryxqdiLS0AdnHCRAQy+rC\n\tO7XuptlaFFjjmpcxpdr5EovCH6jKBA9gUDvuy80KpNXLjZGBhG2DbEeGtW0p7NkWA+PK\n\tV27HoiibtbqHolOfIbCKtblKiqxVCUHvxcQCVV9yU3tf/SIbpOmLdIuTaHU0FkdotE4J\n\tUQdVGj/QipalgUJQ8aQ+X24pV8wxEPNEO0QgL7c2oYIfk+9lvYx9qDrMXqEna4b1V0i4\n\tCSIw==","X-Gm-Message-State":"AHPjjUgNLY6IHhGtYRHsnOX4fbF7Wo56MYSLttjz2L1aT0SlCu6FIt04\n\tMv0e5ntiRMyv5oWw","X-Google-Smtp-Source":"ADKCNb7Usi/pU4RqhPiMNuYORwZ6+yPJ91huUy0nk2l7hant9S52OLVEjS8fTLfXSbehw1LMdkL6pw==","X-Received":"by 10.84.238.16 with SMTP id u16mr596241plk.177.1504233766434;\n\tThu, 31 Aug 2017 19:42:46 -0700 (PDT)","From":"Daniel Axtens ","To":"Eric Dumazet ","Cc":"netdev@vger.kernel.org, tlfalcon@linux.vnet.ibm.com,\n\tYuval.Mintz@cavium.com, ariel.elior@cavium.com,\n\teverest-linux-l2@cavium.com, jay.vosburgh@canonical.com","Subject":"Re: [PATCH] bnx2x: drop packets where gso_size is too big for\n\thardware","In-Reply-To":"<1504159341.15310.6.camel@edumazet-glaptop3.roam.corp.google.com>","References":"<20170831054642.13721-1-dja@axtens.net>\n\t<1504159341.15310.6.camel@edumazet-glaptop3.roam.corp.google.com>","Date":"Fri, 01 Sep 2017 12:42:41 +1000","Message-ID":"<87a82f3zry.fsf@linkitivity.dja.id.au>","MIME-Version":"1.0","Content-Type":"text/plain","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1769863,"web_url":"http://patchwork.ozlabs.org/comment/1769863/","msgid":"<87fubkehyo.fsf@linkitivity.dja.id.au>","list_archive_url":null,"date":"2017-09-18T04:41:51","subject":"Re: [PATCH] bnx2x: drop packets where gso_size is too big for\n\thardware","submitter":{"id":65792,"url":"http://patchwork.ozlabs.org/api/people/65792/","name":"Daniel Axtens","email":"dja@axtens.net"},"content":"Hi Eric,\n\n>> +\t\tif (unlikely(skb_shinfo(skb)->gso_size + hlen > MAX_PACKET_SIZE)) {\n>> +\t\t\tBNX2X_ERR(\"reported gso segment size plus headers \"\n>> +\t\t\t\t \"(%d + %d) > MAX_PACKET_SIZE; dropping pkt!\",\n>> +\t\t\t\t skb_shinfo(skb)->gso_size, hlen);\n>> +\n>> +\t\t\tgoto free_and_drop;\n>> +\t\t}\n>> +\n>\n>\n> If you had this test in bnx2x_features_check(), packet could be\n> segmented by core networking stack before reaching bnx2x_start_xmit() by\n> clearing NETIF_F_GSO_MASK\n>\n> -> No drop would be involved.\n>\n> check i40evf_features_check() for similar logic.\n\nSo I've been experimenting with this and reading through the core\nnetworking code. If my understanding is correct, disabling GSO will\ncause the packet to be segmented, but it will be segemented into\ngso_size+header length packets. So in this case (~10kB gso_size) the\nresultant packets will still be too big - although at least they don't\ncause a crash in that case.\n\nWe could continue with this anyway as it at least prevents the crash -\nbut, and I haven't been able to find a nice definitive answer to this -\nare implementations of ndo_start_xmit permitted to assume that the the\nskb passed in will fit within the MTU? I notice that most callers will\nattempt to ensure this - for example ip_output.c, ip6_output.c and\nip_forward.c all contain calls to skb_gso_validate_mtu(). If\nimplementations are permitted to assume this, perhaps a fix to\nopenvswitch would be more appropriate?\n\nRegards,\nDaniel","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 (1024-bit key;\n\tunprotected) header.d=axtens.net header.i=@axtens.net\n\theader.b=\"QNr5JDaH\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xwYKr62jwz9s7G\n\tfor ;\n\tMon, 18 Sep 2017 14:43:28 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1750886AbdIREl6 (ORCPT );\n\tMon, 18 Sep 2017 00:41:58 -0400","from mail-pg0-f45.google.com ([74.125.83.45]:48043 \"EHLO\n\tmail-pg0-f45.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1750711AbdIREl5 (ORCPT\n\t); Mon, 18 Sep 2017 00:41:57 -0400","by mail-pg0-f45.google.com with SMTP id d8so4385373pgt.4\n\tfor ; Sun, 17 Sep 2017 21:41:57 -0700 (PDT)","from localhost (114-198-116-25.dyn.iinet.net.au. [114.198.116.25])\n\tby smtp.gmail.com with ESMTPSA id\n\ty128sm11164481pfy.125.2017.09.17.21.41.54\n\t(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);\n\tSun, 17 Sep 2017 21:41:56 -0700 (PDT)"],"DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed; d=axtens.net; s=google;\n\th=from:to:cc:subject:in-reply-to:references:date:message-id\n\t:mime-version;\n\tbh=YJ/YgxOOdHX9bkxR1ad3x7XlNMOJaS96Y8onWlj3QcU=;\n\tb=QNr5JDaHUIkp6+23hS0r5vACvUty7Y6ul7EwgUFVbKSXWQ9D5WlJiTg0IZBinMfdnY\n\tzYS+cDE2r+Zim/uZ+EyKkecyaiy9sp5LL3OZUTQIzY0Fvcf0GGfl65bqky1gVytSYJDE\n\tpRkrXFbXfI1o/5n3pNjLaiTn6myMzvzDvFOU8=","X-Google-DKIM-Signature":"v=1; a=rsa-sha256; c=relaxed/relaxed;\n\td=1e100.net; s=20161025;\n\th=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date\n\t:message-id:mime-version;\n\tbh=YJ/YgxOOdHX9bkxR1ad3x7XlNMOJaS96Y8onWlj3QcU=;\n\tb=ryhWjsLsvMlEthwoBcizEzg9bSbAdN+/ZFwuk+URMWYzmdNKjX4mACDqkraTTMupoq\n\tB/UdfjArYAq8wjNJNMbXXW7iJkzMIb2KD7eALtVBu/Fb+7LSHwtQ9Rr2vdNUtitlMIj4\n\tecrYnRlafpRa7tgHtCieT+YNnKC12UgKOhYuwG5RdgEUGUmefWEuEZDue4/pi3MqiXe8\n\toQotlIaveWWmih+dInUzc/eRbU2nwFT6/vIrzuefkm9Ulwih4bxRR2ru26GjbAyZtBww\n\tcPLwAcu5VHLtazrefO5iWaK64wNGT8c16Q2jcnM9/ojaqdS78w6pfDdckCKWuavvGRhM\n\tuMVw==","X-Gm-Message-State":"AHPjjUhIICd641ye3re0AwGP3s9tZ1mxOB2Jt6reN/HMHLuQeZxYUvTV\n\txG8lVlwRITTLPs8v","X-Google-Smtp-Source":"AOwi7QB36ij62XacbcYpV3Kn0slBmlV7G6RcHxuxP2dP3vFyMckrclmDU4AiY05J80f6xndOr4VLAA==","X-Received":"by 10.84.179.129 with SMTP id b1mr4923765plc.166.1505709716742; \n\tSun, 17 Sep 2017 21:41:56 -0700 (PDT)","From":"Daniel Axtens ","To":"Eric Dumazet ","Cc":"netdev@vger.kernel.org, tlfalcon@linux.vnet.ibm.com,\n\tYuval.Mintz@cavium.com, ariel.elior@cavium.com,\n\teverest-linux-l2@cavium.com, jay.vosburgh@canonical.com","Subject":"Re: [PATCH] bnx2x: drop packets where gso_size is too big for\n\thardware","In-Reply-To":"<1504159341.15310.6.camel@edumazet-glaptop3.roam.corp.google.com>","References":"<20170831054642.13721-1-dja@axtens.net>\n\t<1504159341.15310.6.camel@edumazet-glaptop3.roam.corp.google.com>","Date":"Mon, 18 Sep 2017 14:41:51 +1000","Message-ID":"<87fubkehyo.fsf@linkitivity.dja.id.au>","MIME-Version":"1.0","Content-Type":"text/plain","Sender":"netdev-owner@vger.kernel.org","Precedence":"bulk","List-ID":"","X-Mailing-List":"netdev@vger.kernel.org"}},{"id":1770211,"web_url":"http://patchwork.ozlabs.org/comment/1770211/","msgid":"<1505745775.29839.16.camel@edumazet-glaptop3.roam.corp.google.com>","list_archive_url":null,"date":"2017-09-18T14:42:55","subject":"Re: [PATCH] bnx2x: drop packets where gso_size is too big for\n\thardware","submitter":{"id":2404,"url":"http://patchwork.ozlabs.org/api/people/2404/","name":"Eric Dumazet","email":"eric.dumazet@gmail.com"},"content":"On Mon, 2017-09-18 at 14:41 +1000, Daniel Axtens wrote:\n> Hi Eric,\n...\n> So I've been experimenting with this and reading through the core\n> networking code. If my understanding is correct, disabling GSO will\n> cause the packet to be segmented, but it will be segemented into\n> gso_size+header length packets. So in this case (~10kB gso_size) the\n> resultant packets will still be too big - although at least they don't\n> cause a crash in that case.\n\nYou describe a bug in core networking stack then.\n\nWhen we perform software segmentation, we must do the check against\nroute mtu, and drop the offending frame, and send an ICMP back\neventually.","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=\"pJw5ccRR\"; dkim-atps=neutral"],"Received":["from vger.kernel.org (vger.kernel.org [209.132.180.67])\n\tby ozlabs.org (Postfix) with ESMTP id 3xwpdh0Nvdz9s7F\n\tfor ;\n\tTue, 19 Sep 2017 00:43:04 +1000 (AEST)","(majordomo@vger.kernel.org) by vger.kernel.org via listexpand\n\tid S1754926AbdIROnB (ORCPT );\n\tMon, 18 Sep 2017 10:43:01 -0400","from mail-pf0-f170.google.com ([209.85.192.170]:46325 \"EHLO\n\tmail-pf0-f170.google.com\" rhost-flags-OK-OK-OK-OK) by vger.kernel.org\n\twith ESMTP id S1754600AbdIROnA (ORCPT\n\t); Mon, 18 Sep 2017 10:43:00 -0400","by mail-pf0-f170.google.com with SMTP id e199so341787pfh.3\n\tfor ; Mon, 18 Sep 2017 07:43:00 -0700 (PDT)","from [10.1.104.73] ([207.198.105.19])\n\tby smtp.googlemail.com with ESMTPSA id\n\tl3sm10549996pgn.36.2017.09.18.07.42.58\n\t(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);\n\tMon, 18 Sep 2017 07:42:58 -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=dAnoWeO8NNoYWyHVQoElT0OI6OThjGTfLLGIiomSnQU=;\n\tb=pJw5ccRRr78XOZ4QwYwfDftg8qckK4zB+qZXxzyOzHG1tym/dA/pqGzabDdoyGfgy8\n\tJ76TfDUwXcUhanSVf9oK93j82iR9JJEdI27S36f17rNaM5QKig+/H8ED5pUUg31bM5EL\n\tpx0vI0szvvG3IH1WhgbO+Be7YEEzFa75QElCR/h1IqWV5aqxEhgYhGFCwugDueHUa88z\n\tIugOkGzhC96GYKFPpivtoF5+olzNP6PEveCUkonIxma59/Vj0DZml0fLNauG3gvS+cwe\n\tV0CsUCKL3YTiOHnRmztZIxiwnjRDAzt7Vlt+YOuInzQo9A6rzskHmKewVX7jueYdSv1H\n\tqXcA==","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=dAnoWeO8NNoYWyHVQoElT0OI6OThjGTfLLGIiomSnQU=;\n\tb=E9ezVFchlBd/Kesj0sewKSWBeBghrahU9puU9kWyWbfeMzUD5slWHZ8enitFwtPkKd\n\tNtmDHPJHUj4dw5Ee0GNfoGmUm4AWHjmxaPWqxkUxUYQa/Guh4VXYVgroap5y51SQ3XSF\n\tIN7MLTiEufqZ1HQ+Aygnr+qrC82hWjihewPY1IEcp+z/3ZTOQFWKeK/vZ1z2HnCqn4XM\n\tIR8s6Iiw1xN3moWUH9gP8vf0YPR/VmQTZbI807+sOiUyD1E0YrqPjp8Gf6nUKFnLVUBj\n\tqOKEEnwBfqZuOFoFHtv1Witgyz9p/R5bLTVK5N/6fMcGhF/Eg2gNc196WkW0nPDLmHE1\n\t5W9Q==","X-Gm-Message-State":"AHPjjUi0X3KE5Oaq/rJdZDoK7eVVd2T3yzvBRbCOWXZJWfb9t7O5bm91\n\t+ea9Dvhhm1nQ4Q==","X-Google-Smtp-Source":"ADKCNb4d+c2A1LqQ78y5fNYP9tYx6H3ULc3g5Xd/JdnLq7DtDF1l42DQU6tU3BALgAfL+F30jeiFtQ==","X-Received":"by 10.84.133.98 with SMTP id 89mr25368273plf.294.1505745779789; \n\tMon, 18 Sep 2017 07:42:59 -0700 (PDT)","Message-ID":"<1505745775.29839.16.camel@edumazet-glaptop3.roam.corp.google.com>","Subject":"Re: [PATCH] bnx2x: drop packets where gso_size is too big for\n\thardware","From":"Eric Dumazet ","To":"Daniel Axtens ","Cc":"netdev@vger.kernel.org, tlfalcon@linux.vnet.ibm.com,\n\tYuval.Mintz@cavium.com, ariel.elior@cavium.com,\n\teverest-linux-l2@cavium.com, jay.vosburgh@canonical.com","Date":"Mon, 18 Sep 2017 07:42:55 -0700","In-Reply-To":"<87fubkehyo.fsf@linkitivity.dja.id.au>","References":"<20170831054642.13721-1-dja@axtens.net>\n\t<1504159341.15310.6.camel@edumazet-glaptop3.roam.corp.google.com>\n\t<87fubkehyo.fsf@linkitivity.dja.id.au>","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"}}]