From: Stephen Hemminger <stephen@networkplumber.org>
To: "Morten Brørup" <mb@smartsharesystems.com>
Cc: "Megha Ajmera" <megha.ajmera@intel.com>, <dev@dpdk.org>,
<sham.singh.thakur@intel.com>, <john.mcnamara@intel.com>
Subject: Re: [PATCH] sched: fix integer handling issue
Date: Tue, 22 Feb 2022 08:03:06 -0800 [thread overview]
Message-ID: <20220222080306.1caf1fc9@hermes.local> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D86EDB@smartserver.smartshare.dk>
On Tue, 22 Feb 2022 15:13:53 +0100
Morten Brørup <mb@smartsharesystems.com> wrote:
> > From: Megha Ajmera [mailto:megha.ajmera@intel.com]
> > Sent: Tuesday, 22 February 2022 14.19
> >
> > Masking of core mask was incorrect. Instead of using 1U for shifting,
> > it
> > should be using 1LU as the result is assigned to uint64.
> >
> > CID 375859: Potentially overflowing expression "1U << app_main_core"
> > with
> > type "unsigned int" (32 bits, unsigned) is evaluated using 32-bit
> > arithmetic,
> > and then used in a context that expects an expression of type
> > "uint64_t"
> > (64 bits, unsigned).
> >
> > Coverity issue: 375859
> >
> > Signed-off-by: Megha Ajmera <megha.ajmera@intel.com>
> > ---
> > examples/qos_sched/args.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/examples/qos_sched/args.c b/examples/qos_sched/args.c
> > index 10ca7bea61..44f2f5640e 100644
> > --- a/examples/qos_sched/args.c
> > +++ b/examples/qos_sched/args.c
> > @@ -433,7 +433,7 @@ app_parse_args(int argc, char **argv)
> > return -1;
> > }
> > }
> > - app_used_core_mask |= 1u << app_main_core;
> > + app_used_core_mask |= 1lu << app_main_core;
>
> Still wrong on 32 bit platforms, where long unsigned int is still 32 bits.
>
> Use this instead:
> app_used_core_mask |= RTE_BIT64(app_main_core);
DPDK now supports > 64 lcores. So all code using/assuming a 64 bit mask is broken.
next prev parent reply other threads:[~2022-02-22 16:03 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-22 13:18 [PATCH] sched: fix integer handling issue Megha Ajmera
2022-02-22 14:13 ` Morten Brørup
2022-02-22 16:03 ` Stephen Hemminger [this message]
2022-02-22 18:55 ` Ajmera, Megha
2022-02-23 7:17 ` Morten Brørup
2022-02-23 10:03 ` Ferruh Yigit
2022-02-23 10:42 ` more than 64 lcores not properly supported Morten Brørup
2022-02-23 11:20 ` Ferruh Yigit
2022-02-23 13:49 ` Thomas Monjalon
2022-02-23 15:12 ` Stephen Hemminger
2022-02-23 17:36 ` [PATCH v2] sched: fix integer handling issue Megha Ajmera
2022-02-23 18:13 ` Morten Brørup
2022-02-24 22:51 ` 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=20220222080306.1caf1fc9@hermes.local \
--to=stephen@networkplumber.org \
--cc=dev@dpdk.org \
--cc=john.mcnamara@intel.com \
--cc=mb@smartsharesystems.com \
--cc=megha.ajmera@intel.com \
--cc=sham.singh.thakur@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.