From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 8294BB10C for ; Tue, 24 Jun 2014 18:17:22 +0200 (CEST) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 24 Jun 2014 09:12:15 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,539,1400050800"; d="scan'208";a="562588145" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by orsmga002.jf.intel.com with ESMTP; 24 Jun 2014 09:17:32 -0700 Received: from irsmsx152.ger.corp.intel.com (163.33.192.66) by IRSMSX101.ger.corp.intel.com (163.33.3.153) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 24 Jun 2014 17:16:03 +0100 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.76]) by IRSMSX152.ger.corp.intel.com ([169.254.6.25]) with mapi id 14.03.0123.003; Tue, 24 Jun 2014 17:16:03 +0100 From: "Ananyev, Konstantin" To: Stephen Hemminger , "dev@dpdk.org" Thread-Topic: [dpdk-dev] [PATCH] mempool: don't leak ring on failure Thread-Index: AQHPj8QYQ7ZoaTliqUCLplGQnzL/EpuAbGIA Date: Tue, 24 Jun 2014 16:16:02 +0000 Message-ID: <2601191342CEEE43887BDE71AB977258213340B1@IRSMSX105.ger.corp.intel.com> References: <20140624084948.6d4ab3cd@nehalam.linuxnetplumber.net> In-Reply-To: <20140624084948.6d4ab3cd@nehalam.linuxnetplumber.net> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.181] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] mempool: don't leak ring on failure X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jun 2014 16:17:23 -0000 Hi Stephen, >=20 > If mempool can not be created because of insufficient memory > it returns an error but has already created a ring (and leaves it > behind). This prevents code from trying one mempool size and then > retrying with a smaller size if the bigger size fails. >=20 > Reordering to do ring creation after getting memory fixes > the problem. > But now, memzone created for the actual mempool could get leaked instead? =20 > Signed-off-by: Stephen Hemminger >=20 >=20 > --- a/lib/librte_mempool/rte_mempool.c 2014-06-24 08:20:28.513771717 -070= 0 > +++ b/lib/librte_mempool/rte_mempool.c 2014-06-24 08:20:28.513771717 -070= 0 > @@ -473,15 +473,6 @@ rte_mempool_xmem_create(const char *name >=20 > rte_rwlock_write_lock(RTE_EAL_MEMPOOL_RWLOCK); >=20 > - /* allocate the ring that will be used to store objects */ > - /* Ring functions will return appropriate errors if we are > - * running as a secondary process etc., so no checks made > - * in this function for that condition */ > - rte_snprintf(rg_name, sizeof(rg_name), RTE_MEMPOOL_MZ_FORMAT, name); > - r =3D rte_ring_create(rg_name, rte_align32pow2(n+1), socket_id, rg_flag= s); > - if (r =3D=3D NULL) > - goto exit; > - > /* > * reserve a memory zone for this mempool: private data is > * cache-aligned > @@ -542,6 +533,15 @@ rte_mempool_xmem_create(const char *name > startaddr =3D (void*)addr; > } >=20 > + /* allocate the ring that will be used to store objects */ > + /* Ring functions will return appropriate errors if we are > + * running as a secondary process etc., so no checks made > + * in this function for that condition */ > + rte_snprintf(rg_name, sizeof(rg_name), RTE_MEMPOOL_MZ_FORMAT, name); > + r =3D rte_ring_create(rg_name, rte_align32pow2(n+1), socket_id, rg_flag= s); > + if (r =3D=3D NULL) > + goto exit; > + > /* init the mempool structure */ > mp =3D startaddr; > memset(mp, 0, sizeof(*mp));