Message ID | 20190425124817.28409-1-herakliusz.lipiec@intel.com (mailing list archive) |
---|---|
Headers |
Return-Path: <dev-bounces@dpdk.org> X-Original-To: patchwork@dpdk.org Delivered-To: patchwork@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id A575E1B592; Thu, 25 Apr 2019 14:47:44 +0200 (CEST) Received: from mga07.intel.com (mga07.intel.com [134.134.136.100]) by dpdk.org (Postfix) with ESMTP id CBB871B590 for <dev@dpdk.org>; Thu, 25 Apr 2019 14:47:42 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga105.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Apr 2019 05:47:41 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.60,393,1549958400"; d="scan'208";a="145632751" Received: from silpixa00399499.ir.intel.com (HELO silpixa00399499.ger.corp.intel.com) ([10.237.222.133]) by orsmga003.jf.intel.com with ESMTP; 25 Apr 2019 05:47:40 -0700 From: Herakliusz Lipiec <herakliusz.lipiec@intel.com> To: Cc: dev@dpdk.org, anatoly.burakov@intel.com, Herakliusz Lipiec <herakliusz.lipiec@intel.com> Date: Thu, 25 Apr 2019 13:48:15 +0100 Message-Id: <20190425124817.28409-1-herakliusz.lipiec@intel.com> X-Mailer: git-send-email 2.17.2 In-Reply-To: <20190425114324.611-1-herakliusz.lipiec@intel.com> References: <20190425114324.611-1-herakliusz.lipiec@intel.com> Subject: [dpdk-dev] [PATCH v4 0/2] ipc: fix possible memleaks X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> |
Series |
ipc: fix possible memleaks
|
|
Message
Herakliusz Lipiec
April 25, 2019, 12:48 p.m. UTC
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 initializing message buffer to NULL and calling free everytime rte_mp_request_sync is used. v2: - resending as patchset to make it easier to review it. - changed commit message as requested. - added bugzilla id. Bugzilla ID: 228 v3: - rework of the patchset - caller is no longer responsible for freeing buffers on failure - caller still has to free response buffers on success v4: - fixed checkpatch issues Herakliusz Lipiec (2): ipc: fix rte_mp_request_sync memleak ipc: fix tap pmd memleak drivers/net/tap/rte_eth_tap.c | 2 +- lib/librte_eal/common/eal_common_proc.c | 22 +++++++++++++++------- 2 files changed, 16 insertions(+), 8 deletions(-)
Comments
25/04/2019 14:48, Herakliusz Lipiec: > 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 initializing message buffer > to NULL and calling free everytime rte_mp_request_sync > is used. > > v2: > - resending as patchset to make it easier to review it. Heraliusz, it's a total mess. There were 8 patches in v2. Why they disappeared? The title prefixes are often wrong, so it's harder to classify them. Should I merge all these patches? ipc: fix rte_mp_request_sync memleak ipc: fix hotplug memleak ipc: fix vdev memleak ipc: fix vfio memleak ipc: fix pdump memleak ipc: fix tap pmd memleak ipc: fix net/mlx4 memleak ipc: fix net/mlx5 memleak
On 03-May-19 9:34 AM, Thomas Monjalon wrote: > 25/04/2019 14:48, Herakliusz Lipiec: >> 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 initializing message buffer >> to NULL and calling free everytime rte_mp_request_sync >> is used. >> >> v2: >> - resending as patchset to make it easier to review it. > > Heraliusz, it's a total mess. > There were 8 patches in v2. Why they disappeared? > The title prefixes are often wrong, so it's harder to classify them. > > Should I merge all these patches? > ipc: fix rte_mp_request_sync memleak > ipc: fix hotplug memleak > ipc: fix vdev memleak > ipc: fix vfio memleak > ipc: fix pdump memleak > ipc: fix tap pmd memleak > ipc: fix net/mlx4 memleak > ipc: fix net/mlx5 memleak > Hi Thomas, you've also skipped the following: > v3: > - rework of the patchset > - caller is no longer responsible for freeing buffers on failure > - caller still has to free response buffers on success the v3 was where the 8 patch patchset was reworked into two-patch patchset, because we've changed our approach. So no, those 8 patches should not be merged - they're superseded by v3 (well, v4 now).