[dpdk-stable] patch 'hash: fix race condition in iterate' has been queued to stable release 18.08.1

[Kevin Traynor]

Hi,

FYI, your patch has been queued to stable release 18.08.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 11/28/18. 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. If the code is different (ie: not only metadata diffs), due for example to
a change in context or macro names, please double check it.

Thanks.

Kevin Traynor

---
>From e916f02d3fb7ddf504589359aa941ec0971da471 Mon Sep 17 00:00:00 2001
From: Yipeng Wang <yipeng1.wang at intel.com>
Date: Mon, 22 Oct 2018 11:39:45 -0700
Subject: [PATCH] hash: fix race condition in iterate

[ upstream commit 99040943442426ebfef0ad69eca73559a9e3b730 ]

In rte_hash_iterate, the reader lock did not protect the
while loop which checks empty entry. This created a race
condition that the entry may become empty when enters
the lock, then a wrong key data value would be read out.

This commit reads out the position in the while condition,
which makes sure that the position will not be changed
to empty before entering the lock.

Fixes: f2e3001b53ec ("hash: support read/write concurrency")

Reported-by: Honnappa Nagarahalli <honnappa.nagarahalli at arm.com>
Signed-off-by: Yipeng Wang <yipeng1.wang at intel.com>
Reviewed-by: Honnappa Nagarahalli <honnappa.nagarahalli at arm.com>
Acked-by: Dharmik Thakkar <dharmik.thakkar at arm.com>
Acked-by: Bruce Richardson <bruce.richardson at intel.com>
---
 lib/librte_hash/rte_cuckoo_hash.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/lib/librte_hash/rte_cuckoo_hash.c b/lib/librte_hash/rte_cuckoo_hash.c
index f7b86c8c9..da8ddf40a 100644
--- a/lib/librte_hash/rte_cuckoo_hash.c
+++ b/lib/librte_hash/rte_cuckoo_hash.c
@@ -1319,5 +1319,5 @@ rte_hash_iterate(const struct rte_hash *h, const void **key, void **data, uint32
 
 	/* If current position is empty, go to the next one */
-	while (h->buckets[bucket_idx].key_idx[idx] == EMPTY_SLOT) {
+	while ((position = h->buckets[bucket_idx].key_idx[idx]) == EMPTY_SLOT) {
 		(*next)++;
 		/* End of table */
@@ -1327,7 +1327,6 @@ rte_hash_iterate(const struct rte_hash *h, const void **key, void **data, uint32
 		idx = *next % RTE_HASH_BUCKET_ENTRIES;
 	}
+
 	__hash_rw_reader_lock(h);
-	/* Get position of entry in key table */
-	position = h->buckets[bucket_idx].key_idx[idx];
 	next_key = (struct rte_hash_key *) ((char *)h->key_store +
 				position * h->key_entry_size);
-- 
2.19.0

---
  Diff of the applied patch vs upstream commit (please double-check if non-empty:
---
--- -	2018-11-22 16:47:33.134904760 +0000
+++ 0034-hash-fix-race-condition-in-iterate.patch	2018-11-22 16:47:32.000000000 +0000
@@ -1,8 +1,10 @@
-From 99040943442426ebfef0ad69eca73559a9e3b730 Mon Sep 17 00:00:00 2001
+From e916f02d3fb7ddf504589359aa941ec0971da471 Mon Sep 17 00:00:00 2001
 From: Yipeng Wang <yipeng1.wang at intel.com>
 Date: Mon, 22 Oct 2018 11:39:45 -0700
 Subject: [PATCH] hash: fix race condition in iterate
 
+[ upstream commit 99040943442426ebfef0ad69eca73559a9e3b730 ]
+
 In rte_hash_iterate, the reader lock did not protect the
 while loop which checks empty entry. This created a race
 condition that the entry may become empty when enters
@@ -13,7 +15,6 @@
 to empty before entering the lock.
 
 Fixes: f2e3001b53ec ("hash: support read/write concurrency")
-Cc: stable at dpdk.org
 
 Reported-by: Honnappa Nagarahalli <honnappa.nagarahalli at arm.com>
 Signed-off-by: Yipeng Wang <yipeng1.wang at intel.com>