From: Thomas Monjalon <thomas@monjalon.net>
To: "Morten Brørup" <mb@smartsharesystems.com>,
"Tyler Retzlaff" <roretzla@linux.microsoft.com>
Cc: 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: Thu, 11 Nov 2021 12:54:47 +0100 [thread overview]
Message-ID: <28219790.PSkamzV0e4@thomas> (raw)
In-Reply-To: <20211111041540.GA31795@linuxonhyperv3.guj3yctzbm1etfxqx2vob5hsef.xx.internal.cloudapp.net>
11/11/2021 05:15, Tyler Retzlaff:
> 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.
It's difficult to be on all topics.
The best way to avoid such miss is to ping when you see no progress.
So what's next?
They are only inline functions, right? so no ABI breakage.
Is it going to require any change on application-side? I guess no.
Is it acceptable in 21.11-rc3? maybe too late?
Is it acceptable in 22.02?
next prev parent reply other threads:[~2021-11-11 11:54 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
2021-11-11 11:54 ` Thomas Monjalon [this message]
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=28219790.PSkamzV0e4@thomas \
--to=thomas@monjalon.net \
--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=roretzla@linux.microsoft.com \
--cc=stephen@networkplumber.org \
/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).