DPDK patches and discussions
 help / color / mirror / Atom feed
From: Adrien Mazarguil <adrien.mazarguil@6wind.com>
To: Olivier MATZ <olivier.matz@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:04:33 +0100	[thread overview]
Message-ID: <20171208150433.GU4062@6wind.com> (raw)
In-Reply-To: <20171208135114.wzkoidddxudbzyuy@platinum>

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

-- 
Adrien Mazarguil
6WIND

  parent reply	other threads:[~2017-12-08 15:04 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 [this message]
2017-12-08 15:26         ` Olivier MATZ
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=20171208150433.GU4062@6wind.com \
    --to=adrien.mazarguil@6wind.com \
    --cc=dev@dpdk.org \
    --cc=olivier.matz@6wind.com \
    --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).