DPDK patches and discussions
 help / color / mirror / Atom feed
From: Aaron Conole <aconole@redhat.com>
To: "Ananyev\, Konstantin" <konstantin.ananyev@intel.com>
Cc: "Yang\, Ziye" <ziye.yang@intel.com>,
	"dev\@dpdk.org" <dev@dpdk.org>, Ziye Yang <optimistyzy@gmail.com>,
	Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [dpdk-dev] [PATCH v7] linuxapp, eal: Fix the memory leak issue of logid
Date: Thu, 13 Sep 2018 09:28:05 -0400	[thread overview]
Message-ID: <f7tmuslwmqi.fsf@dhcp-25.97.bos.redhat.com> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB977258EA954127@irsmsx105.ger.corp.intel.com> (Konstantin Ananyev's message of "Tue, 11 Sep 2018 14:06:36 +0000")

On second thought - please just fold in the patch I
proposed back in July that I was told would be merged:

  http://mails.dpdk.org/archives/dev/2018-July/108445.html
  http://mails.dpdk.org/archives/dev/2018-August/109177.html

It doesn't include the issues calling rte_atomic32_clear (that I have
concerns about) and preserves an arbitrary length value being passed
through argv/argc.

:-)

-Aaron

"Ananyev, Konstantin" <konstantin.ananyev@intel.com> writes:

>> -----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;
>> >  		}
>> >  	}

  parent reply	other threads:[~2018-09-13 13:28 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
2018-09-11 15:27       ` Aaron Conole
2018-09-13 13:28       ` Aaron Conole [this message]
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=f7tmuslwmqi.fsf@dhcp-25.97.bos.redhat.com \
    --to=aconole@redhat.com \
    --cc=dev@dpdk.org \
    --cc=konstantin.ananyev@intel.com \
    --cc=optimistyzy@gmail.com \
    --cc=thomas@monjalon.net \
    --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).