[dpdk-dev] service: fix shifts to operate on 64 bit integers

  This commit fixes shifts to an integer (1 << shift) which
is assumed to be a 32-bit integer. In this case, the shift is
variable and expected to be valid for 64-bit integers. Given that
the expectation to work with 64 bits exists, we must ensure that
the (1 << shift) one in that formula is actually a uin64_t.

Simply defining a const uint64_t and using it ensures the compiler
is aware of the intention. The issue would only manifest if there
were greater than 31 services registered.

Fixes: 21698354c832 ("service: introduce service cores concept")

Signed-off-by: Harry van Haaren <harry.van.haaren@intel.com>
---
 lib/librte_eal/common/rte_service.c | 16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)
  

Hi Harry,

On Mon, Jul 31, 2017 at 04:58:27PM +0100, Harry van Haaren wrote:
> This commit fixes shifts to an integer (1 << shift) which
> is assumed to be a 32-bit integer. In this case, the shift is
> variable and expected to be valid for 64-bit integers. Given that
> the expectation to work with 64 bits exists, we must ensure that
> the (1 << shift) one in that formula is actually a uin64_t.
> 
> Simply defining a const uint64_t and using it ensures the compiler
> is aware of the intention. The issue would only manifest if there
> were greater than 31 services registered.
> 
> Fixes: 21698354c832 ("service: introduce service cores concept")
> 
> Signed-off-by: Harry van Haaren <harry.van.haaren@intel.com>
> ---
>  lib/librte_eal/common/rte_service.c | 16 ++++++++++------
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/lib/librte_eal/common/rte_service.c b/lib/librte_eal/common/rte_service.c
> index e82b9ad..8c1cffa 100644
> --- a/lib/librte_eal/common/rte_service.c
> +++ b/lib/librte_eal/common/rte_service.c
> @@ -285,8 +285,9 @@ rte_service_unregister(struct rte_service_spec *spec)
>  
>  	s->internal_flags &= ~(SERVICE_F_REGISTERED);
>  
> +	const uint64_t one = 1;
>  	for (i = 0; i < RTE_MAX_LCORE; i++)
> -		lcore_states[i].service_mask &= ~(1 << service_id);
> +		lcore_states[i].service_mask &= ~(one << service_id);

Why not use UINT64_C(1)?

>  
>  	memset(&rte_services[service_id], 0,
>  			sizeof(struct rte_service_spec_impl));
> @@ -319,6 +320,7 @@ rte_service_runner_func(void *arg)
>  {
>  	RTE_SET_USED(arg);
>  	uint32_t i;
> +	const uint64_t one = 1;
>  	const int lcore = rte_lcore_id();
>  	struct core_state *cs = &lcore_states[lcore];
>  
> @@ -327,7 +329,7 @@ rte_service_runner_func(void *arg)
>  		for (i = 0; i < rte_service_count; i++) {
>  			struct rte_service_spec_impl *s = &rte_services[i];
>  			if (s->runstate != RUNSTATE_RUNNING ||
> -					!(service_mask & (1 << i)))
> +					!(service_mask & (one << i)))
>  				continue;
>  
>  			/* check do we need cmpset, if MT safe or <= 1 core
> @@ -448,6 +450,7 @@ service_update(struct rte_service_spec *service, uint32_t lcore,
>  {
>  	uint32_t i;
>  	int32_t sid = -1;
> +	const uint64_t one = 1;
>  
>  	for (i = 0; i < RTE_SERVICE_NUM_MAX; i++) {
>  		if ((struct rte_service_spec *)&rte_services[i] == service &&
> @@ -465,16 +468,16 @@ service_update(struct rte_service_spec *service, uint32_t lcore,
>  
>  	if (set) {
>  		if (*set) {
> -			lcore_states[lcore].service_mask |=  (1 << sid);
> +			lcore_states[lcore].service_mask |=  (one << sid);
>  			rte_services[sid].num_mapped_cores++;
>  		} else {
> -			lcore_states[lcore].service_mask &= ~(1 << sid);
> +			lcore_states[lcore].service_mask &= ~(one << sid);
>  			rte_services[sid].num_mapped_cores--;
>  		}
>  	}
>  
>  	if (enabled)
> -		*enabled = (lcore_states[lcore].service_mask & (1 << sid));
> +		*enabled = (lcore_states[lcore].service_mask & (one << sid));
>  
>  	rte_smp_wmb();
>  
> @@ -599,6 +602,7 @@ rte_service_lcore_start(uint32_t lcore)
>  int32_t
>  rte_service_lcore_stop(uint32_t lcore)
>  {
> +	const uint64_t one = 1;
>  	if (lcore >= RTE_MAX_LCORE)
>  		return -EINVAL;
>  
> @@ -607,7 +611,7 @@ rte_service_lcore_stop(uint32_t lcore)
>  
>  	uint32_t i;
>  	for (i = 0; i < RTE_SERVICE_NUM_MAX; i++) {
> -		int32_t enabled = lcore_states[i].service_mask & (1 << i);
> +		int32_t enabled = lcore_states[i].service_mask & (one << i);
>  		int32_t service_running = rte_services[i].runstate !=
>  						RUNSTATE_STOPPED;
>  		int32_t only_core = rte_services[i].num_mapped_cores == 1;
> -- 
> 2.7.4
>
  

> From: Gaëtan Rivet [mailto:gaetan.rivet@6wind.com]
> Sent: Monday, July 31, 2017 5:18 PM
> To: Van Haaren, Harry <harry.van.haaren@intel.com>
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] service: fix shifts to operate on 64 bit integers
> 
> Hi Harry,
> 
> On Mon, Jul 31, 2017 at 04:58:27PM +0100, Harry van Haaren wrote:
> > This commit fixes shifts to an integer (1 << shift) which
> > is assumed to be a 32-bit integer. In this case, the shift is
> > variable and expected to be valid for 64-bit integers. Given that
> > the expectation to work with 64 bits exists, we must ensure that
> > the (1 << shift) one in that formula is actually a uin64_t.
> >
> > Simply defining a const uint64_t and using it ensures the compiler
> > is aware of the intention. The issue would only manifest if there
> > were greater than 31 services registered.
> >
> > Fixes: 21698354c832 ("service: introduce service cores concept")
> >
> > Signed-off-by: Harry van Haaren <harry.van.haaren@intel.com>
> > ---
> >  lib/librte_eal/common/rte_service.c | 16 ++++++++++------
> >  1 file changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/lib/librte_eal/common/rte_service.c b/lib/librte_eal/common/rte_service.c
> > index e82b9ad..8c1cffa 100644
> > --- a/lib/librte_eal/common/rte_service.c
> > +++ b/lib/librte_eal/common/rte_service.c
> > @@ -285,8 +285,9 @@ rte_service_unregister(struct rte_service_spec *spec)
> >
> >  	s->internal_flags &= ~(SERVICE_F_REGISTERED);
> >
> > +	const uint64_t one = 1;
> >  	for (i = 0; i < RTE_MAX_LCORE; i++)
> > -		lcore_states[i].service_mask &= ~(1 << service_id);
> > +		lcore_states[i].service_mask &= ~(one << service_id);
> 
> Why not use UINT64_C(1)?

Mostly because I've never heard of it before :) Thanks for review, still learnin' every day! Sending v2's every other day...