Seen while trying to fix the func_reentrancy autotest. The
series addresses several issues:
1/ Hash and lpm return a pointer to an existing object if the user requests the
creation with an already existing name. This look dangerous: when an object
is returned, the user does not know if it should be freed or not.
2/ There is a race condition in cuckoo_hash as the lock is not held in
rte_hash_create(). We could find some cases where NULL is returned when the
object already exists (ex: when rte_ring_create() fails).
3/ There is a race condition func_reentrancy that can fail even if the tested
API behaves correctly.
RFC -> v1:
- split the patch in 4 patches
- on error, set rte_errno to EEXIST when relevant
- fix locking in cuckoo_hash creation
v1 -> v2:
- fix compilation issue in cuckoo hash
- update the hash test to conform to the new behavior
- rework locking modification in cuckoo_hash
- passed autotests: hash, lpm, lpm6, func_reentrancy
v2 -> v3:
- rebase against head
- add "Fixes:" in commit messages
- properly set lpm or hash pointers to NULL on error before returning
v3 -> v4:
- add entries in the release note to explain the API changes
in lpm and hash
- correct the "Fixes:" line in the first 2 patches
Olivier Matz (4):
lpm: allocation of an existing object should fail
hash: allocation of an existing object should fail
hash: keep the list locked at creation
autotest: fix func reentrancy
app/test/test_func_reentrancy.c| 31 ++-
app/test/test_hash.c | 65 +++---
app/test/test_lpm6.c | 2 +-
doc/guides/rel_notes/release_16_04.rst | 17
lib/librte_hash/rte_cuckoo_hash.c | 72 --
lib/librte_hash/rte_fbk_hash.c | 5 ++-
lib/librte_lpm/rte_lpm.c | 10 -
lib/librte_lpm/rte_lpm6.c | 5 ++-
8 files changed, 120 insertions(+), 87 deletions(-)
--
2.1.4
