patch 'net/tap: fix traffic control handle calculation' has been queued to stable release 23.11.1

[Xueming Li]

Hi,

FYI, your patch has been queued to stable release 23.11.1

Note it hasn't been pushed to http://dpdk.org/browse/dpdk-stable yet.
It will be pushed if I get no objections before 04/15/24. 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://git.dpdk.org/dpdk-stable/log/?h=23.11-staging

This queued commit can be viewed at:
https://git.dpdk.org/dpdk-stable/commit/?h=23.11-staging&id=1d5bfd9fdf17cb809a9e32da71d2abc92f2bf871

Thanks.

Xueming Li <xuemingl at nvidia.com>

---
>From 1d5bfd9fdf17cb809a9e32da71d2abc92f2bf871 Mon Sep 17 00:00:00 2001
From: Stephen Hemminger <stephen at networkplumber.org>
Date: Thu, 29 Feb 2024 09:31:08 -0800
Subject: [PATCH] net/tap: fix traffic control handle calculation
Cc: Xueming Li <xuemingl at nvidia.com>

[ upstream commit 4e924ff6f789c6a67424263bf384f3e4b4fba373 ]

The code to take a flow pointer and make a TC handle was incorrect
and would always generate the same handle. This is because it was
hashing the address of the union on the stack (which is invariant)
rather than the contents of the union.

The following testpmd case would cause an error:
testpmd> flow create 0 ingress pattern eth src is 06:05:04:03:02:01 \
  / end actions queue index 2 / end
Flow rule #0 created
testpmd> flow create 0 ingress pattern eth src is 06:05:04:03:02:02 \
  / end actions queue index 3 / end
tap_nl_dump_ext_ack(): Filter already exists
tap_flow_create(): Kernel refused TC filter rule creation (17): File exists
port_flow_complain(): Caught PMD error type 2 (flow rule (handle)):
  overlapping rules or Kernel too old for flower support: File exists

This fix does it in a more robust manner using size independent
code. It also initializes the hash seed so the same hash won't
show up every time and risk potential leakage of address to
other places.

Bugzilla ID: 1382
Fixes: de96fe68ae95 ("net/tap: add basic flow API patterns and actions")
Fixes: a625ab89df11 ("net/tap: fix build with GCC 11")

Signed-off-by: Stephen Hemminger <stephen at networkplumber.org>
---
 drivers/net/tap/tap_flow.c | 23 ++++++++++++-----------
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/net/tap/tap_flow.c b/drivers/net/tap/tap_flow.c
index 5b0fee9064..fa50fe45d7 100644
--- a/drivers/net/tap/tap_flow.c
+++ b/drivers/net/tap/tap_flow.c
@@ -11,6 +11,7 @@
 
 #include <rte_byteorder.h>
 #include <rte_jhash.h>
+#include <rte_random.h>
 #include <rte_malloc.h>
 #include <rte_eth_tap.h>
 #include <tap_flow.h>
@@ -1297,9 +1298,7 @@ tap_flow_validate(struct rte_eth_dev *dev,
  * In those rules, the handle (uint32_t) is the part that would identify
  * specifically each rule.
  *
- * On 32-bit architectures, the handle can simply be the flow's pointer address.
- * On 64-bit architectures, we rely on jhash(flow) to find a (sufficiently)
- * unique handle.
+ * Use jhash of the flow pointer to make a unique handle.
  *
  * @param[in, out] flow
  *   The flow that needs its handle set.
@@ -1309,16 +1308,18 @@ tap_flow_set_handle(struct rte_flow *flow)
 {
 	union {
 		struct rte_flow *flow;
-		const void *key;
-	} tmp;
-	uint32_t handle = 0;
+		uint32_t words[sizeof(flow) / sizeof(uint32_t)];
+	} tmp = {
+		.flow = flow,
+	};
+	uint32_t handle;
+	static uint64_t hash_seed;
 
-	tmp.flow = flow;
+	if (hash_seed == 0)
+		hash_seed = rte_rand();
+
+	handle = rte_jhash_32b(tmp.words, sizeof(flow) / sizeof(uint32_t), hash_seed);
 
-	if (sizeof(flow) > 4)
-		handle = rte_jhash(tmp.key, sizeof(flow), 1);
-	else
-		handle = (uintptr_t)flow;
 	/* must be at least 1 to avoid letting the kernel choose one for us */
 	if (!handle)
 		handle = 1;
-- 
2.34.1

---
  Diff of the applied patch vs upstream commit (please double-check if non-empty:
---
--- -	2024-04-13 20:43:05.777702013 +0800
+++ 0020-net-tap-fix-traffic-control-handle-calculation.patch	2024-04-13 20:43:04.937754010 +0800
@@ -1 +1 @@
-From 4e924ff6f789c6a67424263bf384f3e4b4fba373 Mon Sep 17 00:00:00 2001
+From 1d5bfd9fdf17cb809a9e32da71d2abc92f2bf871 Mon Sep 17 00:00:00 2001
@@ -4,0 +5,3 @@
+Cc: Xueming Li <xuemingl at nvidia.com>
+
+[ upstream commit 4e924ff6f789c6a67424263bf384f3e4b4fba373 ]
@@ -30 +32,0 @@
-Cc: stable at dpdk.org