| Message ID | 20190417144245.23353-1-herakliusz.lipiec@intel.com (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Delegated to: | Thomas Monjalon |
| Headers | show |
| Series | [1/8] ipc: fix rte_mp_request_sync memleak | expand |
| Context | Check | Description |
|---|---|---|
| ci/checkpatch | success | coding style OK |
| ci/Intel-compilation | success | Compilation OK |
diff --git a/drivers/net/tap/rte_eth_tap.c b/drivers/net/tap/rte_eth_tap.c index e9fda8cf6..d70412d62 100644 --- a/drivers/net/tap/rte_eth_tap.c +++ b/drivers/net/tap/rte_eth_tap.c @@ -2104,6 +2104,7 @@ tap_mp_attach_queues(const char *port_name, struct rte_eth_dev *dev) if (ret < 0) { TAP_LOG(ERR, "Failed to request queues from primary: %d", rte_errno); + free(replies.msgs); return -1; } reply = &replies.msgs[0]; @@ -2119,6 +2120,7 @@ tap_mp_attach_queues(const char *port_name, struct rte_eth_dev *dev) for (queue = 0; queue < reply_param->txq_count; queue++) process_private->txq_fds[queue] = reply->fds[fd_iterator++]; + free(replies.msgs); return 0; }
When sending multiple requests, rte_mp_request_sync can succeed sending a few of those requests, but then fail on a later one and in the end return with rc=-1. The upper layers - e.g. device hotplug - currently handles this case as if no messages were sent and no memory for response buffers was allocated, which is not true. Fixed by always freeing reply message buffers. Fixes: c9aa56edec8e ("net/tap: access primary process queues from secondary") Cc: rasland@mellanox.com Cc: stable@dpdk.org Signed-off-by: Herakliusz Lipiec <herakliusz.lipiec@intel.com> --- drivers/net/tap/rte_eth_tap.c | 2 ++ 1 file changed, 2 insertions(+)