From patchwork Thu Jan 11 23:59:05 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Axtens X-Patchwork-Id: 859410 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@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; dkim=pass (1024-bit key; unprotected) header.d=axtens.net header.i=@axtens.net header.b="lf4qIoSK"; dkim-atps=neutral Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3zHjZ9355Yz9sNr for ; Fri, 12 Jan 2018 11:00:49 +1100 (AEDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932169AbeALAAr (ORCPT ); Thu, 11 Jan 2018 19:00:47 -0500 Received: from mail-pf0-f196.google.com ([209.85.192.196]:44613 "EHLO mail-pf0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932068AbeALAAp (ORCPT ); Thu, 11 Jan 2018 19:00:45 -0500 Received: by mail-pf0-f196.google.com with SMTP id m26so3000180pfj.11 for ; Thu, 11 Jan 2018 16:00:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=axtens.net; s=google; h=from:to:cc:subject:date:message-id; bh=PLOkEW/xBV4RXh7UpiqbvwtD689ouOhrMEvg5wwIkxM=; b=lf4qIoSKQCr+W1aTrUjY3NyYcKjbHYJxKQitb6pv6JTCLn2GPTbLjUwtJl+jq0+rek P1P+Wh8po4Qe50sEU2sEHd2LXfnyHFT62AMRsCW4oBO1pWj58irICGrtK6Pqi1YCXEmU 9dSE0KTTTh9LLV9nz0jq2x8XP3RiwKE7wgMtc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id; bh=PLOkEW/xBV4RXh7UpiqbvwtD689ouOhrMEvg5wwIkxM=; b=RyRdo+7QmgScWraDqoBqzC9Tv/acuNXtVBqPt7ec55UGYtGJc7VdC+hBJW6r2XNM+e mZ4DarqXcYl4wF2YAv3JLd8qn4pqZFDTJgfVxXtTCQGDXHP0zdG1JG/mcNMiPIJulGn8 b4DocMKy/v3vMGZg2Cd4UBej9EBWDI4UNk6KlS/wqMb5z98GySkKKesKEWd0ssgfIcxA pemYJMUaNmCp9c8ycWTOOYnaUcuJdM0XImnvDGtjjWwkUeqcYZ4Zfth6Jwlx3Cb7OuLW Ufiuhapwv8KFbsQhoS+Cg8ILKgvb9jkz9J0tE4dAVmmxf3BVDqpRzoY85CuWz+6rLTFl j1YA== X-Gm-Message-State: AKGB3mJDIpRXkEX30wVgc3ou4RYPQkRKFy+1ALgcZo0XvW/I0iyhjcF8 mdt3BY33hxKRjCJA6meviuAmRxO3hwE= X-Google-Smtp-Source: ACJfBos++LPOTDHdaKHGX8cGfm6J84zTlgUib4p2KX4M4axDqFf8L79upyKXdh0i4dhln+y82lA03Q== X-Received: by 10.99.96.142 with SMTP id u136mr15010857pgb.406.1515715245101; Thu, 11 Jan 2018 16:00:45 -0800 (PST) Received: from localhost.localdomain (124-171-96-65.dyn.iinet.net.au. [124.171.96.65]) by smtp.gmail.com with ESMTPSA id v25sm25383156pfg.132.2018.01.11.16.00.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jan 2018 16:00:44 -0800 (PST) From: Daniel Axtens To: netdev@vger.kernel.org Cc: Daniel Axtens , Thomas Falcon , Yuval Mintz Subject: [PATCH v2] bnx2x: disable GSO where gso_size is too big for hardware Date: Fri, 12 Jan 2018 10:59:05 +1100 Message-Id: <20180111235905.10110-1-dja@axtens.net> X-Mailer: git-send-email 2.14.1 Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org If a bnx2x card is passed a GSO packet with a gso_size larger than ~9700 bytes, it will cause a firmware error that will bring the card down: bnx2x: [bnx2x_attn_int_deasserted3:4323(enP24p1s0f0)]MC assert! bnx2x: [bnx2x_mc_assert:720(enP24p1s0f0)]XSTORM_ASSERT_LIST_INDEX 0x2 bnx2x: [bnx2x_mc_assert:736(enP24p1s0f0)]XSTORM_ASSERT_INDEX 0x0 = 0x00000000 0x25e43e47 0x00463e01 0x00010052 bnx2x: [bnx2x_mc_assert:750(enP24p1s0f0)]Chip Revision: everest3, FW Version: 7_13_1 ... (dump of values continues) ... Detect when gso_size + header length is greater than the maximum packet size (9700 bytes) and disable GSO. For simplicity and speed this is approximated by comparing gso_size against 9200 and assuming no-one will have more than 500 bytes of headers. This raises the obvious question - how do we end up with a packet with a gso_size that's greater than 9700? This has been observed on an powerpc system when Open vSwitch is forwarding a packet from an ibmveth device. ibmveth is a bit special. It's the driver for communication between virtual machines (aka 'partitions'/LPARs) running under IBM's proprietary hypervisor on ppc machines. It allows sending very large packets (up to 64kB) between LPARs. This involves some quite 'interesting' things: for example, when talking TCP, the MSS is stored the checksum field (see ibmveth_rx_mss_helper() in ibmveth.c). Normally on a box like this, there would be a Virtual I/O Server (VIOS) partition that owns the physical network card. VIOS lets the AIX partitions know when they're talking to a real network and that they should drop their MSS. This works fine if VIOS owns the physical network card. However, in this case, a Linux partition owns the card (this is known as a NovaLink setup). The negotiation between VIOS and AIX uses a non-standard TCP option, so Linux has never supported that. Instead, Linux just supports receiving large packets. It doesn't support any form of messaging/MSS negotiation back to other LPARs. To get some clarity about where the large MSS was coming from, I asked Thomas Falcon, the maintainer of ibmveth, for some background: "In most cases, large segments are an aggregation of smaller packets by the Virtual I/O Server (VIOS) partition and then are forwarded to the Linux LPAR / ibmveth driver. These segments can be as large as 64KB. In this case, since the customer is using Novalink, I believe what is happening is pretty straightforward: the large segments are created by the AIX partition and then forwarded to the Linux partition, ... The ibmveth driver doesn't do any aggregation itself but just ensures the proper bits are set before sending the frame up to avoid giving the upper layers indigestion." It is possible to stop AIX from sending these large segments, but it requires configuration on each LPAR. While ibmveth's behaviour is admittedly weird, we should fix this here: it shouldn't be possible for it to cause a firmware panic on another card. Cc: Thomas Falcon # ibmveth Cc: Yuval Mintz # bnx2x Thanks-to: Jay Vosburgh # veth info Signed-off-by: Daniel Axtens --- v2: change to a feature check as suggested by Eric Dumazet. --- drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c index 7b08323e3f3d..bab909b5d7a2 100644 --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c @@ -12934,6 +12934,17 @@ static netdev_features_t bnx2x_features_check(struct sk_buff *skb, struct net_device *dev, netdev_features_t features) { + /* + * A skb with gso_size + header length > 9700 will cause a + * firmware panic. Drop GSO support. + * + * To avoid costly calculations on all packets (and because + * super-jumbo frames are rare), allow 500 bytes of headers + * and just disable GSO if gso_size is greater than 9200. + */ + if (unlikely(skb_is_gso(skb) && skb_shinfo(skb)->gso_size > 9200)) + features &= ~NETIF_F_GSO_MASK; + features = vlan_features_check(skb, features); return vxlan_features_check(skb, features); }