All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrien Mazarguil <adrien.mazarguil@6wind.com>
To: "Burakov, Anatoly" <anatoly.burakov@intel.com>
Cc: dev@dpdk.org
Subject: Re: [PATCH v2 2/2] eal: fix signed integers in fbarray
Date: Fri, 13 Apr 2018 19:54:03 +0200	[thread overview]
Message-ID: <20180413175403.GT4957@6wind.com> (raw)
In-Reply-To: <25801a3b-8c0d-26fb-aa72-40bbd02adbb4@intel.com>

On Fri, Apr 13, 2018 at 05:09:01PM +0100, Burakov, Anatoly wrote:
> On 13-Apr-18 4:56 PM, Adrien Mazarguil wrote:
> > While debugging startup issues encountered with Clang (see "eal: fix
> > undefined behavior in fbarray"), I noticed that fbarray stores indices,
> > sizes and masks on signed integers involved in bitwise operations.
> > 
> > Such operations almost invariably cause undefined behavior with values that
> > cannot be represented by the result type, as is often the case with
> > bit-masks and left-shifts.
> > 
> > This patch replaces them with unsigned integers as a safety measure and
> > promotes a few internal variables to larger types for consistency.
> > 
> > Fixes: c44d09811b40 ("eal: add shared indexed file-backed array")
> > Cc: Anatoly Burakov <anatoly.burakov@intel.com>
> > 
> > Signed-off-by: Adrien Mazarguil <adrien.mazarguil@6wind.com>
> > 
> > --
> > 
> > v2 changes:
> > 
> > Removed unnecessary "(unsigned int)" cast leftovers.
> 
> Thanks for figuring this out! In general, i'm OK with the change, however...
> 
> > ---
> >   lib/librte_eal/common/eal_common_fbarray.c  | 97 ++++++++++++------------
> >   lib/librte_eal/common/include/rte_fbarray.h | 33 ++++----
> >   2 files changed, 68 insertions(+), 62 deletions(-)
> > 
> > diff --git a/lib/librte_eal/common/eal_common_fbarray.c b/lib/librte_eal/common/eal_common_fbarray.c
> > index 11aa3f22a..368290654 100644
> > --- a/lib/librte_eal/common/eal_common_fbarray.c
> > +++ b/lib/librte_eal/common/eal_common_fbarray.c
> > @@ -21,7 +21,7 @@
> >   #include "rte_fbarray.h"
> >   #define MASK_SHIFT 6ULL
> > -#define MASK_ALIGN (1 << MASK_SHIFT)
> > +#define MASK_ALIGN (1ULL << MASK_SHIFT)
> >   #define MASK_LEN_TO_IDX(x) ((x) >> MASK_SHIFT)
> >   #define MASK_LEN_TO_MOD(x) ((x) - RTE_ALIGN_FLOOR(x, MASK_ALIGN))
> >   #define MASK_GET_IDX(idx, mod) ((idx << MASK_SHIFT) + mod)
> > @@ -32,12 +32,12 @@
> >    */
> 
> <...>
> 
> >   int __rte_experimental
> > -rte_fbarray_find_next_free(struct rte_fbarray *arr, int start)
> > +rte_fbarray_find_next_free(struct rte_fbarray *arr, unsigned int start)
> >   {
> 
> This leads to inconsistency here. As it is, we can specify len and start
> value up to UINT32_MAX, but this (and others like it) function will only
> return values up to INT32_MAX.
> 
> One way to fix this would be to prohibit len being >= INT32_MAX on array
> creation. The place to fix this would probably be fully_validate().

Indeed, also I just received a Coverity report about a bunch of other
details due to these changes (now it's obvious that calc_data_size() doesn't
support negative page sizes), I'll update the patch accordingly and submit
v3. Thanks.

> 
> >   	int ret = -1;
> > -	if (arr == NULL || start < 0 || start >= arr->len) {
> > +	if (arr == NULL || start >= arr->len) {
> >   		rte_errno = EINVAL;
> >   		return -1;
> >   	}
> > @@ -683,11 +686,11 @@ rte_fbarray_find_next_free(struct rte_fbarray *arr, int start)
> 
> 
> -- 
> Thanks,
> Anatoly

-- 
Adrien Mazarguil
6WIND

  reply	other threads:[~2018-04-13 17:54 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-13 15:39 [PATCH 1/2] eal: fix undefined behavior in fbarray Adrien Mazarguil
2018-04-13 15:39 ` [PATCH 2/2] eal: fix signed integers " Adrien Mazarguil
2018-04-13 15:56 ` [PATCH v2 1/2] eal: fix undefined behavior " Adrien Mazarguil
2018-04-13 15:56   ` [PATCH v2 2/2] eal: fix signed integers " Adrien Mazarguil
2018-04-13 16:09     ` Burakov, Anatoly
2018-04-13 17:54       ` Adrien Mazarguil [this message]
2018-04-13 16:10   ` [PATCH v2 1/2] eal: fix undefined behavior " Burakov, Anatoly
2018-04-13 18:42   ` [PATCH v3 " Adrien Mazarguil
2018-04-13 18:43     ` [PATCH v3 2/2] eal: fix signed integers " Adrien Mazarguil
2018-04-14 10:03       ` Burakov, Anatoly
2018-04-17 11:14         ` Burakov, Anatoly
2018-04-17 12:39           ` 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=20180413175403.GT4957@6wind.com \
    --to=adrien.mazarguil@6wind.com \
    --cc=anatoly.burakov@intel.com \
    --cc=dev@dpdk.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 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.