Message ID | 20190417143854.21588-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/bus/vdev/vdev.c b/drivers/bus/vdev/vdev.c index 04f76a63f..7c43f2ddd 100644 --- a/drivers/bus/vdev/vdev.c +++ b/drivers/bus/vdev/vdev.c @@ -429,10 +429,9 @@ vdev_scan(void) mp_rep = &mp_reply.msgs[0]; resp = (struct vdev_param *)mp_rep->param; VDEV_LOG(INFO, "Received %d vdevs", resp->num); - free(mp_reply.msgs); } else VDEV_LOG(ERR, "Failed to request vdev from primary"); - + free(mp_reply.msgs); /* Fall through to allow private vdevs in secondary process */ }
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 the reply message buffers. Fixes: cdb068f031c6 ("bus/vdev: scan by multi-process channel") Cc: jianfeng.tan@intel.com Cc: stable@dpdk.org Signed-off-by: Herakliusz Lipiec <herakliusz.lipiec@intel.com> --- drivers/bus/vdev/vdev.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)