From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 9FBC242D83 for ; Wed, 28 Jun 2023 16:11:50 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 9B28242D2D; Wed, 28 Jun 2023 16:11:50 +0200 (CEST) Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) by mails.dpdk.org (Postfix) with ESMTP id 471B940151 for ; Wed, 28 Jun 2023 16:11:49 +0200 (CEST) Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-3fa96fd79f0so46285145e9.3 for ; Wed, 28 Jun 2023 07:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687961509; x=1690553509; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=NfkBKLBNb9sqDGc9eMt+OQvtQZcTbXQ8U52Kl9JcUO4=; b=mkWHczdFYTFmT9a52hYT9IEUVzLkgOz5bNzPsR/POM1vRjwEsUMtlfAiDIlLhZ2c9q 9vy0XAfZelCWNpCS7bh7NpO7PNs1216Qn5aFFsXIkfYE/UmpTB5k0owozKQ8uliK358Q Ov+rqmSUzmDA8tQm25UyJYGGIfwzLy3fTpmH+vGQ7nOOi1HMl37xwGjzZSqZTJK4I+kG EST5TPtdOmm8N1ahoQ/YYiVbOq1HJvObUULbhsXnnpe7t7WD21Krofb29YZtETLA4N/h YOKpiUrd9SXhEC9i+u6YCaOQ0O98SrCECvLPus0J54XlKlWGP6SEFAA4Sem0moV+JVVu IdKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687961509; x=1690553509; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=NfkBKLBNb9sqDGc9eMt+OQvtQZcTbXQ8U52Kl9JcUO4=; b=hOVTtG3kFRYHR6mqdlUuRm4tov8spwyCZRXBcvBOH97Yh00kdqKxFiB/r5gSFVEc/d 6gB9F8lAZ+uJpmahrN9fnuYgf3G+SmDmS5hCx4SJyw++RVC05anWUY4/koNB7hYwjg3v w3GJneTIj5maS8eVbxJGHuwfnmw9k2mDRq1orEpIz805VZslHkTJmhFnPwPd5k1kPav3 gNoL49H6saA/l2vXtzPeZwtAn04FgGevZRrJ+zMUHBGxuXa3Zq1uqRTBn0I30OfBjIwN E2NfPXO8NU6h/LdeBV5Yij0iRDiQR18kGtKNFaUKMAdG7+CFiDXRf48D2AlJtaZiPz0p k8DQ== X-Gm-Message-State: AC+VfDy9DRO9G5lMUL3ZnvjPqhCDt3LMxSK9iJuCtHmrOFfww9+SkQfy X86bTHHizV0qWSQ4PTWsa8+WSW+6Pj+wtA== X-Google-Smtp-Source: ACHHUZ6LMrWS2u1NreQ3be4ZH7dpabdyXWG6ipbxI1nwDhVNXh7ywbGVW7ASA7PlJ+6FphLrN7e3QA== X-Received: by 2002:a7b:c44f:0:b0:3fa:9720:4c53 with SMTP id l15-20020a7bc44f000000b003fa97204c53mr9557344wmi.34.1687961508908; Wed, 28 Jun 2023 07:11:48 -0700 (PDT) Received: from localhost ([2a01:4b00:d307:1000:f1d3:eb5e:11f4:a7d9]) by smtp.gmail.com with ESMTPSA id y9-20020a7bcd89000000b003fbb5506e54sm434384wmj.29.2023.06.28.07.11.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 28 Jun 2023 07:11:48 -0700 (PDT) From: luca.boccassi@gmail.com To: Min Zhou Cc: Ruifeng Wang , dpdk stable Subject: patch 'net/ixgbe: add proper memory barriers in Rx' has been queued to stable release 20.11.9 Date: Wed, 28 Jun 2023 15:10:40 +0100 Message-Id: <20230628141046.2145871-16-luca.boccassi@gmail.com> X-Mailer: git-send-email 2.39.2 In-Reply-To: <20230628141046.2145871-1-luca.boccassi@gmail.com> References: <20230615013258.1439718-63-luca.boccassi@gmail.com> <20230628141046.2145871-1-luca.boccassi@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Hi, FYI, your patch has been queued to stable release 20.11.9 Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet. It will be pushed if I get no objections before 06/30/23. So please shout if anyone has objections. Also note that after the patch there's a diff of the upstream commit vs the patch applied to the branch. This will indicate if there was any rebasing needed to apply to the stable branch. If there were code changes for rebasing (ie: not only metadata diffs), please double check that the rebase was correctly done. Queued patches are on a temporary branch at: https://github.com/bluca/dpdk-stable This queued commit can be viewed at: https://github.com/bluca/dpdk-stable/commit/6fb5e74cd8bfd97db2188a452974c76ee574ccd3 the Thanks. Luca Boccassi --- >From 6fb5e74cd8bfd97db2188a452974c76ee574ccd3 Mon Sep 17 00:00:00 2001 From: Min Zhou Date: Tue, 13 Jun 2023 17:44:25 +0800 Subject: [PATCH] net/ixgbe: add proper memory barriers in Rx [ upstream commit 85e46c532bc76ebe07f6a397aa76211250aca59c ] Segmentation fault has been observed while running the ixgbe_recv_pkts_lro() function to receive packets on the Loongson 3C5000 processor which has 64 cores and 4 NUMA nodes. >From the ixgbe_recv_pkts_lro() function, we found that as long as the first packet has the EOP bit set, and the length of this packet is less than or equal to rxq->crc_len, the segmentation fault will definitely happen even though on the other platforms. For example, if we made the first packet which had the EOP bit set had a zero length by force, the segmentation fault would happen on X86. Because when processd the first packet the first_seg->next will be NULL, if at the same time this packet has the EOP bit set and its length is less than or equal to rxq->crc_len, the following loop will be executed: for (lp = first_seg; lp->next != rxm; lp = lp->next) ; We know that the first_seg->next will be NULL under this condition. So the expression of lp->next->next will cause the segmentation fault. Normally, the length of the first packet with EOP bit set will be greater than rxq->crc_len. However, the out-of-order execution of CPU may make the read ordering of the status and the rest of the descriptor fields in this function not be correct. The related codes are as following: rxdp = &rx_ring[rx_id]; #1 staterr = rte_le_to_cpu_32(rxdp->wb.upper.status_error); if (!(staterr & IXGBE_RXDADV_STAT_DD)) break; #2 rxd = *rxdp; The sentence #2 may be executed before sentence #1. This action is likely to make the ready packet zero length. If the packet is the first packet and has the EOP bit set, the above segmentation fault will happen. So, we should add a proper memory barrier to ensure the read ordering be correct. We also did the same thing in the ixgbe_recv_pkts() function to make the rxd data be valid even though we did not find segmentation fault in this function. Fixes: 8eecb3295aed ("ixgbe: add LRO support") Signed-off-by: Min Zhou Reviewed-by: Ruifeng Wang --- drivers/net/ixgbe/ixgbe_rxtx.c | 47 +++++++++++++++------------------- 1 file changed, 21 insertions(+), 26 deletions(-) diff --git a/drivers/net/ixgbe/ixgbe_rxtx.c b/drivers/net/ixgbe/ixgbe_rxtx.c index ab3e70d27e..7414384493 100644 --- a/drivers/net/ixgbe/ixgbe_rxtx.c +++ b/drivers/net/ixgbe/ixgbe_rxtx.c @@ -1787,11 +1787,22 @@ ixgbe_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, * of accesses cannot be reordered by the compiler. If they were * not volatile, they could be reordered which could lead to * using invalid descriptor fields when read from rxd. + * + * Meanwhile, to prevent the CPU from executing out of order, we + * need to use a proper memory barrier to ensure the memory + * ordering below. */ rxdp = &rx_ring[rx_id]; staterr = rxdp->wb.upper.status_error; if (!(staterr & rte_cpu_to_le_32(IXGBE_RXDADV_STAT_DD))) break; + + /* + * Use acquire fence to ensure that status_error which includes + * DD bit is loaded before loading of other descriptor words. + */ + rte_atomic_thread_fence(__ATOMIC_ACQUIRE); + rxd = *rxdp; /* @@ -2058,32 +2069,10 @@ ixgbe_recv_pkts_lro(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts, next_desc: /* - * The code in this whole file uses the volatile pointer to - * ensure the read ordering of the status and the rest of the - * descriptor fields (on the compiler level only!!!). This is so - * UGLY - why not to just use the compiler barrier instead? DPDK - * even has the rte_compiler_barrier() for that. - * - * But most importantly this is just wrong because this doesn't - * ensure memory ordering in a general case at all. For - * instance, DPDK is supposed to work on Power CPUs where - * compiler barrier may just not be enough! - * - * I tried to write only this function properly to have a - * starting point (as a part of an LRO/RSC series) but the - * compiler cursed at me when I tried to cast away the - * "volatile" from rx_ring (yes, it's volatile too!!!). So, I'm - * keeping it the way it is for now. - * - * The code in this file is broken in so many other places and - * will just not work on a big endian CPU anyway therefore the - * lines below will have to be revisited together with the rest - * of the ixgbe PMD. - * - * TODO: - * - Get rid of "volatile" and let the compiler do its job. - * - Use the proper memory barrier (rte_rmb()) to ensure the - * memory ordering below. + * "Volatile" only prevents caching of the variable marked + * volatile. Most important, "volatile" cannot prevent the CPU + * from executing out of order. So, it is necessary to use a + * proper memory barrier to ensure the memory ordering below. */ rxdp = &rx_ring[rx_id]; staterr = rte_le_to_cpu_32(rxdp->wb.upper.status_error); @@ -2091,6 +2080,12 @@ next_desc: if (!(staterr & IXGBE_RXDADV_STAT_DD)) break; + /* + * Use acquire fence to ensure that status_error which includes + * DD bit is loaded before loading of other descriptor words. + */ + rte_atomic_thread_fence(__ATOMIC_ACQUIRE); + rxd = *rxdp; PMD_RX_LOG(DEBUG, "port_id=%u queue_id=%u rx_id=%u " -- 2.39.2 --- Diff of the applied patch vs upstream commit (please double-check if non-empty: --- --- - 2023-06-28 11:40:08.748912143 +0100 +++ 0016-net-ixgbe-add-proper-memory-barriers-in-Rx.patch 2023-06-28 11:40:08.076027917 +0100 @@ -1 +1 @@ -From 85e46c532bc76ebe07f6a397aa76211250aca59c Mon Sep 17 00:00:00 2001 +From 6fb5e74cd8bfd97db2188a452974c76ee574ccd3 Mon Sep 17 00:00:00 2001 @@ -5,0 +6,2 @@ +[ upstream commit 85e46c532bc76ebe07f6a397aa76211250aca59c ] + @@ -50 +51,0 @@ -Cc: stable@dpdk.org @@ -59 +60 @@ -index 6cbb992823..61f17cd90b 100644 +index ab3e70d27e..7414384493 100644 @@ -62 +63 @@ -@@ -1817,11 +1817,22 @@ ixgbe_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, +@@ -1787,11 +1787,22 @@ ixgbe_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, @@ -85 +86 @@ -@@ -2088,32 +2099,10 @@ ixgbe_recv_pkts_lro(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts, +@@ -2058,32 +2069,10 @@ ixgbe_recv_pkts_lro(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts, @@ -122 +123 @@ -@@ -2121,6 +2110,12 @@ next_desc: +@@ -2091,6 +2080,12 @@ next_desc: