Coverity has reported (issue ID 501503) a memory leak, but there actually were a few more problems with IPC than that. This patchset addresses said problems.
1. Using pointer as async request identity is unsafe Because asynchronous requests can fail at arbitrary points while having arbitrary number of requests or alarms already in flight, using pointer as request identity can create use-after-free risks. Patchset replaces this with using numeric request ID instead. 2. Alarm cancel can deadlock Async request handler may attempt to cancel the alarm, but an alarm might have already been in progress blocking on the same lock that is held by async request, leading to a deadlock. Patchset removes the alarm cancel call, and allows the alarm to fire. This is fine, because due to fix #1 the worst that can happen from calling stale alarm is a noop, as request ID would not be found. 3. Memory leaks There are a couple of memory leaks in failure paths. Patchset fixes those. 4. Zero-peer async request does not trigger alarm When async requests are performed but no peers exist, we created a dummy request and put it on the queue, but we never set the dummy alarm that is supposed to handle that request. Patchset adds the alarm set in dummy paths where none was present before. v6: Moved pieces around, namely: 1) apply request ID refactor first as a standalone patch 2) fix the deadlock immediately after 3) fix memory leaks next 4) add missing callback as a final step Contents of the patchset remain the same. Anatoly Burakov (6): eal: fix wrong log message in async IPC request eal: use request ID instead of pointers eal: avoid deadlock in async IPC alarm callback eal: fix async IPC memory leaks on partial failure eal: fix memory leak in async IPC secondary path eal: fix async IPC callback not fired when no peers lib/eal/common/eal_common_proc.c | 133 +++++++++++++++++++++++-------- 1 file changed, 99 insertions(+), 34 deletions(-) -- 2.47.3
