From patchwork Sat Apr 16 10:25:53 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Kicinski X-Patchwork-Id: 611330 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id 3qn9Yr6T8Mz9t64 for ; Sat, 16 Apr 2016 20:26:40 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=netronome-com.20150623.gappssmtp.com header.i=@netronome-com.20150623.gappssmtp.com header.b=mBfv2p6g; dkim-atps=neutral Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751333AbcDPK03 (ORCPT ); Sat, 16 Apr 2016 06:26:29 -0400 Received: from mail-wm0-f48.google.com ([74.125.82.48]:35756 "EHLO mail-wm0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751246AbcDPK0Z (ORCPT ); Sat, 16 Apr 2016 06:26:25 -0400 Received: by mail-wm0-f48.google.com with SMTP id a140so60657756wma.0 for ; Sat, 16 Apr 2016 03:26:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netronome-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=hAa4jiNzibGd+BY0GuNr1MsS7SUX2H3vkGYOwdOn+eE=; b=mBfv2p6gerqfSrLQvJ0ZxXtLut2v+j8DiGSKnUjnUWbhx6wG0nXuhCbPU79Kg3hrgi TGSgqNw+lwY4UvuhdRn6MfbA0/j28l42/Ip81pWcqQ0JnytlNZcyqaXzwDkeBsyv04V8 sL3MjmBEjAo5CZdqQ+uMd2sRvV03PotY5Z5M6whx9xL2H9t6DUEnmpDc9LUSseCA//VR dt8K0jKOVmHdlXXuAVC7+G7dRBMXL8rfaRSZsO2pk7No+nQJzqGlxYKvUQi7keds7Fry SokwHp3mA3a4M5qOLxnErYww/1z8LvuIPkVa+rOHgC3l/VRlqJ850gSUAYIsCCmZ+gDb VYDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=hAa4jiNzibGd+BY0GuNr1MsS7SUX2H3vkGYOwdOn+eE=; b=fPIYRjYmsXHBlI3cTgRs/ylaYHZWJDl429ULMwk+MNy5Sk5+X+KAV04MUkJTqmoALH azp8RJgfSEbicGzVGkBMH6VEmgfKt3fusKvSeu3OfX+bOqhwfzOv1xR8IEExw4+OPJex 6Pyc+OY4PMmNmoKBXIQvOePsF4mAvJKQ3AZRZH5d/h3vDX8aM6q5O5N/L3foAgR8R2LY 9Eb5sUbipaz8KPb2Cs2I3kTL/qrJpGo06fEElUOWUMIGKe/jda995ttmNVNETjBH5Uxa ivAYQpMes2pocsVNvm8jK9UNdamQ2k47qEKyRiQFPoE3OpcmWCYcfv7z9wJ9cxt2n1W4 t93w== X-Gm-Message-State: AOPr4FWKYGcDWioKQn7dO/LtnWZPS3JN0CpvYkS8Fr1QMd9GojZ4mNwgkN0NXIEKEs59mWKN X-Received: by 10.28.158.202 with SMTP id h193mr8616645wme.35.1460802383793; Sat, 16 Apr 2016 03:26:23 -0700 (PDT) Received: from jkicinski-Precision-T1700.netronome.com ([79.78.33.110]) by smtp.gmail.com with ESMTPSA id a1sm53263080wje.43.2016.04.16.03.26.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 16 Apr 2016 03:26:23 -0700 (PDT) From: Jakub Kicinski To: netdev@vger.kernel.org Cc: Jakub Kicinski Subject: [PATCH net-next 5/6] nfp: remove buggy RX buffer length validation Date: Sat, 16 Apr 2016 11:25:53 +0100 Message-Id: <1460802354-14248-6-git-send-email-jakub.kicinski@netronome.com> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1460802354-14248-1-git-send-email-jakub.kicinski@netronome.com> References: <1460802354-14248-1-git-send-email-jakub.kicinski@netronome.com> Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org Meaning of data_len and meta_len RX WB descriptor fields is slightly confusing. Add a comment with a diagram clarifying the layout. Also remove the buffer length validation: (a) it's imprecise for static rx-offsets; (b) if firmware is buggy enough to DMA past the end of the buffer WARN_ON_ONCE() doesn't seem like a strong enough response. skb_put() will do the checking for us anyway. Signed-off-by: Jakub Kicinski --- .../net/ethernet/netronome/nfp/nfp_net_common.c | 26 ++++++++++++---------- 1 file changed, 14 insertions(+), 12 deletions(-) diff --git a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c index 0bdff390c958..5235e86eb684 100644 --- a/drivers/net/ethernet/netronome/nfp/nfp_net_common.c +++ b/drivers/net/ethernet/netronome/nfp/nfp_net_common.c @@ -1298,23 +1298,25 @@ static int nfp_net_rx(struct nfp_net_rx_ring *rx_ring, int budget) nfp_net_rx_give_one(rx_ring, new_skb, new_dma_addr); + /* < meta_len > + * <-- [rx_offset] --> + * --------------------------------------------------------- + * | [XX] | metadata | packet | XXXX | + * --------------------------------------------------------- + * <---------------- data_len ---------------> + * + * The rx_offset is fixed for all packets, the meta_len can vary + * on a packet by packet basis. If rx_offset is set to zero + * (_RX_OFFSET_DYNAMIC) metadata starts at the beginning of the + * buffer and is immediately followed by the packet (no [XX]). + */ meta_len = rxd->rxd.meta_len_dd & PCIE_DESC_RX_META_LEN_MASK; data_len = le16_to_cpu(rxd->rxd.data_len); - if (WARN_ON_ONCE(data_len > nn->fl_bufsz)) { - dev_kfree_skb_any(skb); - continue; - } - - if (nn->rx_offset == NFP_NET_CFG_RX_OFFSET_DYNAMIC) { - /* The packet data starts after the metadata */ + if (nn->rx_offset == NFP_NET_CFG_RX_OFFSET_DYNAMIC) skb_reserve(skb, meta_len); - } else { - /* The packet data starts at a fixed offset */ + else skb_reserve(skb, nn->rx_offset); - } - - /* Adjust the SKB for the dynamic meta data pre-pended */ skb_put(skb, data_len - meta_len); nfp_net_set_hash(nn->netdev, skb, rxd);