From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id 67B204C92 for ; Tue, 11 Sep 2018 16:06:39 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Sep 2018 07:06:38 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.53,360,1531810800"; d="scan'208";a="72064076" Received: from irsmsx108.ger.corp.intel.com ([163.33.3.3]) by orsmga007.jf.intel.com with ESMTP; 11 Sep 2018 07:06:37 -0700 Received: from irsmsx105.ger.corp.intel.com ([169.254.7.54]) by IRSMSX108.ger.corp.intel.com ([169.254.11.13]) with mapi id 14.03.0319.002; Tue, 11 Sep 2018 15:06:36 +0100 From: "Ananyev, Konstantin" To: Aaron Conole , "Yang, Ziye" CC: "dev@dpdk.org" , Ziye Yang Thread-Topic: [dpdk-dev] [PATCH v7] linuxapp, eal: Fix the memory leak issue of logid Thread-Index: AQHUSdX49NTz9BwsC06fyRilaCIaeaTrHCog Date: Tue, 11 Sep 2018 14:06:36 +0000 Message-ID: <2601191342CEEE43887BDE71AB977258EA954127@irsmsx105.ger.corp.intel.com> References: <1536125954-46632-1-git-send-email-ziye.yang@intel.com> <1536629269-35295-1-git-send-email-ziye.yang@intel.com> In-Reply-To: Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMmNiN2Q1OTAtMTUxZC00Mjg5LWJkMWItYzIxNDdjOGU3MzBhIiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiTFlZS0lmeUQ2TUtTdHNPdWc5ZUJmemtJUUZ4MVVsdkVkVGZkZ1FQMjkrR3A0R1V3XC9tWmd5OWtZMm9vNmZRS1IifQ== x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.400.15 dlp-reaction: no-action 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 v7] linuxapp, eal: Fix the memory leak issue of logid X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Sep 2018 14:06:40 -0000 > -----Original Message----- > From: Aaron Conole [mailto:aconole@redhat.com] > Sent: Tuesday, September 11, 2018 2:47 PM > To: Yang, Ziye > Cc: dev@dpdk.org; Ananyev, Konstantin ; Ziy= e Yang > Subject: Re: [dpdk-dev] [PATCH v7] linuxapp, eal: Fix the memory leak iss= ue of logid >=20 > Ziye Yang writes: >=20 > > From: Ziye Yang > > > > This patch is used to fix the memory leak issue of logid. > > We use the ASAN test in SPDK when intergrating DPDK and > > find this memory leak issue. > > > > By the way, we also fix several missed function call of > > rte_atomic32_clear. >=20 > This part I don't understand. It should be a separate proposal. >=20 > > Signed-off-by: Ziye Yang > > --- > > lib/librte_eal/linuxapp/eal/eal.c | 11 +++++++---- > > 1 file changed, 7 insertions(+), 4 deletions(-) > > > > diff --git a/lib/librte_eal/linuxapp/eal/eal.c b/lib/librte_eal/linuxap= p/eal/eal.c > > index e59ac65..a5129e5 100644 > > --- a/lib/librte_eal/linuxapp/eal/eal.c > > +++ b/lib/librte_eal/linuxapp/eal/eal.c > > @@ -793,7 +793,8 @@ static void rte_eal_init_alert(const char *msg) > > int i, fctret, ret; > > pthread_t thread_id; > > static rte_atomic32_t run_once =3D RTE_ATOMIC32_INIT(0); > > - const char *logid; > > + const char *p; > > + static char logid[PATH_MAX]; >=20 > On a linux system, PATH_MAX is 4096, but an argument may be > MAX_ARG_STRLEN which is significantly higher. But we only interested here in 'basename(argv[0])'. Surely it shouldn't be bigger than PATH_MAX unless something is terribly wr= ong here. >=20 > Have you thought about an alternative where you keep the strdup and add > an atexit() handler to do the free? Otherwise, you'll need to add code > to check the string length as well and enforce some kind of size > restriction. snprintf() below will do a safe truncation for us. >=20 > > char cpuset[RTE_CPU_AFFINITY_STR_LEN]; > > char thread_name[RTE_MAX_THREAD_NAME_LEN]; > > > > @@ -810,9 +811,8 @@ static void rte_eal_init_alert(const char *msg) > > return -1; > > } > > > > - logid =3D strrchr(argv[0], '/'); > > - logid =3D strdup(logid ? logid + 1: argv[0]); > > - > > + p =3D strrchr(argv[0], '/'); > > + snprintf(logid, sizeof(logid), "%s", (p ? p + 1 : argv[0])); > > thread_id =3D pthread_self(); > > > > eal_reset_internal_config(&internal_config); > > @@ -823,6 +823,7 @@ static void rte_eal_init_alert(const char *msg) > > if (rte_eal_cpu_init() < 0) { > > rte_eal_init_alert("Cannot detect lcores."); > > rte_errno =3D ENOTSUP; > > + rte_atomic32_clear(&run_once); >=20 > This is not recoverable. No amount of retry will allow the user to > re-init the eal - the hardware isn't supported. Why clear the run_once > flag? >=20 > > return -1; > > } > > > > @@ -851,6 +852,7 @@ static void rte_eal_init_alert(const char *msg) > > > > if (rte_eal_intr_init() < 0) { > > rte_eal_init_alert("Cannot init interrupt-handling thread\n"); > > + rte_atomic32_clear(&run_once); >=20 > Arguable whether or not this is recoverable. IIRC, the eal_intr_init > spawns a thread - if it fails to spawn the likelihood is the process > won't be able to continue. >=20 > > return -1; > > } > > > > @@ -861,6 +863,7 @@ static void rte_eal_init_alert(const char *msg) > > rte_eal_init_alert("failed to init mp channel\n"); > > if (rte_eal_process_type() =3D=3D RTE_PROC_PRIMARY) { > > rte_errno =3D EFAULT; > > + rte_atomic32_clear(&run_once); >=20 > This is also not recoverable. Why clear the run_once flag? >=20 > > return -1; > > } > > }