From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-10.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id AA89EC33CB3 for ; Thu, 16 Jan 2020 18:16:22 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 882DE20730 for ; Thu, 16 Jan 2020 18:16:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1579198582; bh=ouDOGODEY/dNR0K0ljr0NFswmyk7CBZsCorqDZUqP4Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=Fa58rP44KlmwyLjGsQgEt8jftdAhlfu9m47+bium1uMyrB3gW8VhbGuSEbPbxPxAI VTrS5jMEYICdnYihjRmw60IYzFcQe5jEFb0stkoLq1eA0Hp80m5s3DCKNjwZ14uYbB s92mDd5FsLlkYuVPICmVIhN43+3tNVCpTmxkyG0g= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2405349AbgAPSQV (ORCPT ); Thu, 16 Jan 2020 13:16:21 -0500 Received: from mail.kernel.org ([198.145.29.99]:41338 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2392722AbgAPR32 (ORCPT ); Thu, 16 Jan 2020 12:29:28 -0500 Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id A5F1824719; Thu, 16 Jan 2020 17:29:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1579195767; bh=ouDOGODEY/dNR0K0ljr0NFswmyk7CBZsCorqDZUqP4Y=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BRnW+1i0yfpCl2JLc3/e5K8GCfirPWT7KScok1/hOHAOUEEYBCLyDFM+meUFjofsa 0huc4akveKPD1GaxA006yqafipXTAs1oY0zphdPjAAzroLGNUaQjn76caca9pwszwp /VMDFRORL0Ktz8GFykbVWSmlNsaz+C5IG9VhR8hQ= From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Firo Yang , Alexander Duyck , Andrew Bowers , Jeff Kirsher , Sasha Levin , intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org Subject: [PATCH AUTOSEL 4.14 295/371] ixgbe: sync the first fragment unconditionally Date: Thu, 16 Jan 2020 12:22:47 -0500 Message-Id: <20200116172403.18149-238-sashal@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20200116172403.18149-1-sashal@kernel.org> References: <20200116172403.18149-1-sashal@kernel.org> MIME-Version: 1.0 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Firo Yang [ Upstream commit e7ba676c6188d394a0133fc4b9bcd7ee50d54b7f ] In Xen environment, if Xen-swiotlb is enabled, ixgbe driver could possibly allocate a page, DMA memory buffer, for the first fragment which is not suitable for Xen-swiotlb to do DMA operations. Xen-swiotlb have to internally allocate another page for doing DMA operations. This mechanism requires syncing the data from the internal page to the page which ixgbe sends to upper network stack. However, since commit f3213d932173 ("ixgbe: Update driver to make use of DMA attributes in Rx path"), the unmap operation is performed with DMA_ATTR_SKIP_CPU_SYNC. As a result, the sync is not performed. Since the sync isn't performed, the upper network stack could receive a incomplete network packet. By incomplete, it means the linear data on the first fragment(between skb->head and skb->end) is invalid. So we have to copy the data from the internal xen-swiotlb page to the page which ixgbe sends to upper network stack through the sync operation. More details from Alexander Duyck: Specifically since we are mapping the frame with DMA_ATTR_SKIP_CPU_SYNC we have to unmap with that as well. As a result a sync is not performed on an unmap and must be done manually as we skipped it for the first frag. As such we need to always sync before possibly performing a page unmap operation. Fixes: f3213d932173 ("ixgbe: Update driver to make use of DMA attributes in Rx path") Signed-off-by: Firo Yang Reviewed-by: Alexander Duyck Tested-by: Andrew Bowers Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin --- drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 16 +++++++++------- 1 file changed, 9 insertions(+), 7 deletions(-) diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c index 0edfd199937d..e4c1e6345edd 100644 --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c @@ -1871,13 +1871,7 @@ static void ixgbe_pull_tail(struct ixgbe_ring *rx_ring, static void ixgbe_dma_sync_frag(struct ixgbe_ring *rx_ring, struct sk_buff *skb) { - /* if the page was released unmap it, else just sync our portion */ - if (unlikely(IXGBE_CB(skb)->page_released)) { - dma_unmap_page_attrs(rx_ring->dev, IXGBE_CB(skb)->dma, - ixgbe_rx_pg_size(rx_ring), - DMA_FROM_DEVICE, - IXGBE_RX_DMA_ATTR); - } else if (ring_uses_build_skb(rx_ring)) { + if (ring_uses_build_skb(rx_ring)) { unsigned long offset = (unsigned long)(skb->data) & ~PAGE_MASK; dma_sync_single_range_for_cpu(rx_ring->dev, @@ -1894,6 +1888,14 @@ static void ixgbe_dma_sync_frag(struct ixgbe_ring *rx_ring, skb_frag_size(frag), DMA_FROM_DEVICE); } + + /* If the page was released, just unmap it. */ + if (unlikely(IXGBE_CB(skb)->page_released)) { + dma_unmap_page_attrs(rx_ring->dev, IXGBE_CB(skb)->dma, + ixgbe_rx_pg_size(rx_ring), + DMA_FROM_DEVICE, + IXGBE_RX_DMA_ATTR); + } } /** -- 2.20.1