ipc: fix access after async request failure
authorAnatoly Burakov <anatoly.burakov@intel.com>
Tue, 20 Nov 2018 16:18:46 +0000 (16:18 +0000)
committerThomas Monjalon <thomas@monjalon.net>
Fri, 23 Nov 2018 00:43:24 +0000 (01:43 +0100)
commit615fcf55d24eeb3747b3300b25f61eed8f9053ab
treeb3f36756ebe78cca576ea7f4c3c3fa82d8af8cff
parent109cb989d9a9c55ca80256cbde184b6a22be3b86
ipc: fix access after async request failure

Previous fix for rte_panic has moved setting of alarm before
sending the message. This means that whether we send a message,
the alarm would still trigger. The comment noted that cleanup
would happen in the alarm handler, but that's not what actually
happened - instead, in the event of failed send we freed the
memory in-place, before putting the request on the queue.

This works OK when the message is sent, but when sending the
message fails, the alarm would still trigger with a pointer
argument that points to non-existent memory, and cause
memory corruption.

There probably is a "proper" fix for this issue, with correct
handling of sent vs. unsent requests, however it would be
simpler just to sacrifice the sent request in the (extremely
unlikely) event of alarm set failing. The other process would
still send a response, but it will be ignored by the sender.

Fixes: 45e5f49e87fb ("ipc: remove panic in async request")

Signed-off-by: Anatoly Burakov <anatoly.burakov@intel.com>
lib/librte_eal/common/eal_common_proc.c