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
