[dpdk-stable] patch 'net/tap: fix check for mbuf number of segment' has been queued to stable release 19.11.3

[luca.boccassi at gmail.com]

Hi,

FYI, your patch has been queued to stable release 19.11.3

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet.
It will be pushed if I get no objections before 05/21/20. 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.

Thanks.

Luca Boccassi

---
>From 2b74a885aafea68be58f6ad98cc2acf7af7ce086 Mon Sep 17 00:00:00 2001
From: Yunjian Wang <wangyunjian at huawei.com>
Date: Thu, 16 Apr 2020 11:04:35 +0800
Subject: [PATCH] net/tap: fix check for mbuf number of segment

[ upstream commit cc6cf04f59ec20757990b3e8586b7c3a7f497720 ]

Now the rxq->pool is mbuf concatenation, but its nb_segs is 1. When
conducting some sanity checks on the mbuf with debug enabled, it fails.

Fixes: 0781f5762cfe ("net/tap: support segmented mbufs")

Signed-off-by: Yunjian Wang <wangyunjian at huawei.com>
Reviewed-by: Ferruh Yigit <ferruh.yigit at intel.com>
Acked-by: Stephen Hemminger <stephen at networkplumber.org>
---
 drivers/net/tap/rte_eth_tap.c | 25 +++++++++++++++++++++----
 1 file changed, 21 insertions(+), 4 deletions(-)

diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c
index 9c88b9268e..2846ce0d3e 100644
--- a/drivers/net/tap/rte_eth_tap.c
+++ b/drivers/net/tap/rte_eth_tap.c
@@ -338,6 +338,23 @@ tap_rx_offload_get_queue_capa(void)
 	       DEV_RX_OFFLOAD_TCP_CKSUM;
 }
 
+static void
+tap_rxq_pool_free(struct rte_mbuf *pool)
+{
+	struct rte_mbuf *mbuf = pool;
+	uint16_t nb_segs = 1;
+
+	if (mbuf == NULL)
+		return;
+
+	while (mbuf->next) {
+		mbuf = mbuf->next;
+		nb_segs++;
+	}
+	pool->nb_segs = nb_segs;
+	rte_pktmbuf_free(pool);
+}
+
 /* Callback to handle the rx burst of packets to the correct interface and
  * file descriptor(s) in a multi-queue setup.
  */
@@ -388,7 +405,7 @@ pmd_rx_burst(void *queue, struct rte_mbuf **bufs, uint16_t nb_pkts)
 					goto end;
 
 				seg->next = NULL;
-				rte_pktmbuf_free(mbuf);
+				tap_rxq_pool_free(mbuf);
 
 				goto end;
 			}
@@ -1035,7 +1052,7 @@ tap_dev_close(struct rte_eth_dev *dev)
 			rxq = &internals->rxq[i];
 			close(process_private->rxq_fds[i]);
 			process_private->rxq_fds[i] = -1;
-			rte_pktmbuf_free(rxq->pool);
+			tap_rxq_pool_free(rxq->pool);
 			rte_free(rxq->iovecs);
 			rxq->pool = NULL;
 			rxq->iovecs = NULL;
@@ -1074,7 +1091,7 @@ tap_rx_queue_release(void *queue)
 	if (process_private->rxq_fds[rxq->queue_id] > 0) {
 		close(process_private->rxq_fds[rxq->queue_id]);
 		process_private->rxq_fds[rxq->queue_id] = -1;
-		rte_pktmbuf_free(rxq->pool);
+		tap_rxq_pool_free(rxq->pool);
 		rte_free(rxq->iovecs);
 		rxq->pool = NULL;
 		rxq->iovecs = NULL;
@@ -1484,7 +1501,7 @@ tap_rx_queue_setup(struct rte_eth_dev *dev,
 	return 0;
 
 error:
-	rte_pktmbuf_free(rxq->pool);
+	tap_rxq_pool_free(rxq->pool);
 	rxq->pool = NULL;
 	rte_free(rxq->iovecs);
 	rxq->iovecs = NULL;
-- 
2.20.1

---
  Diff of the applied patch vs upstream commit (please double-check if non-empty:
---
--- -	2020-05-19 14:04:48.345034391 +0100
+++ 0095-net-tap-fix-check-for-mbuf-number-of-segment.patch	2020-05-19 14:04:44.304649968 +0100
@@ -1,13 +1,14 @@
-From cc6cf04f59ec20757990b3e8586b7c3a7f497720 Mon Sep 17 00:00:00 2001
+From 2b74a885aafea68be58f6ad98cc2acf7af7ce086 Mon Sep 17 00:00:00 2001
 From: Yunjian Wang <wangyunjian at huawei.com>
 Date: Thu, 16 Apr 2020 11:04:35 +0800
 Subject: [PATCH] net/tap: fix check for mbuf number of segment
 
+[ upstream commit cc6cf04f59ec20757990b3e8586b7c3a7f497720 ]
+
 Now the rxq->pool is mbuf concatenation, but its nb_segs is 1. When
 conducting some sanity checks on the mbuf with debug enabled, it fails.
 
 Fixes: 0781f5762cfe ("net/tap: support segmented mbufs")
-Cc: stable at dpdk.org
 
 Signed-off-by: Yunjian Wang <wangyunjian at huawei.com>
 Reviewed-by: Ferruh Yigit <ferruh.yigit at intel.com>