From: Tyler Retzlaff <roretzla@linux.microsoft.com>
To: "Morten Brørup" <mb@smartsharesystems.com>
Cc: Thomas Monjalon <thomas@monjalon.net>,
stephen@networkplumber.org, dev@dpdk.org,
anatoly.burakov@intel.com, ranjit.menon@intel.com, mdr@ashroe.eu,
david.marchand@redhat.com, dmitry.kozliuk@gmail.com,
bruce.richardson@intel.com
Subject: Re: [dpdk-dev] [PATCH v2] doc: propose correction rte_{bsf, fls} inline functions type use
Date: Wed, 10 Nov 2021 20:15:40 -0800 [thread overview]
Message-ID: <20211111041540.GA31795@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D86C5E@smartserver.smartshare.dk>
On Tue, Oct 26, 2021 at 09:45:20AM +0200, Morten Brørup wrote:
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas Monjalon
> > Sent: Monday, 25 October 2021 21.14
> >
> > 15/03/2021 20:34, Tyler Retzlaff:
> > > The proposal has resulted from request to review [1] the following
> > > functions where there appeared to be inconsistency in return type
> > > or parameter type selections for the following inline functions.
> > >
> > > rte_bsf32()
> > > rte_bsf32_safe()
> > > rte_bsf64()
> > > rte_bsf64_safe()
> > > rte_fls_u32()
> > > rte_fls_u64()
> > > rte_log2_u32()
> > > rte_log2_u64()
> > >
> > > [1] http://mails.dpdk.org/archives/dev/2021-March/201590.html
> > >
> > > Signed-off-by: Tyler Retzlaff <roretzla@linux.microsoft.com>
> > > ---
> > > --- a/doc/guides/rel_notes/deprecation.rst
> > > +++ b/doc/guides/rel_notes/deprecation.rst
> > > +* eal: Fix inline function return and parameter types for
> > rte_{bsf,fls}
> > > + inline functions to be consistent.
> > > + Change ``rte_bsf32_safe`` parameter ``v`` from ``uint64_t`` to
> > ``uint32_t``.
> > > + Change ``rte_bsf64`` return type to ``uint32_t`` instead of
> > ``int``.
> > > + Change ``rte_fls_u32`` return type to ``uint32_t`` instead of
> > ``int``.
> > > + Change ``rte_fls_u64`` return type to ``uint32_t`` instead of
> > ``int``.
> >
> > It seems we completely forgot this.
> > How critical is it?
>
our organization as a matter of internal security policy requires these
sorts of things to be fixed. while i didn't see any bugs in the dpdk
code there is an opportunity for users of these functions to
accidentally write code that is prone to integer and buffer overflow
class bugs.
there is no urgency, but why leave things sloppy? though i do wish this
had been responded to in a more timely manner 7 months for something
that should have almost been rubber stamped.
> Not updating has near zero effect on bug probability: Incorrectly returning signed int instead of unsigned int is extremely unlikely to cause problems.
>
> Updating has near zero performance improvement: The unnecessary expansion of a parameter value from 32 to 64 bits is cheap.
>
> The update's only tangible benefit is API consistency. :-)
>
> -Morten
next prev parent reply other threads:[~2021-11-11 4:15 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-10 23:24 [dpdk-dev] [PATCH] doc: propose correction rte_bsf64 return type declaration Tyler Retzlaff
2021-03-15 19:34 ` [dpdk-dev] [PATCH v2] doc: propose correction rte_{bsf, fls} inline functions type use Tyler Retzlaff
2021-10-25 19:14 ` Thomas Monjalon
2021-10-26 7:45 ` Morten Brørup
2021-11-11 4:15 ` Tyler Retzlaff [this message]
2021-11-11 11:54 ` Thomas Monjalon
2021-11-11 12:41 ` Morten Brørup
2022-07-11 14:07 ` Jerin Jacob
2022-07-13 10:13 ` Thomas Monjalon
2022-07-18 21:28 ` Tyler Retzlaff
2022-08-08 21:21 ` [PATCH 0/3] cleanup bsf and fls inline function return types Tyler Retzlaff
2022-08-08 21:21 ` [PATCH 1/3] doc: announce cleanup of rte_{bsf, fls} inline functions type use Tyler Retzlaff
2022-10-05 9:06 ` Thomas Monjalon
2022-08-08 21:21 ` [PATCH 2/3] eal: change rte_fls and rte_bsf to return uint32_t Tyler Retzlaff
2022-10-05 9:02 ` Thomas Monjalon
2022-10-05 15:15 ` Tyler Retzlaff
2022-10-05 15:23 ` Thomas Monjalon
2022-10-05 15:40 ` [PATCH] eal: fix return type of bsf safe functions Thomas Monjalon
2022-10-05 19:41 ` David Marchand
2022-10-05 22:20 ` Tyler Retzlaff
2022-10-06 0:27 ` Thomas Monjalon
2022-10-06 18:20 ` Mattias Rönnblom
2022-08-08 21:21 ` [PATCH 3/3] test: fix sign compare warning for rte_bsf64 return type change Tyler Retzlaff
2022-08-08 21:42 ` [PATCH 0/3] cleanup bsf and fls inline function return types Stephen Hemminger
2022-08-09 8:26 ` Morten Brørup
2022-10-05 10:11 ` 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=20211111041540.GA31795@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net \
--to=roretzla@linux.microsoft.com \
--cc=anatoly.burakov@intel.com \
--cc=bruce.richardson@intel.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=dmitry.kozliuk@gmail.com \
--cc=mb@smartsharesystems.com \
--cc=mdr@ashroe.eu \
--cc=ranjit.menon@intel.com \
--cc=stephen@networkplumber.org \
--cc=thomas@monjalon.net \
/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).