From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Aaron Conole <aconole@redhat.com>, "Yang, Ziye" <ziye.yang@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>, Ziye Yang <optimistyzy@gmail.com>
Subject: Re: [dpdk-dev] [PATCH v7] linuxapp, eal: Fix the memory leak issue of logid
Date: Tue, 11 Sep 2018 14:06:36 +0000 [thread overview]
Message-ID: <2601191342CEEE43887BDE71AB977258EA954127@irsmsx105.ger.corp.intel.com> (raw)
In-Reply-To: <f7t4lewkuxp.fsf@dhcp-25.97.bos.redhat.com>
> -----Original Message-----
> From: Aaron Conole [mailto:aconole@redhat.com]
> Sent: Tuesday, September 11, 2018 2:47 PM
> To: Yang, Ziye <ziye.yang@intel.com>
> Cc: dev@dpdk.org; Ananyev, Konstantin <konstantin.ananyev@intel.com>; Ziye Yang <optimistyzy@gmail.com>
> Subject: Re: [dpdk-dev] [PATCH v7] linuxapp, eal: Fix the memory leak issue of logid
>
> Ziye Yang <ziye.yang@intel.com> writes:
>
> > From: Ziye Yang <optimistyzy@gmail.com>
> >
> > 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.
>
> This part I don't understand. It should be a separate proposal.
>
> > Signed-off-by: Ziye Yang <ziye.yang@intel.com>
> > ---
> > 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/linuxapp/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 = RTE_ATOMIC32_INIT(0);
> > - const char *logid;
> > + const char *p;
> > + static char logid[PATH_MAX];
>
> 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 wrong here.
>
> 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.
>
> > 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 = strrchr(argv[0], '/');
> > - logid = strdup(logid ? logid + 1: argv[0]);
> > -
> > + p = strrchr(argv[0], '/');
> > + snprintf(logid, sizeof(logid), "%s", (p ? p + 1 : argv[0]));
> > thread_id = 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 = ENOTSUP;
> > + rte_atomic32_clear(&run_once);
>
> 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?
>
> > 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);
>
> 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.
>
> > 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() == RTE_PROC_PRIMARY) {
> > rte_errno = EFAULT;
> > + rte_atomic32_clear(&run_once);
>
> This is also not recoverable. Why clear the run_once flag?
>
> > return -1;
> > }
> > }
next prev parent reply other threads:[~2018-09-11 14:06 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-05 5:39 [dpdk-dev] [PATCH v5] " Ziye Yang
2018-09-10 11:54 ` Ananyev, Konstantin
2018-09-10 11:58 ` Yang, Ziye
2018-09-10 12:19 ` Ananyev, Konstantin
2018-09-10 12:23 ` Yang, Ziye
2018-09-10 13:46 ` [dpdk-dev] [PATCH v6] " Ziye Yang
2018-09-11 1:27 ` [dpdk-dev] [PATCH v7] " Ziye Yang
2018-09-11 10:09 ` Ananyev, Konstantin
2018-09-11 13:47 ` Aaron Conole
2018-09-11 14:06 ` Ananyev, Konstantin [this message]
2018-09-11 15:27 ` Aaron Conole
2018-09-13 13:28 ` Aaron Conole
2018-09-12 1:31 ` [dpdk-dev] [PATCH v8] " Ziye Yang
2018-10-16 15:33 ` Ferruh Yigit
2018-10-22 8:00 ` Thomas Monjalon
2018-10-28 10:41 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2601191342CEEE43887BDE71AB977258EA954127@irsmsx105.ger.corp.intel.com \
--to=konstantin.ananyev@intel.com \
--cc=aconole@redhat.com \
--cc=dev@dpdk.org \
--cc=optimistyzy@gmail.com \
--cc=ziye.yang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).