DPDK patches and discussions
 help / color / mirror / Atom feed
* [dpdk-dev] [PATCH] app/test-compress-perf: fix improper use of negative value
@ 2019-05-20 13:26 Tomasz Jozwiak
  2019-05-20 13:26 ` [dpdk-dev] [PATCH] app/test-compress-perf: fix reliance on integer endianness Tomasz Jozwiak
  2019-05-20 13:39 ` [dpdk-dev] [PATCH] app/test-compress-perf: fix improper use of negative value Trahe, Fiona
  0 siblings, 2 replies; 11+ messages in thread
From: Tomasz Jozwiak @ 2019-05-20 13:26 UTC (permalink / raw)
  To: dev, fiona.trahe, tomaszx.jozwiak, shallyv, stable

This patch fixes coverity issue: Improper use of negative value.
test_data->input_data_sz is passed to a parameter that
cannot be negative.

Coverity issue: 328504
Fixes: b68a82425da4 ("app/compress-perf: add performance measurement")
Cc: stable@dpdk.org

Signed-off-by: Tomasz Jozwiak <tomaszx.jozwiak@intel.com>
---
 app/test-compress-perf/main.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/app/test-compress-perf/main.c b/app/test-compress-perf/main.c
index c2a45d1..5a579ea 100644
--- a/app/test-compress-perf/main.c
+++ b/app/test-compress-perf/main.c
@@ -244,7 +244,8 @@ comp_perf_dump_input_data(struct comp_test_data *test_data)
 	if (test_data->input_data_sz == 0)
 		test_data->input_data_sz = actual_file_sz;
 
-	if (fseek(f, 0, SEEK_SET) != 0) {
+	if (test_data->input_data_sz <= 0 || actual_file_sz <= 0 ||
+			fseek(f, 0, SEEK_SET) != 0) {
 		RTE_LOG(ERR, USER1, "Size of input could not be calculated\n");
 		goto end;
 	}
-- 
2.7.4


^ permalink raw reply	[flat|nested] 11+ messages in thread

* [dpdk-dev] [PATCH] app/test-compress-perf: fix reliance on integer endianness
  2019-05-20 13:26 [dpdk-dev] [PATCH] app/test-compress-perf: fix improper use of negative value Tomasz Jozwiak
@ 2019-05-20 13:26 ` Tomasz Jozwiak
  2019-05-20 14:05   ` Trahe, Fiona
  2019-05-20 13:39 ` [dpdk-dev] [PATCH] app/test-compress-perf: fix improper use of negative value Trahe, Fiona
  1 sibling, 1 reply; 11+ messages in thread
From: Tomasz Jozwiak @ 2019-05-20 13:26 UTC (permalink / raw)
  To: dev, fiona.trahe, tomaszx.jozwiak, shallyv, stable

This patch fixes coverity issue:
Reliance on integer endianness (INCOMPATIBLE_CAST)
in parse_window_sz function.

Coverity issue: 328524
Fixes: e0b6287c035d ("app/compress-perf: add parser")
Cc: stable@dpdk.org

Signed-off-by: Tomasz Jozwiak <tomaszx.jozwiak@intel.com>
---
 app/test-compress-perf/comp_perf_options_parse.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/app/test-compress-perf/comp_perf_options_parse.c b/app/test-compress-perf/comp_perf_options_parse.c
index 2fb6fb4..56ca580 100644
--- a/app/test-compress-perf/comp_perf_options_parse.c
+++ b/app/test-compress-perf/comp_perf_options_parse.c
@@ -364,13 +364,15 @@ parse_max_num_sgl_segs(struct comp_test_data *test_data, const char *arg)
 static int
 parse_window_sz(struct comp_test_data *test_data, const char *arg)
 {
-	int ret = parse_uint16_t((uint16_t *)&test_data->window_sz, arg);
+	uint16_t tmp;
+	int ret = parse_uint16_t(&tmp, arg);
 
 	if (ret) {
 		RTE_LOG(ERR, USER1, "Failed to parse window size\n");
 		return -1;
 	}
 
+	test_data->window_sz = (int)tmp;
 	return 0;
 }
 
-- 
2.7.4


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [PATCH] app/test-compress-perf: fix improper use of negative value
  2019-05-20 13:26 [dpdk-dev] [PATCH] app/test-compress-perf: fix improper use of negative value Tomasz Jozwiak
  2019-05-20 13:26 ` [dpdk-dev] [PATCH] app/test-compress-perf: fix reliance on integer endianness Tomasz Jozwiak
@ 2019-05-20 13:39 ` Trahe, Fiona
  2019-06-19 14:55   ` Akhil Goyal
  1 sibling, 1 reply; 11+ messages in thread
From: Trahe, Fiona @ 2019-05-20 13:39 UTC (permalink / raw)
  To: Jozwiak, TomaszX, dev, shallyv, stable


> -----Original Message-----
> From: Jozwiak, TomaszX
> Sent: Monday, May 20, 2019 2:26 PM
> To: dev@dpdk.org; Trahe, Fiona <fiona.trahe@intel.com>; Jozwiak, TomaszX
> <tomaszx.jozwiak@intel.com>; shallyv@marvell.com; stable@dpdk.org
> Subject: [PATCH] app/test-compress-perf: fix improper use of negative value
> 
> This patch fixes coverity issue: Improper use of negative value.
> test_data->input_data_sz is passed to a parameter that
> cannot be negative.
> 
> Coverity issue: 328504
> Fixes: b68a82425da4 ("app/compress-perf: add performance measurement")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Tomasz Jozwiak <tomaszx.jozwiak@intel.com>
Acked-by: Fiona Trahe <fiona.trahe@intel.com>


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [PATCH] app/test-compress-perf: fix reliance on integer endianness
  2019-05-20 13:26 ` [dpdk-dev] [PATCH] app/test-compress-perf: fix reliance on integer endianness Tomasz Jozwiak
@ 2019-05-20 14:05   ` Trahe, Fiona
  2019-05-20 14:25     ` Jozwiak, TomaszX
  2019-05-21  6:47     ` Jozwiak, TomaszX
  0 siblings, 2 replies; 11+ messages in thread
From: Trahe, Fiona @ 2019-05-20 14:05 UTC (permalink / raw)
  To: Jozwiak, TomaszX, dev, shallyv, stable; +Cc: Trahe, Fiona, Trybula, ArturX

HI Tomasz,

> -----Original Message-----
> From: Jozwiak, TomaszX
> Sent: Monday, May 20, 2019 2:26 PM
> To: dev@dpdk.org; Trahe, Fiona <fiona.trahe@intel.com>; Jozwiak, TomaszX
> <tomaszx.jozwiak@intel.com>; shallyv@marvell.com; stable@dpdk.org
> Subject: [PATCH] app/test-compress-perf: fix reliance on integer endianness
> 
> This patch fixes coverity issue:
> Reliance on integer endianness (INCOMPATIBLE_CAST)
> in parse_window_sz function.
> 
> Coverity issue: 328524
> Fixes: e0b6287c035d ("app/compress-perf: add parser")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Tomasz Jozwiak <tomaszx.jozwiak@intel.com>
> ---
>  app/test-compress-perf/comp_perf_options_parse.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/app/test-compress-perf/comp_perf_options_parse.c b/app/test-compress-
> perf/comp_perf_options_parse.c
> index 2fb6fb4..56ca580 100644
> --- a/app/test-compress-perf/comp_perf_options_parse.c
> +++ b/app/test-compress-perf/comp_perf_options_parse.c
> @@ -364,13 +364,15 @@ parse_max_num_sgl_segs(struct comp_test_data *test_data, const char *arg)
>  static int
>  parse_window_sz(struct comp_test_data *test_data, const char *arg)
>  {
> -	int ret = parse_uint16_t((uint16_t *)&test_data->window_sz, arg);
> +	uint16_t tmp;
> +	int ret = parse_uint16_t(&tmp, arg);
> 
>  	if (ret) {
>  		RTE_LOG(ERR, USER1, "Failed to parse window size\n");
>  		return -1;
>  	}
> 
> +	test_data->window_sz = (int)tmp;
>  	return 0;
>  }
[Fiona] I expect this fixes this coverity issue - but will it result in another one?
window_sz on the xform is uint8_t - so this int will get truncated later, and there's no cast done at that point.
Would it be better to add a new parse_uint8_t fn and change test-data->window_sz to a unit8_t?
Or add that cast?


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [PATCH] app/test-compress-perf: fix reliance on integer endianness
  2019-05-20 14:05   ` Trahe, Fiona
@ 2019-05-20 14:25     ` Jozwiak, TomaszX
  2019-05-21  6:47     ` Jozwiak, TomaszX
  1 sibling, 0 replies; 11+ messages in thread
From: Jozwiak, TomaszX @ 2019-05-20 14:25 UTC (permalink / raw)
  To: Trahe, Fiona, dev, shallyv, stable; +Cc: Trybula, ArturX

Hi Fiona,

> -----Original Message-----
> From: Trahe, Fiona
> Sent: Monday, May 20, 2019 4:06 PM
> To: Jozwiak, TomaszX <tomaszx.jozwiak@intel.com>; dev@dpdk.org;
> shallyv@marvell.com; stable@dpdk.org
> Cc: Trahe, Fiona <fiona.trahe@intel.com>; Trybula, ArturX
> <arturx.trybula@intel.com>
> Subject: RE: [PATCH] app/test-compress-perf: fix reliance on integer
> endianness
> 
> HI Tomasz,
> 
> > -----Original Message-----
> > From: Jozwiak, TomaszX
> > Sent: Monday, May 20, 2019 2:26 PM
> > To: dev@dpdk.org; Trahe, Fiona <fiona.trahe@intel.com>; Jozwiak,
> > TomaszX <tomaszx.jozwiak@intel.com>; shallyv@marvell.com;
> > stable@dpdk.org
> > Subject: [PATCH] app/test-compress-perf: fix reliance on integer
> > endianness
> >
> > This patch fixes coverity issue:
> > Reliance on integer endianness (INCOMPATIBLE_CAST) in
> parse_window_sz
> > function.
> >
> > Coverity issue: 328524
> > Fixes: e0b6287c035d ("app/compress-perf: add parser")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: Tomasz Jozwiak <tomaszx.jozwiak@intel.com>
> > ---
> >  app/test-compress-perf/comp_perf_options_parse.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/app/test-compress-perf/comp_perf_options_parse.c
> > b/app/test-compress- perf/comp_perf_options_parse.c index
> > 2fb6fb4..56ca580 100644
> > --- a/app/test-compress-perf/comp_perf_options_parse.c
> > +++ b/app/test-compress-perf/comp_perf_options_parse.c
> > @@ -364,13 +364,15 @@ parse_max_num_sgl_segs(struct
> comp_test_data
> > *test_data, const char *arg)  static int  parse_window_sz(struct
> > comp_test_data *test_data, const char *arg)  {
> > -	int ret = parse_uint16_t((uint16_t *)&test_data->window_sz, arg);
> > +	uint16_t tmp;
> > +	int ret = parse_uint16_t(&tmp, arg);
> >
> >  	if (ret) {
> >  		RTE_LOG(ERR, USER1, "Failed to parse window size\n");
> >  		return -1;
> >  	}
> >
> > +	test_data->window_sz = (int)tmp;
> >  	return 0;
> >  }
> [Fiona] I expect this fixes this coverity issue - but will it result in another one?
> window_sz on the xform is uint8_t - so this int will get truncated later, and
> there's no cast done at that point.
> Would it be better to add a new parse_uint8_t fn and change test-data-
> >window_sz to a unit8_t?
> Or add that cast?
> [Tomek] I measn it's ok. There's a check inside comp_perf_check_capabilities function. If the value from test_data->window_sz > cap->window_size we have a fail. Also during parsing there's a check is value from command line is between 0 and UINT16_MAX, so in my opinion all cases are tested. The point is there's only one place where we're parsing uint8_t value.  parse_uint8_t function will be especially for that.






^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [PATCH] app/test-compress-perf: fix reliance on integer endianness
  2019-05-20 14:05   ` Trahe, Fiona
  2019-05-20 14:25     ` Jozwiak, TomaszX
@ 2019-05-21  6:47     ` Jozwiak, TomaszX
  2019-05-21  8:03       ` Shally Verma
  1 sibling, 1 reply; 11+ messages in thread
From: Jozwiak, TomaszX @ 2019-05-21  6:47 UTC (permalink / raw)
  To: Trahe, Fiona, dev, shallyv, stable; +Cc: Trybula, ArturX

Hi Fiona,

Outlook issue :D  , so once again

> -----Original Message-----
> From: Trahe, Fiona
> Sent: Monday, May 20, 2019 4:06 PM
> To: Jozwiak, TomaszX <tomaszx.jozwiak@intel.com>; dev@dpdk.org;
> shallyv@marvell.com; stable@dpdk.org
> Cc: Trahe, Fiona <fiona.trahe@intel.com>; Trybula, ArturX
> <arturx.trybula@intel.com>
> Subject: RE: [PATCH] app/test-compress-perf: fix reliance on integer
> endianness
> 
> HI Tomasz,
> 
> > -----Original Message-----
> > From: Jozwiak, TomaszX
> > Sent: Monday, May 20, 2019 2:26 PM
> > To: dev@dpdk.org; Trahe, Fiona <fiona.trahe@intel.com>; Jozwiak,
> > TomaszX <tomaszx.jozwiak@intel.com>; shallyv@marvell.com;
> > stable@dpdk.org
> > Subject: [PATCH] app/test-compress-perf: fix reliance on integer
> > endianness
> >
> > This patch fixes coverity issue:
> > Reliance on integer endianness (INCOMPATIBLE_CAST) in
> parse_window_sz
> > function.
> >
> > Coverity issue: 328524
> > Fixes: e0b6287c035d ("app/compress-perf: add parser")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: Tomasz Jozwiak <tomaszx.jozwiak@intel.com>
> > ---
> >  app/test-compress-perf/comp_perf_options_parse.c | 4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/app/test-compress-perf/comp_perf_options_parse.c
> > b/app/test-compress- perf/comp_perf_options_parse.c index
> > 2fb6fb4..56ca580 100644
> > --- a/app/test-compress-perf/comp_perf_options_parse.c
> > +++ b/app/test-compress-perf/comp_perf_options_parse.c
> > @@ -364,13 +364,15 @@ parse_max_num_sgl_segs(struct
> comp_test_data
> > *test_data, const char *arg)  static int  parse_window_sz(struct
> > comp_test_data *test_data, const char *arg)  {
> > -	int ret = parse_uint16_t((uint16_t *)&test_data->window_sz, arg);
> > +	uint16_t tmp;
> > +	int ret = parse_uint16_t(&tmp, arg);
> >
> >  	if (ret) {
> >  		RTE_LOG(ERR, USER1, "Failed to parse window size\n");
> >  		return -1;
> >  	}
> >
> > +	test_data->window_sz = (int)tmp;
> >  	return 0;
> >  }
> [Fiona] I expect this fixes this coverity issue - but will it result in another one?
> window_sz on the xform is uint8_t - so this int will get truncated later, and
> there's no cast done at that point.
> Would it be better to add a new parse_uint8_t fn and change test-data-
> >window_sz to a unit8_t?
> Or add that cast?
[Tomek] I measn it's ok. There's a check inside comp_perf_check_capabilities function.
If the value from test_data->window_sz > cap->window_size we have a fail.
Also during parsing there's a check is value from command line between 0 and UINT16_MAX,
so in my opinion all cases are tested. The point is there's only one place where
we're parsing uint8_t value.  parse_uint8_t function will be especially for that.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [PATCH] app/test-compress-perf: fix reliance on integer endianness
  2019-05-21  6:47     ` Jozwiak, TomaszX
@ 2019-05-21  8:03       ` Shally Verma
  2019-05-21  8:47         ` Jozwiak, TomaszX
  0 siblings, 1 reply; 11+ messages in thread
From: Shally Verma @ 2019-05-21  8:03 UTC (permalink / raw)
  To: Jozwiak, TomaszX, Trahe, Fiona, dev, stable; +Cc: Trybula, ArturX

HI Tomasz

> -----Original Message-----
> From: Jozwiak, TomaszX <tomaszx.jozwiak@intel.com>
> Sent: Tuesday, May 21, 2019 12:18 PM
> To: Trahe, Fiona <fiona.trahe@intel.com>; dev@dpdk.org; Shally Verma
> <shallyv@marvell.com>; stable@dpdk.org
> Cc: Trybula, ArturX <arturx.trybula@intel.com>
> Subject: [EXT] RE: [PATCH] app/test-compress-perf: fix reliance on integer
> endianness
> 
> External Email
> 
> ----------------------------------------------------------------------
> Hi Fiona,
> 
> Outlook issue :D  , so once again
> 
> > -----Original Message-----
> > From: Trahe, Fiona
> > Sent: Monday, May 20, 2019 4:06 PM
> > To: Jozwiak, TomaszX <tomaszx.jozwiak@intel.com>; dev@dpdk.org;
> > shallyv@marvell.com; stable@dpdk.org
> > Cc: Trahe, Fiona <fiona.trahe@intel.com>; Trybula, ArturX
> > <arturx.trybula@intel.com>
> > Subject: RE: [PATCH] app/test-compress-perf: fix reliance on integer
> > endianness
> >
> > HI Tomasz,
> >
> > > -----Original Message-----
> > > From: Jozwiak, TomaszX
> > > Sent: Monday, May 20, 2019 2:26 PM
> > > To: dev@dpdk.org; Trahe, Fiona <fiona.trahe@intel.com>; Jozwiak,
> > > TomaszX <tomaszx.jozwiak@intel.com>; shallyv@marvell.com;
> > > stable@dpdk.org
> > > Subject: [PATCH] app/test-compress-perf: fix reliance on integer
> > > endianness
> > >
> > > This patch fixes coverity issue:
> > > Reliance on integer endianness (INCOMPATIBLE_CAST) in
> > parse_window_sz
> > > function.
> > >
> > > Coverity issue: 328524
> > > Fixes: e0b6287c035d ("app/compress-perf: add parser")
> > > Cc: stable@dpdk.org
> > >
> > > Signed-off-by: Tomasz Jozwiak <tomaszx.jozwiak@intel.com>
> > > ---
> > >  app/test-compress-perf/comp_perf_options_parse.c | 4 +++-
> > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/app/test-compress-perf/comp_perf_options_parse.c
> > > b/app/test-compress- perf/comp_perf_options_parse.c index
> > > 2fb6fb4..56ca580 100644
> > > --- a/app/test-compress-perf/comp_perf_options_parse.c
> > > +++ b/app/test-compress-perf/comp_perf_options_parse.c
> > > @@ -364,13 +364,15 @@ parse_max_num_sgl_segs(struct
> > comp_test_data
> > > *test_data, const char *arg)  static int  parse_window_sz(struct
> > > comp_test_data *test_data, const char *arg)  {
> > > -	int ret = parse_uint16_t((uint16_t *)&test_data->window_sz, arg);
> > > +	uint16_t tmp;
> > > +	int ret = parse_uint16_t(&tmp, arg);
> > >
> > >  	if (ret) {
> > >  		RTE_LOG(ERR, USER1, "Failed to parse window size\n");
> > >  		return -1;
> > >  	}
> > >
> > > +	test_data->window_sz = (int)tmp;
> > >  	return 0;
> > >  }
> > [Fiona] I expect this fixes this coverity issue - but will it result in another one?
> > window_sz on the xform is uint8_t - so this int will get truncated
> > later, and there's no cast done at that point.
> > Would it be better to add a new parse_uint8_t fn and change test-data-
> > >window_sz to a unit8_t?
> > Or add that cast?
> [Tomek] I measn it's ok. There's a check inside comp_perf_check_capabilities
> function.
> If the value from test_data->window_sz > cap->window_size we have a fail.
> Also during parsing there's a check is value from command line between 0 and
> UINT16_MAX, so in my opinion all cases are tested. The point is there's only
> one place where we're parsing uint8_t value.  parse_uint8_t function will be
> especially for that.
[Shally] What is window_sz in test data ?is it base 2 log of (actual window length) or actual window length in bytes? lib spec mention this as struct rte_param_log2_range, so
If test window size is actual window length in bytes then I assume test perf should check for test_data->window_sz > 2 pow cap->window_size but that doesn't look like the case. 
So if it is log value, then coding wise typecasting here doesn't look right. Though it add need for extra function to parse_uint8, but that looks like cleaner approach to use.


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [PATCH] app/test-compress-perf: fix reliance on integer endianness
  2019-05-21  8:03       ` Shally Verma
@ 2019-05-21  8:47         ` Jozwiak, TomaszX
  2019-05-29 13:46           ` Trahe, Fiona
  0 siblings, 1 reply; 11+ messages in thread
From: Jozwiak, TomaszX @ 2019-05-21  8:47 UTC (permalink / raw)
  To: Shally Verma, Trahe, Fiona, dev, stable; +Cc: Trybula, ArturX

Hi Shally

> -----Original Message-----
> From: Shally Verma [mailto:shallyv@marvell.com]
> Sent: Tuesday, May 21, 2019 10:04 AM
> To: Jozwiak, TomaszX <tomaszx.jozwiak@intel.com>; Trahe, Fiona
> <fiona.trahe@intel.com>; dev@dpdk.org; stable@dpdk.org
> Cc: Trybula, ArturX <arturx.trybula@intel.com>
> Subject: RE: [PATCH] app/test-compress-perf: fix reliance on integer
> endianness
> 
> HI Tomasz
> 
> > -----Original Message-----
> > From: Jozwiak, TomaszX <tomaszx.jozwiak@intel.com>
> > Sent: Tuesday, May 21, 2019 12:18 PM
> > To: Trahe, Fiona <fiona.trahe@intel.com>; dev@dpdk.org; Shally Verma
> > <shallyv@marvell.com>; stable@dpdk.org
> > Cc: Trybula, ArturX <arturx.trybula@intel.com>
> > Subject: [EXT] RE: [PATCH] app/test-compress-perf: fix reliance on
> > integer endianness
> >
> > External Email
> >
> > ----------------------------------------------------------------------
> > Hi Fiona,
> >
> > Outlook issue :D  , so once again
> >
> > > -----Original Message-----
> > > From: Trahe, Fiona
> > > Sent: Monday, May 20, 2019 4:06 PM
> > > To: Jozwiak, TomaszX <tomaszx.jozwiak@intel.com>; dev@dpdk.org;
> > > shallyv@marvell.com; stable@dpdk.org
> > > Cc: Trahe, Fiona <fiona.trahe@intel.com>; Trybula, ArturX
> > > <arturx.trybula@intel.com>
> > > Subject: RE: [PATCH] app/test-compress-perf: fix reliance on integer
> > > endianness
> > >
> > > HI Tomasz,
> > >
> > > > -----Original Message-----
> > > > From: Jozwiak, TomaszX
> > > > Sent: Monday, May 20, 2019 2:26 PM
> > > > To: dev@dpdk.org; Trahe, Fiona <fiona.trahe@intel.com>; Jozwiak,
> > > > TomaszX <tomaszx.jozwiak@intel.com>; shallyv@marvell.com;
> > > > stable@dpdk.org
> > > > Subject: [PATCH] app/test-compress-perf: fix reliance on integer
> > > > endianness
> > > >
> > > > This patch fixes coverity issue:
> > > > Reliance on integer endianness (INCOMPATIBLE_CAST) in
> > > parse_window_sz
> > > > function.
> > > >
> > > > Coverity issue: 328524
> > > > Fixes: e0b6287c035d ("app/compress-perf: add parser")
> > > > Cc: stable@dpdk.org
> > > >
> > > > Signed-off-by: Tomasz Jozwiak <tomaszx.jozwiak@intel.com>
> > > > ---
> > > >  app/test-compress-perf/comp_perf_options_parse.c | 4 +++-
> > > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/app/test-compress-perf/comp_perf_options_parse.c
> > > > b/app/test-compress- perf/comp_perf_options_parse.c index
> > > > 2fb6fb4..56ca580 100644
> > > > --- a/app/test-compress-perf/comp_perf_options_parse.c
> > > > +++ b/app/test-compress-perf/comp_perf_options_parse.c
> > > > @@ -364,13 +364,15 @@ parse_max_num_sgl_segs(struct
> > > comp_test_data
> > > > *test_data, const char *arg)  static int  parse_window_sz(struct
> > > > comp_test_data *test_data, const char *arg)  {
> > > > -	int ret = parse_uint16_t((uint16_t *)&test_data->window_sz, arg);
> > > > +	uint16_t tmp;
> > > > +	int ret = parse_uint16_t(&tmp, arg);
> > > >
> > > >  	if (ret) {
> > > >  		RTE_LOG(ERR, USER1, "Failed to parse window size\n");
> > > >  		return -1;
> > > >  	}
> > > >
> > > > +	test_data->window_sz = (int)tmp;
> > > >  	return 0;
> > > >  }
> > > [Fiona] I expect this fixes this coverity issue - but will it result in another
> one?
> > > window_sz on the xform is uint8_t - so this int will get truncated
> > > later, and there's no cast done at that point.
> > > Would it be better to add a new parse_uint8_t fn and change
> > > test-data-
> > > >window_sz to a unit8_t?
> > > Or add that cast?
> > [Tomek] I measn it's ok. There's a check inside
> > comp_perf_check_capabilities function.
> > If the value from test_data->window_sz > cap->window_size we have a
> fail.
> > Also during parsing there's a check is value from command line between
> > 0 and UINT16_MAX, so in my opinion all cases are tested. The point is
> > there's only one place where we're parsing uint8_t value.
> > parse_uint8_t function will be especially for that.
> [Shally] What is window_sz in test data ?is it base 2 log of (actual window
> length) or actual window length in bytes? lib spec mention this as struct
> rte_param_log2_range, so If test window size is actual window length in
> bytes then I assume test perf should check for test_data->window_sz > 2
> pow cap->window_size but that doesn't look like the case.
> So if it is log value, then coding wise typecasting here doesn't look right.
> Though it add need for extra function to parse_uint8, but that looks like
> cleaner approach to use.
[Tomek] I mean it's log 2  (please take a look at help usage function in comp_perf_options_parse.c:37

" --window-sz N: base two log value of compression window size\n"
		"		(e.g.: 15 => 32k, default: max supported by PMD)\n"

I mean it's ok, still. We have many types in command line and can be much more in the future. The idea is to parse them into a sort of common range value first ( it should be max range for all digital command line options - in our case there's uint16 or uint32_t) even if it's shorter like uint8_t or etc. We store these values in comp_test_data structure first. Next we check the ranges each of them. In case of window_sz this test is in comp_perf_check_capabilities function. That approach reduce a  set of parsing functions we needed. Of course we can create separate parsing function for each of command line type value, but is this really needed ? :D
Please let me know your thoughts - if this new parsing function will clear the code - I'll add this in v2







^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [PATCH] app/test-compress-perf: fix reliance on integer endianness
  2019-05-21  8:47         ` Jozwiak, TomaszX
@ 2019-05-29 13:46           ` Trahe, Fiona
  2019-06-03 13:44             ` Shally Verma
  0 siblings, 1 reply; 11+ messages in thread
From: Trahe, Fiona @ 2019-05-29 13:46 UTC (permalink / raw)
  To: Jozwiak, TomaszX, Shally Verma, dev, stable; +Cc: Trybula, ArturX, Trahe, Fiona

Hi Shally, Tomasz,

> > > > > -----Original Message-----
> > > > > From: Jozwiak, TomaszX
> > > > > Sent: Monday, May 20, 2019 2:26 PM
> > > > > To: dev@dpdk.org; Trahe, Fiona <fiona.trahe@intel.com>; Jozwiak,
> > > > > TomaszX <tomaszx.jozwiak@intel.com>; shallyv@marvell.com;
> > > > > stable@dpdk.org
> > > > > Subject: [PATCH] app/test-compress-perf: fix reliance on integer
> > > > > endianness
> > > > >
> > > > > This patch fixes coverity issue:
> > > > > Reliance on integer endianness (INCOMPATIBLE_CAST) in
> > > > parse_window_sz
> > > > > function.
> > > > >
> > > > > Coverity issue: 328524
> > > > > Fixes: e0b6287c035d ("app/compress-perf: add parser")
> > > > > Cc: stable@dpdk.org
> > > > >
> > > > > Signed-off-by: Tomasz Jozwiak <tomaszx.jozwiak@intel.com>
> > > > > ---
> > > > >  app/test-compress-perf/comp_perf_options_parse.c | 4 +++-
> > > > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/app/test-compress-perf/comp_perf_options_parse.c
> > > > > b/app/test-compress- perf/comp_perf_options_parse.c index
> > > > > 2fb6fb4..56ca580 100644
> > > > > --- a/app/test-compress-perf/comp_perf_options_parse.c
> > > > > +++ b/app/test-compress-perf/comp_perf_options_parse.c
> > > > > @@ -364,13 +364,15 @@ parse_max_num_sgl_segs(struct
> > > > comp_test_data
> > > > > *test_data, const char *arg)  static int  parse_window_sz(struct
> > > > > comp_test_data *test_data, const char *arg)  {
> > > > > -	int ret = parse_uint16_t((uint16_t *)&test_data->window_sz, arg);
> > > > > +	uint16_t tmp;
> > > > > +	int ret = parse_uint16_t(&tmp, arg);
> > > > >
> > > > >  	if (ret) {
> > > > >  		RTE_LOG(ERR, USER1, "Failed to parse window size\n");
> > > > >  		return -1;
> > > > >  	}
> > > > >
> > > > > +	test_data->window_sz = (int)tmp;
> > > > >  	return 0;
> > > > >  }
> > > > [Fiona] I expect this fixes this coverity issue - but will it result in another
> > one?
> > > > window_sz on the xform is uint8_t - so this int will get truncated
> > > > later, and there's no cast done at that point.
> > > > Would it be better to add a new parse_uint8_t fn and change
> > > > test-data-
> > > > >window_sz to a unit8_t?
> > > > Or add that cast?
> > > [Tomek] I measn it's ok. There's a check inside
> > > comp_perf_check_capabilities function.
> > > If the value from test_data->window_sz > cap->window_size we have a
> > fail.
> > > Also during parsing there's a check is value from command line between
> > > 0 and UINT16_MAX, so in my opinion all cases are tested. The point is
> > > there's only one place where we're parsing uint8_t value.
> > > parse_uint8_t function will be especially for that.
> > [Shally] What is window_sz in test data ?is it base 2 log of (actual window
> > length) or actual window length in bytes? lib spec mention this as struct
> > rte_param_log2_range, so If test window size is actual window length in
> > bytes then I assume test perf should check for test_data->window_sz > 2
> > pow cap->window_size but that doesn't look like the case.
> > So if it is log value, then coding wise typecasting here doesn't look right.
> > Though it add need for extra function to parse_uint8, but that looks like
> > cleaner approach to use.
> [Tomek] I mean it's log 2  (please take a look at help usage function in comp_perf_options_parse.c:37
> 
> " --window-sz N: base two log value of compression window size\n"
> 		"		(e.g.: 15 => 32k, default: max supported by PMD)\n"
> 
> I mean it's ok, still. We have many types in command line and can be much more in the future. The idea
> is to parse them into a sort of common range value first ( it should be max range for all digital command
> line options - in our case there's uint16 or uint32_t) even if it's shorter like uint8_t or etc. We store
> these values in comp_test_data structure first. Next we check the ranges each of them. In case of
> window_sz this test is in comp_perf_check_capabilities function. That approach reduce a  set of parsing
> functions we needed. Of course we can create separate parsing function for each of command line type
> value, but is this really needed ? :D
> Please let me know your thoughts - if this new parsing function will clear the code - I'll add this in v2
[Fiona] ok, I reviewed again and see I'd misunderstood.
The param being parsed is intentionally not being stored in test_data struct as uint8_t, but as
an int because it uses -1 as a default value. And there are range checks on the input, so an invalid value will never be passed to the PMD.  
So I'm ok with the fix as is - it resolves the coverity issues reported on the param parsing.

However there's a second issue, which coverity is likely to throw up after the above fix is applied - when
the test_data value is later passed to the PMD, it should have a cast from int to unit8_t. 
But that's a separate issue, not referred to by this coverity report, so we'll send a separate patch for it.
@Shally, are you ok with this?


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [PATCH] app/test-compress-perf: fix reliance on integer endianness
  2019-05-29 13:46           ` Trahe, Fiona
@ 2019-06-03 13:44             ` Shally Verma
  0 siblings, 0 replies; 11+ messages in thread
From: Shally Verma @ 2019-06-03 13:44 UTC (permalink / raw)
  To: Trahe, Fiona, Jozwiak, TomaszX, dev, stable; +Cc: Trybula, ArturX



> -----Original Message-----
> From: Trahe, Fiona <fiona.trahe@intel.com>
> Sent: Wednesday, May 29, 2019 7:17 PM
> To: Jozwiak, TomaszX <tomaszx.jozwiak@intel.com>; Shally Verma
> <shallyv@marvell.com>; dev@dpdk.org; stable@dpdk.org
> Cc: Trybula, ArturX <arturx.trybula@intel.com>; Trahe, Fiona
> <fiona.trahe@intel.com>
> Subject: [EXT] RE: [PATCH] app/test-compress-perf: fix reliance on integer
> endianness
> 
> External Email
> 
> ----------------------------------------------------------------------
> Hi Shally, Tomasz,
> 
> > > > > > -----Original Message-----
> > > > > > From: Jozwiak, TomaszX
> > > > > > Sent: Monday, May 20, 2019 2:26 PM
> > > > > > To: dev@dpdk.org; Trahe, Fiona <fiona.trahe@intel.com>;
> > > > > > Jozwiak, TomaszX <tomaszx.jozwiak@intel.com>;
> > > > > > shallyv@marvell.com; stable@dpdk.org
> > > > > > Subject: [PATCH] app/test-compress-perf: fix reliance on
> > > > > > integer endianness
> > > > > >
> > > > > > This patch fixes coverity issue:
> > > > > > Reliance on integer endianness (INCOMPATIBLE_CAST) in
> > > > > parse_window_sz
> > > > > > function.
> > > > > >
> > > > > > Coverity issue: 328524
> > > > > > Fixes: e0b6287c035d ("app/compress-perf: add parser")
> > > > > > Cc: stable@dpdk.org
> > > > > >
> > > > > > Signed-off-by: Tomasz Jozwiak <tomaszx.jozwiak@intel.com>
> > > > > > ---
> > > > > >  app/test-compress-perf/comp_perf_options_parse.c | 4 +++-
> > > > > >  1 file changed, 3 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/app/test-compress-perf/comp_perf_options_parse.c
> > > > > > b/app/test-compress- perf/comp_perf_options_parse.c index
> > > > > > 2fb6fb4..56ca580 100644
> > > > > > --- a/app/test-compress-perf/comp_perf_options_parse.c
> > > > > > +++ b/app/test-compress-perf/comp_perf_options_parse.c
> > > > > > @@ -364,13 +364,15 @@ parse_max_num_sgl_segs(struct
> > > > > comp_test_data
> > > > > > *test_data, const char *arg)  static int
> > > > > > parse_window_sz(struct comp_test_data *test_data, const char *arg)
> {
> > > > > > -	int ret = parse_uint16_t((uint16_t *)&test_data->window_sz,
> arg);
> > > > > > +	uint16_t tmp;
> > > > > > +	int ret = parse_uint16_t(&tmp, arg);
> > > > > >
> > > > > >  	if (ret) {
> > > > > >  		RTE_LOG(ERR, USER1, "Failed to parse window
> size\n");
> > > > > >  		return -1;
> > > > > >  	}
> > > > > >
> > > > > > +	test_data->window_sz = (int)tmp;
> > > > > >  	return 0;
> > > > > >  }
> > > > > [Fiona] I expect this fixes this coverity issue - but will it
> > > > > result in another
> > > one?
> > > > > window_sz on the xform is uint8_t - so this int will get
> > > > > truncated later, and there's no cast done at that point.
> > > > > Would it be better to add a new parse_uint8_t fn and change
> > > > > test-data-
> > > > > >window_sz to a unit8_t?
> > > > > Or add that cast?
> > > > [Tomek] I measn it's ok. There's a check inside
> > > > comp_perf_check_capabilities function.
> > > > If the value from test_data->window_sz > cap->window_size we have
> > > > a
> > > fail.
> > > > Also during parsing there's a check is value from command line
> > > > between
> > > > 0 and UINT16_MAX, so in my opinion all cases are tested. The point
> > > > is there's only one place where we're parsing uint8_t value.
> > > > parse_uint8_t function will be especially for that.
> > > [Shally] What is window_sz in test data ?is it base 2 log of (actual
> > > window
> > > length) or actual window length in bytes? lib spec mention this as
> > > struct rte_param_log2_range, so If test window size is actual window
> > > length in bytes then I assume test perf should check for
> > > test_data->window_sz > 2 pow cap->window_size but that doesn't look like
> the case.
> > > So if it is log value, then coding wise typecasting here doesn't look right.
> > > Though it add need for extra function to parse_uint8, but that looks
> > > like cleaner approach to use.
> > [Tomek] I mean it's log 2  (please take a look at help usage function
> > in comp_perf_options_parse.c:37
> >
> > " --window-sz N: base two log value of compression window size\n"
> > 		"		(e.g.: 15 => 32k, default: max supported by
> PMD)\n"
> >
> > I mean it's ok, still. We have many types in command line and can be
> > much more in the future. The idea is to parse them into a sort of
> > common range value first ( it should be max range for all digital
> > command line options - in our case there's uint16 or uint32_t) even if
> > it's shorter like uint8_t or etc. We store these values in
> > comp_test_data structure first. Next we check the ranges each of them.
> > In case of window_sz this test is in comp_perf_check_capabilities
> > function. That approach reduce a  set of parsing functions we needed.
> > Of course we can create separate parsing function for each of command
> > line type value, but is this really needed ? :D Please let me know
> > your thoughts - if this new parsing function will clear the code -
> > I'll add this in v2
> [Fiona] ok, I reviewed again and see I'd misunderstood.
> The param being parsed is intentionally not being stored in test_data struct as
> uint8_t, but as an int because it uses -1 as a default value. And there are range
> checks on the input, so an invalid value will never be passed to the PMD.
> So I'm ok with the fix as is - it resolves the coverity issues reported on the param
> parsing.
> 
> However there's a second issue, which coverity is likely to throw up after the
> above fix is applied - when the test_data value is later passed to the PMD, it
> should have a cast from int to unit8_t.
> But that's a separate issue, not referred to by this coverity report, so we'll send a
> separate patch for it.
> @Shally, are you ok with this?
[Shally] No hard choices here. But why we cant app use 0 as default value instead of -1? It would save us an additional typecast when passing to PMD

Thanks
Shally


^ permalink raw reply	[flat|nested] 11+ messages in thread

* Re: [dpdk-dev] [PATCH] app/test-compress-perf: fix improper use of negative value
  2019-05-20 13:39 ` [dpdk-dev] [PATCH] app/test-compress-perf: fix improper use of negative value Trahe, Fiona
@ 2019-06-19 14:55   ` Akhil Goyal
  0 siblings, 0 replies; 11+ messages in thread
From: Akhil Goyal @ 2019-06-19 14:55 UTC (permalink / raw)
  To: Trahe, Fiona, Jozwiak, TomaszX, dev, shallyv, stable

> >
> > This patch fixes coverity issue: Improper use of negative value.
> > test_data->input_data_sz is passed to a parameter that
> > cannot be negative.
> >
> > Coverity issue: 328504
> > Fixes: b68a82425da4 ("app/compress-perf: add performance measurement")
> > Cc: stable@dpdk.org
> >
> > Signed-off-by: Tomasz Jozwiak <tomaszx.jozwiak@intel.com>
> Acked-by: Fiona Trahe <fiona.trahe@intel.com>

Applied to dpdk-next-crypto

Thanks

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2019-06-19 14:55 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-20 13:26 [dpdk-dev] [PATCH] app/test-compress-perf: fix improper use of negative value Tomasz Jozwiak
2019-05-20 13:26 ` [dpdk-dev] [PATCH] app/test-compress-perf: fix reliance on integer endianness Tomasz Jozwiak
2019-05-20 14:05   ` Trahe, Fiona
2019-05-20 14:25     ` Jozwiak, TomaszX
2019-05-21  6:47     ` Jozwiak, TomaszX
2019-05-21  8:03       ` Shally Verma
2019-05-21  8:47         ` Jozwiak, TomaszX
2019-05-29 13:46           ` Trahe, Fiona
2019-06-03 13:44             ` Shally Verma
2019-05-20 13:39 ` [dpdk-dev] [PATCH] app/test-compress-perf: fix improper use of negative value Trahe, Fiona
2019-06-19 14:55   ` Akhil Goyal

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).