Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp6014945pxb; Mon, 14 Feb 2022 13:10:28 -0800 (PST) X-Google-Smtp-Source: ABdhPJwEmMkIz/Aeu46F/GV/b2WG/x3HoLyM070HWrECfjxbkIZL3mAtqb70tLjQT0S9sCRHUlEv X-Received: by 2002:a63:6aca:: with SMTP id f193mr758635pgc.85.1644873028683; Mon, 14 Feb 2022 13:10:28 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1644873028; cv=none; d=google.com; s=arc-20160816; b=k/UTTxMAl0br9lMoPjoBi29I2AHt8A4MdxUWX027mjfFoOJufDbSCgb0RmikT0SHtW vJE5AYzOx9sYVztvA0Sb9RRUnALqkfXBKT7p4sikLPe5MQjjYGhNA9Snn84QMtuRb1rD 0M0AJzwTKq0HZMIcGiokdOyt8oamUG6x/osSKaWMH1inVhF0cZMBeKpbH9mMXlGguXDc b2chANAdeQZ/iSMmHlh3lFtIy0SQAZ2cM9rjH9+WMkXT497ZnYqpPcugpkVDLtWaapVb htPP2MQU9VC1bk0Bsanbvq0PSlaK1VHhG2imD3JSMX3Ff5Xxhjne6ZGEVx1OzWJwHWrR bHUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=bpv6XQW3sG3PvDdNyNuhfX8DM7mOJHdjHBRWd/5An0E=; b=zo4jCL/1xn990M9Kmc7SYYZt5xprEqXxmwqxfLqqOQEp+9dtQZ3qvnAKRrFNS46Zsa EL+N4drzjAZq6zkCcMNRMzgS3pFEpHpqTw7N5JF4pUprsw0ojCnYH3NCRFVFA4LmiV8c hXdDxpoa3F3y/Xrxdsds4aObOKA5k6CHYYu8kQXpGEcOFnF9XUM6G7TdvnvD0NBmjFWa T1UFRyW7NVgxJgeTzlq/gi4Gsf2JMMU4JiCdelmON3tgbxLDhXzjhjgGRKW3nGWt/xYT 8k5rOReBs+tMZ475n8zSuexIAPwd6kAejCwIiHqNl0TQchAnrM/+iGYC9uwoD5vBlzON 1gQg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=xj08xgfD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id q1si13131897pln.67.2022.02.14.13.10.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 14 Feb 2022 13:10:28 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@linuxfoundation.org header.s=korg header.b=xj08xgfD; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linuxfoundation.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 0463720D37C; Mon, 14 Feb 2022 12:30:20 -0800 (PST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231633AbiBNKOE (ORCPT + 99 others); Mon, 14 Feb 2022 05:14:04 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:44746 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1345709AbiBNKNK (ORCPT ); Mon, 14 Feb 2022 05:13:10 -0500 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1565C59A63; Mon, 14 Feb 2022 01:51:22 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id C1820B80DC4; Mon, 14 Feb 2022 09:51:20 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E3FBEC340EF; Mon, 14 Feb 2022 09:51:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1644832279; bh=YYnbQUNHnyZnPlW0EXMkhiN07cJiuJLrOZ2257GGNHE=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=xj08xgfD13OdK/APT9R8t0yiN6BSiHPHP5epMUADCYgW8PPTVNbhpglYxNzJrDJdb eBirdkDIW/+BLMJpfcGIfu2nZUW9OZAM+JP6u0ipDPxb2xKOss7y91aDm+PppK9mlC b8NAhVuznixrixomcDnPbZfC4N4t/vpqlsIe9OYI= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Samuel Mendoza-Jonas , Konrad Jankowski , Tony Nguyen , "David S. Miller" , Sasha Levin Subject: [PATCH 5.15 104/172] ixgbevf: Require large buffers for build_skb on 82599VF Date: Mon, 14 Feb 2022 10:26:02 +0100 Message-Id: <20220214092509.987469123@linuxfoundation.org> X-Mailer: git-send-email 2.35.1 In-Reply-To: <20220214092506.354292783@linuxfoundation.org> References: <20220214092506.354292783@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RDNS_NONE,SPF_HELO_NONE,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Samuel Mendoza-Jonas [ Upstream commit fe68195daf34d5dddacd3f93dd3eafc4beca3a0e ] >From 4.17 onwards the ixgbevf driver uses build_skb() to build an skb around new data in the page buffer shared with the ixgbe PF. This uses either a 2K or 3K buffer, and offsets the DMA mapping by NET_SKB_PAD + NET_IP_ALIGN. When using a smaller buffer RXDCTL is set to ensure the PF does not write a full 2K bytes into the buffer, which is actually 2K minus the offset. However on the 82599 virtual function, the RXDCTL mechanism is not available. The driver attempts to work around this by using the SET_LPE mailbox method to lower the maximm frame size, but the ixgbe PF driver ignores this in order to keep the PF and all VFs in sync[0]. This means the PF will write up to the full 2K set in SRRCTL, causing it to write NET_SKB_PAD + NET_IP_ALIGN bytes past the end of the buffer. With 4K pages split into two buffers, this means it either writes NET_SKB_PAD + NET_IP_ALIGN bytes past the first buffer (and into the second), or NET_SKB_PAD + NET_IP_ALIGN bytes past the end of the DMA mapping. Avoid this by only enabling build_skb when using "large" buffers (3K). These are placed in each half of an order-1 page, preventing the PF from writing past the end of the mapping. [0]: Technically it only ever raises the max frame size, see ixgbe_set_vf_lpe() in ixgbe_sriov.c Fixes: f15c5ba5b6cd ("ixgbevf: add support for using order 1 pages to receive large frames") Signed-off-by: Samuel Mendoza-Jonas Tested-by: Konrad Jankowski Signed-off-by: Tony Nguyen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin --- drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c index c714e1ecd3089..7ef2e1241a76e 100644 --- a/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c +++ b/drivers/net/ethernet/intel/ixgbevf/ixgbevf_main.c @@ -1984,14 +1984,15 @@ static void ixgbevf_set_rx_buffer_len(struct ixgbevf_adapter *adapter, if (adapter->flags & IXGBEVF_FLAGS_LEGACY_RX) return; - set_ring_build_skb_enabled(rx_ring); + if (PAGE_SIZE < 8192) + if (max_frame > IXGBEVF_MAX_FRAME_BUILD_SKB) + set_ring_uses_large_buffer(rx_ring); - if (PAGE_SIZE < 8192) { - if (max_frame <= IXGBEVF_MAX_FRAME_BUILD_SKB) - return; + /* 82599 can't rely on RXDCTL.RLPML to restrict the size of the frame */ + if (adapter->hw.mac.type == ixgbe_mac_82599_vf && !ring_uses_large_buffer(rx_ring)) + return; - set_ring_uses_large_buffer(rx_ring); - } + set_ring_build_skb_enabled(rx_ring); } /** -- 2.34.1