DPDK patches and discussions
 help / color / mirror / Atom feed
From: Olivier MATZ <olivier.matz@6wind.com>
To: Adrien Mazarguil <adrien.mazarguil@6wind.com>
Cc: Xueming Li <xuemingl@mellanox.com>,
	Wenzhuo Lu <wenzhuo.lu@intel.com>,
	dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH v1] lib/cmdline: init parse result memory
Date: Fri, 8 Dec 2017 16:26:14 +0100	[thread overview]
Message-ID: <20171208152612.75nttsciba3imn6x@platinum> (raw)
In-Reply-To: <20171208150433.GU4062@6wind.com>

Hi,

On Fri, Dec 08, 2017 at 04:04:33PM +0100, Adrien Mazarguil wrote:
> On Fri, Dec 08, 2017 at 02:51:15PM +0100, Olivier MATZ wrote:
> > On Fri, Dec 08, 2017 at 01:27:26PM +0100, Adrien Mazarguil wrote:
> > > On Fri, Dec 08, 2017 at 03:02:44PM +0800, Xueming Li wrote:
> > > > Initialize binary result memory before parsing to avoid garbage in
> > > > parsing result.
> > > > 
> > > > Signed-off-by: Xueming Li <xuemingl@mellanox.com>
> > > 
> > > Since you chose to move the break statement, maybe the original commit
> > > mentioned in my previous message (9b3fbb051d2e "cmdline: fix parsing") can
> > > be reverted afterward? I think it makes tmp_result redundant.
> > > 
> > > Wenzhuo, as the author of that commit, can you confirm?
> > > 
> > > Olivier, no problem with breaking the loop immediately after the first
> > > successful match_inst() call instead of the last one? (I don't see why it
> > > would be an issue but I may have missed something)
> > 
> > Moving the break will change the behavior, it will never detect
> > ambiguous commands (i.e when several commands match the same input).
> > So I think we should not do it.
> > 
> > IMO, only the memset() is enough.
> 
> I agree it should be, however as reported by Xueming doing so somehow breaks
> the flow command. In my previous reply I assumed that was caused by clearing
> the result buffer of prior successful calls in cmdline_parse(), I just
> checked and it appears not to be the case. Wenzhuo's patch works fine.
> 
> The root cause is actually the flow command stores internal buffer addresses
> in the output buffer, which happens to be tmp_result.buf since commit
> 9b3fbb051d2e.
> 
> When match_inst() returns successfully, tmp_result.buf is copied to
> result.buf and the contents of tmp_result.buf are discarded by the next call
> to match_inst(). Addresses stored inside result.buf still refer to locations
> inside tmp_result.buf, memset()'ing that region only makes that bug manifest
> itself.
> 
> Another suggestion to address the underlying issue before adding memset():
> 
> diff --git a/lib/librte_cmdline/cmdline_parse.c b/lib/librte_cmdline/cmdline_parse.c
> index 205f243..15a3482 100644
> --- a/lib/librte_cmdline/cmdline_parse.c
> +++ b/lib/librte_cmdline/cmdline_parse.c
> @@ -254,7 +254,7 @@ cmdline_parse(struct cmdline *cl, const char * buf)
>  	union {
>  		char buf[CMDLINE_PARSE_RESULT_BUFSIZE];
>  		long double align; /* strong alignment constraint for buf */
> -	} result, tmp_result;
> +	} result, result_ok;
>  	void (*f)(void *, struct cmdline *, void *) = NULL;
>  	void *data = NULL;
>  	int comment = 0;
> @@ -315,16 +315,13 @@ cmdline_parse(struct cmdline *cl, const char * buf)
>  		debug_printf("INST %d\n", inst_num);
>  
>  		/* fully parsed */
> -		tok = match_inst(inst, buf, 0, tmp_result.buf,
> -				 sizeof(tmp_result.buf));
> +		tok = match_inst(inst, buf, 0, result.buf, sizeof(result.buf));
>  
>  		if (tok > 0) /* we matched at least one token */
>  			err = CMDLINE_PARSE_BAD_ARGS;
>  
>  		else if (!tok) {
>  			debug_printf("INST fully parsed\n");
> -			memcpy(&result, &tmp_result,
> -			       sizeof(result));
>  			/* skip spaces */
>  			while (isblank2(*curbuf)) {
>  				curbuf++;
> @@ -344,6 +341,7 @@ cmdline_parse(struct cmdline *cl, const char * buf)
>  					break;
>  				}
>  			}
> +			result_ok = result;
>  		}
>  
>  		inst_num ++;
> @@ -352,6 +350,7 @@ cmdline_parse(struct cmdline *cl, const char * buf)
>  
>  	/* call func */
>  	if (f) {
> +		result = result_ok;
>  		f(result.buf, cl, data);
>  	}
> 

In addition to the memset() at the beginning of match_inst(), it looks
good to me.

A particular attention should be paid to the explanation of the issue
and its solution in the commit log :)

  reply	other threads:[~2017-12-08 15:26 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-15 15:54 [dpdk-dev] [PATCH] lib/cmdline: init parse result memeory Xueming Li
2017-12-07 14:48 ` Olivier MATZ
2017-12-07 15:05   ` Xueming(Steven) Li
2017-12-07 15:35     ` Xueming(Steven) Li
2017-12-07 17:13       ` Adrien Mazarguil
2017-12-08  7:02 ` [dpdk-dev] [PATCH v1] lib/cmdline: init parse result memory Xueming Li
2017-12-08 12:27   ` Adrien Mazarguil
2017-12-08 13:51     ` Olivier MATZ
2017-12-08 14:50       ` Xueming(Steven) Li
2017-12-08 15:04       ` Adrien Mazarguil
2017-12-08 15:26         ` Olivier MATZ [this message]
2017-12-09 15:39 ` [dpdk-dev] [PATCH v2] lib/cmdline: init CLI parsing memory Xueming Li
2017-12-14 15:35   ` Olivier MATZ
2017-12-18 10:51     ` Adrien Mazarguil
2017-12-18 13:44       ` Xueming(Steven) Li
2017-12-26 12:57     ` Xueming(Steven) Li
2018-01-16 12:45       ` Olivier Matz
2018-01-18  4:29         ` Xueming(Steven) Li
2018-01-19  9:07           ` Olivier Matz
2018-01-19 18:18             ` Xueming(Steven) Li
2018-01-19 18:16 ` [dpdk-dev] [PATCH v3] cmdline: fix dynamic tokens parsing Xueming Li
2018-01-22 13:13   ` Olivier Matz
2018-01-25 22:14     ` [dpdk-dev] [dpdk-stable] " 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=20171208152612.75nttsciba3imn6x@platinum \
    --to=olivier.matz@6wind.com \
    --cc=adrien.mazarguil@6wind.com \
    --cc=dev@dpdk.org \
    --cc=wenzhuo.lu@intel.com \
    --cc=xuemingl@mellanox.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).