From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Wang, Yipeng1" Subject: Re: [PATCH v4 1/2] hash table: fix a bug in rte_hash_iterate() Date: Wed, 10 Oct 2018 01:55:28 +0000 Message-ID: References: <20180831165101.20026-1-qiaobinf@bu.edu> <20181009192907.85650-1-qiaobinf@bu.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Cc: "dev@dpdk.org" , "doucette@bu.edu" , "Wiles, Keith" , "Gobriel, Sameh" , "Tai, Charlie" , "stephen@networkplumber.org" , "nd@arm.com" , "honnappa.nagarahalli@arm.com" , "michel@digirati.com.br" To: Qiaobin Fu , "Richardson, Bruce" , "De Lara Guarch, Pablo" Return-path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) by dpdk.org (Postfix) with ESMTP id CC3221B490 for ; Wed, 10 Oct 2018 04:01:54 +0200 (CEST) In-Reply-To: <20181009192907.85650-1-qiaobinf@bu.edu> Content-Language: en-US List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Hi Qiaobin, This patch: http://patchwork.dpdk.org/patch/46105/ covers the bug. Honnapp= a 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 ; De Lara Guarch, Pablo = >Cc: dev@dpdk.org; doucette@bu.edu; Wiles, Keith ; G= obriel, Sameh ; Tai, Charlie >; stephen@networkplumber.org; nd@arm.com; honnappa.= nagarahalli@arm.com; Wang, Yipeng1 >; 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 >Reviewed-by: Michel Machado >--- > 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_cucko= o_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 v= oid **key, void **data, uint32 > bucket_idx =3D *next / RTE_HASH_BUCKET_ENTRIES; > idx =3D *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] =3D=3D EMPTY_SLOT) { > (*next)++; > /* End of table */ >- if (*next =3D=3D total_entries) >+ if (*next =3D=3D total_entries) { >+ __hash_rw_reader_unlock(h); > return -ENOENT; >+ } > bucket_idx =3D *next / RTE_HASH_BUCKET_ENTRIES; > idx =3D *next % RTE_HASH_BUCKET_ENTRIES; > } >- __hash_rw_reader_lock(h); > /* Get position of entry in key table */ > position =3D h->buckets[bucket_idx].key_idx[idx]; > next_key =3D (struct rte_hash_key *) ((char *)h->key_store + >-- >2.17.1