All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Wang, Yipeng1" <yipeng1.wang@intel.com>
To: Qiaobin Fu <qiaobinf@bu.edu>,
	"Richardson, Bruce" <bruce.richardson@intel.com>,
	"De Lara Guarch, Pablo" <pablo.de.lara.guarch@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>,
	"doucette@bu.edu" <doucette@bu.edu>,
	"Wiles, Keith" <keith.wiles@intel.com>,
	"Gobriel, Sameh" <sameh.gobriel@intel.com>,
	"Tai, Charlie" <charlie.tai@intel.com>,
	"stephen@networkplumber.org" <stephen@networkplumber.org>,
	"nd@arm.com" <nd@arm.com>,
	"honnappa.nagarahalli@arm.com" <honnappa.nagarahalli@arm.com>,
	"michel@digirati.com.br" <michel@digirati.com.br>
Subject: Re: [PATCH v4 1/2] hash table: fix a bug in rte_hash_iterate()
Date: Wed, 10 Oct 2018 01:55:28 +0000	[thread overview]
Message-ID: <D2C4A16CA39F7F4E8E384D204491D7A6614EE328@FMSMSX151.amr.corp.intel.com> (raw)
In-Reply-To: <20181009192907.85650-1-qiaobinf@bu.edu>

Hi Qiaobin,

This patch: http://patchwork.dpdk.org/patch/46105/ covers the bug.  Honnappa suggested a fix that would work well for the lock free implementation as well.

>-----Original Message-----
>From: Qiaobin Fu [mailto:qiaobinf@bu.edu]
>Sent: Tuesday, October 9, 2018 12:29 PM
>To: Richardson, Bruce <bruce.richardson@intel.com>; De Lara Guarch, Pablo <pablo.de.lara.guarch@intel.com>
>Cc: dev@dpdk.org; doucette@bu.edu; Wiles, Keith <keith.wiles@intel.com>; Gobriel, Sameh <sameh.gobriel@intel.com>; Tai, Charlie
><charlie.tai@intel.com>; stephen@networkplumber.org; nd@arm.com; honnappa.nagarahalli@arm.com; Wang, Yipeng1
><yipeng1.wang@intel.com>; michel@digirati.com.br; qiaobinf@bu.edu
>Subject: [PATCH v4 1/2] hash table: fix a bug in rte_hash_iterate()
>
>In current implementation of rte_hash_iterate(), it
>tries to obtain the lock after the while loop. However,
>this may lead to a bug. Notice the following racing condition:
>
>1. The while loop above finishes because it finds
>   a not empty slot. But it does so without a lock.
>2. Then we get the lock.
>3. The position that was once not empty is now empty.
>   BUG because next_key is invalid.
>
>This patch fixes this small bug.
>
>Signed-off-by: Qiaobin Fu <qiaobinf@bu.edu>
>Reviewed-by: Michel Machado <michel@digirati.com.br>
>---
> lib/librte_hash/rte_cuckoo_hash.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
>diff --git a/lib/librte_hash/rte_cuckoo_hash.c b/lib/librte_hash/rte_cuckoo_hash.c
>index f7b86c8c9..a3e76684d 100644
>--- a/lib/librte_hash/rte_cuckoo_hash.c
>+++ b/lib/librte_hash/rte_cuckoo_hash.c
>@@ -1317,16 +1317,18 @@ rte_hash_iterate(const struct rte_hash *h, const void **key, void **data, uint32
> 	bucket_idx = *next / RTE_HASH_BUCKET_ENTRIES;
> 	idx = *next % RTE_HASH_BUCKET_ENTRIES;
>
>+	__hash_rw_reader_lock(h);
> 	/* If current position is empty, go to the next one */
> 	while (h->buckets[bucket_idx].key_idx[idx] == EMPTY_SLOT) {
> 		(*next)++;
> 		/* End of table */
>-		if (*next == total_entries)
>+		if (*next == total_entries) {
>+			__hash_rw_reader_unlock(h);
> 			return -ENOENT;
>+		}
> 		bucket_idx = *next / RTE_HASH_BUCKET_ENTRIES;
> 		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 +
>--
>2.17.1

      parent reply	other threads:[~2018-10-10  2:01 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-31 16:51 [PATCH v3] hash table: add an iterator over conflicting entries Qiaobin Fu
2018-08-31 22:53 ` Gaëtan Rivet
2018-09-04 18:46   ` Michel Machado
2018-09-02 22:05 ` Honnappa Nagarahalli
2018-09-04 19:36   ` Michel Machado
2018-09-05 22:13     ` Honnappa Nagarahalli
2018-09-06 14:28       ` Michel Machado
2018-09-12 20:37         ` Honnappa Nagarahalli
2018-09-20 19:50           ` Michel Machado
2018-09-04 18:55 ` Wang, Yipeng1
2018-09-04 19:07   ` Michel Machado
2018-09-04 19:51     ` Wang, Yipeng1
2018-09-04 20:26       ` Michel Machado
2018-09-04 20:57         ` Wang, Yipeng1
2018-09-05 17:52           ` Michel Machado
2018-09-05 20:27             ` Wang, Yipeng1
2018-09-06 13:34               ` Michel Machado
2018-10-09 19:29 ` [PATCH v4 1/2] hash table: fix a bug in rte_hash_iterate() Qiaobin Fu
2018-10-09 19:29   ` [PATCH v4 2/2] hash table: add an iterator over conflicting entries Qiaobin Fu
2018-10-10  2:54     ` Wang, Yipeng1
2018-10-10  1:55   ` Wang, Yipeng1 [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=D2C4A16CA39F7F4E8E384D204491D7A6614EE328@FMSMSX151.amr.corp.intel.com \
    --to=yipeng1.wang@intel.com \
    --cc=bruce.richardson@intel.com \
    --cc=charlie.tai@intel.com \
    --cc=dev@dpdk.org \
    --cc=doucette@bu.edu \
    --cc=honnappa.nagarahalli@arm.com \
    --cc=keith.wiles@intel.com \
    --cc=michel@digirati.com.br \
    --cc=nd@arm.com \
    --cc=pablo.de.lara.guarch@intel.com \
    --cc=qiaobinf@bu.edu \
    --cc=sameh.gobriel@intel.com \
    --cc=stephen@networkplumber.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.