From patchwork Thu May 15 08:46:45 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Ian Campbell X-Patchwork-Id: 30225 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-vc0-f200.google.com (mail-vc0-f200.google.com [209.85.220.200]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id A73CF20446 for ; Thu, 15 May 2014 08:47:18 +0000 (UTC) Received: by mail-vc0-f200.google.com with SMTP id lc6sf10410067vcb.7 for ; Thu, 15 May 2014 01:47:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:delivered-to:message-id:subject:from:to:cc:date :in-reply-to:references:organization:mime-version:sender:precedence :list-id:x-original-sender:x-original-authentication-results :mailing-list:list-post:list-help:list-archive:list-unsubscribe :content-type:content-transfer-encoding; bh=RMPL/RIl1oBq9DKve16Gr14FcGzlu4U95AAdW65ff80=; b=HCK4FlxYOab2Jsjzk5sXzVQqqOt0VL/4cMPq8dO/DHCSAeTgXU9Q/SZjSSS/e1Ptg4 7x2W4wHIBvl1emVDJPBEnVgV8uHHDfYAW3nBePyLm74m3+ejmAtx6Tv0r6VC8xW4H6fS rMjcWsTo/2hTiI0pPW0VkfdXSw4DklYUAVdTjzD+W3SpmuvapxgZn3kul2kHCqPZA+Cb VJSPlorZXoxf5YlaBBoIAtXshiTJmWCDl/RkPFCTrbowwfjf2kiKLnYWeMaUZcpehv01 VilES7IP/E6NP7Z8MPzYlCNbLIpuDfHOiyYMVo2c8UqjErjQuJWA58JmnUo3IxDiAfV8 P5wQ== X-Gm-Message-State: ALoCoQlk5Plw0X8YGeJEkLRuVh3bNrmNnLVd38nB8VLoHNChPWZFy+tqUM8NXVts4FB3fU2jDMaw X-Received: by 10.58.168.137 with SMTP id zw9mr4631284veb.15.1400143638500; Thu, 15 May 2014 01:47:18 -0700 (PDT) X-BeenThere: patchwork-forward@linaro.org Received: by 10.140.84.72 with SMTP id k66ls118679qgd.96.gmail; Thu, 15 May 2014 01:47:18 -0700 (PDT) X-Received: by 10.52.74.196 with SMTP id w4mr6278867vdv.19.1400143638420; Thu, 15 May 2014 01:47:18 -0700 (PDT) Received: from mail-vc0-f175.google.com (mail-vc0-f175.google.com [209.85.220.175]) by mx.google.com with ESMTPS id o19si815976vcp.57.2014.05.15.01.47.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 15 May 2014 01:47:18 -0700 (PDT) Received-SPF: pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.220.175 as permitted sender) client-ip=209.85.220.175; Received: by mail-vc0-f175.google.com with SMTP id hu19so3914764vcb.6 for ; Thu, 15 May 2014 01:47:18 -0700 (PDT) X-Received: by 10.221.29.137 with SMTP id ry9mr7570460vcb.6.1400143638320; Thu, 15 May 2014 01:47:18 -0700 (PDT) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patch@linaro.org Received: by 10.220.221.72 with SMTP id ib8csp304891vcb; Thu, 15 May 2014 01:47:16 -0700 (PDT) X-Received: by 10.66.122.208 with SMTP id lu16mr10608623pab.129.1400143636429; Thu, 15 May 2014 01:47:16 -0700 (PDT) Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id ub6si4677268pab.41.2014.05.15.01.47.15; Thu, 15 May 2014 01:47:15 -0700 (PDT) Received-SPF: none (google.com: netdev-owner@vger.kernel.org does not designate permitted sender hosts) client-ip=209.132.180.67; Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752149AbaEOIrK (ORCPT + 3 others); Thu, 15 May 2014 04:47:10 -0400 Received: from smtp.citrix.com ([66.165.176.89]:2299 "EHLO SMTP.CITRIX.COM" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750786AbaEOIrE (ORCPT ); Thu, 15 May 2014 04:47:04 -0400 X-IronPort-AV: E=Sophos;i="4.97,1057,1389744000"; d="scan'208";a="131393372" Received: from accessns.citrite.net (HELO FTLPEX01CL01.citrite.net) ([10.9.154.239]) by FTLPIPO01.CITRIX.COM with ESMTP; 15 May 2014 08:46:47 +0000 Received: from kazak.uk.xensource.com (10.80.2.80) by FTLPEX01CL01.citrite.net (10.13.107.78) with Microsoft SMTP Server id 14.3.181.6; Thu, 15 May 2014 04:46:46 -0400 Message-ID: <1400143605.1006.1.camel@kazak.uk.xensource.com> Subject: Re: [Xen-devel] xen-netfront possibly rides the rocket too often From: Ian Campbell To: Zoltan Kiss CC: Stefan Bader , , netdev , Wei Liu Date: Thu, 15 May 2014 09:46:45 +0100 In-Reply-To: <5373C8D4.2010803@citrix.com> References: <537262AB.5010408@canonical.com> <5373C8D4.2010803@citrix.com> Organization: Citrix Systems, Inc. X-Mailer: Evolution 3.12.1-1 MIME-Version: 1.0 X-Originating-IP: [10.80.2.80] X-DLP: MIA2 Sender: netdev-owner@vger.kernel.org Precedence: list List-ID: X-Mailing-List: netdev@vger.kernel.org X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: ian.campbell@citrix.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of patch+caf_=patchwork-forward=linaro.org@linaro.org designates 209.85.220.175 as permitted sender) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org X-Google-Group-Id: 836684582541 List-Post: , List-Help: , List-Archive: List-Unsubscribe: , On Wed, 2014-05-14 at 20:49 +0100, Zoltan Kiss wrote: > On 13/05/14 19:21, Stefan Bader wrote: > > We had reports about this message being seen on EC2 for a while but finally a > > reporter did notice some details about the guests and was able to provide a > > simple way to reproduce[1]. > > > > For my local experiments I use a Xen-4.2.2 based host (though I would say the > > host versions are not important). The host has one NIC which is used as the > > outgoing port of a Linux based (not openvswitch) bridge. And the PV guests use > > that bridge. I set the mtu to 9001 (which was seen on affected instance types) > > and also inside the guests. As described in the report one guests runs > > redis-server and the other nodejs through two scripts (for me I had to do the > > two sub.js calls in separate shells). After a bit the error messages appear on > > the guest running the redis-server. > > > > I added some debug printk's to show a bit more detail about the skb and got the > > following (@): > > > > [ 698.108119] xen_netfront: xennet: skb rides the rocket: 19 slots > > [ 698.108134] header 1490@238 -> 1 slots > > [ 698.108139] frag #0 1614@2164 -> + 1 pages > > [ 698.108143] frag #1 3038@1296 -> + 2 pages > > [ 698.108147] frag #2 6076@1852 -> + 2 pages > > [ 698.108151] frag #3 6076@292 -> + 2 pages > > [ 698.108156] frag #4 6076@2828 -> + 3 pages > > [ 698.108160] frag #5 3038@1268 -> + 2 pages > > [ 698.108164] frag #6 2272@1824 -> + 1 pages > > [ 698.108168] frag #7 3804@0 -> + 1 pages > > [ 698.108172] frag #8 6076@264 -> + 2 pages > > [ 698.108177] frag #9 3946@2800 -> + 2 pages > > [ 698.108180] frags adding 18 slots > > > > Since I am not deeply familiar with the networking code, I wonder about two things: > > - is there something that should limit the skb data length from all frags > > to stay below the 64K which the definition of MAX_SKB_FRAGS hints? > I think netfront should be able to handle 64K packets at most. Ah, maybe this relates to this fix from Wei? commit 9ecd1a75d977e2e8c48139c7d3efed183f898d94 Author: Wei Liu Date: Mon Apr 22 02:20:41 2013 +0000 xen-netfront: reduce gso_max_size to account for max TCP header The maximum packet including header that can be handled by netfront / netback wire format is 65535. Reduce gso_max_size accordingly. Drop skb and print warning when skb->len > 65535. This can 1) save the effort to send malformed packet to netback, 2) help spotting misconfiguration of netfront in the future. Signed-off-by: Wei Liu Acked-by: Ian Campbell Signed-off-by: David S. Miller --- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c index 1bb2e20..1db10141 100644 --- a/drivers/net/xen-netfront.c +++ b/drivers/net/xen-netfront.c @@ -36,7 +36,7 @@ #include #include #include -#include +#include #include #include #include @@ -547,6 +547,16 @@ static int xennet_start_xmit(struct sk_buff *skb, struct net_device *dev) unsigned int len = skb_headlen(skb); unsigned long flags; + /* If skb->len is too big for wire format, drop skb and alert + * user about misconfiguration. + */ + if (unlikely(skb->len > XEN_NETIF_MAX_TX_SIZE)) { + net_alert_ratelimited( + "xennet: skb->len = %u, too big for wire format\n", + skb->len); + goto drop; + } + slots = DIV_ROUND_UP(offset + len, PAGE_SIZE) + xennet_count_skb_frag_slots(skb); if (unlikely(slots > MAX_SKB_FRAGS + 1)) { @@ -1058,7 +1068,8 @@ err: static int xennet_change_mtu(struct net_device *dev, int mtu) { - int max = xennet_can_sg(dev) ? 65535 - ETH_HLEN : ETH_DATA_LEN; + int max = xennet_can_sg(dev) ? + XEN_NETIF_MAX_TX_SIZE - MAX_TCP_HEADER : ETH_DATA_LEN; if (mtu > max) return -EINVAL; @@ -1362,6 +1373,8 @@ static struct net_device *xennet_create_dev(struct xenbus_device *dev) SET_ETHTOOL_OPS(netdev, &xennet_ethtool_ops); SET_NETDEV_DEV(netdev, &dev->dev); + netif_set_gso_max_size(netdev, XEN_NETIF_MAX_TX_SIZE - MAX_TCP_HEADER); + np->netdev = netdev; netif_carrier_off(netdev); diff --git a/include/xen/interface/io/netif.h b/include/xen/interface/io/netif.h index 9dfc120..58fadca 100644 --- a/include/xen/interface/io/netif.h +++ b/include/xen/interface/io/netif.h @@ -47,6 +47,7 @@ #define _XEN_NETTXF_extra_info (3) #define XEN_NETTXF_extra_info (1U<<_XEN_NETTXF_extra_info) +#define XEN_NETIF_MAX_TX_SIZE 0xFFFF struct xen_netif_tx_request { grant_ref_t gref; /* Reference to buffer page */ uint16_t offset; /* Offset within buffer page */