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 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 +- 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 ++- 7 files changed, 103 insertions(+), 87 deletions(-) -- 2.1.4
