lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <X7fIZrTD6dWB8+xI@shinobu>
Date:   Fri, 20 Nov 2020 08:45:10 -0500
From:   William Breathitt Gray <vilhelm.gray@...il.com>
To:     Arnd Bergmann <arnd@...nel.org>
Cc:     Syed Nayyar Waris <syednwaris@...il.com>,
        Michal Simek <michal.simek@...inx.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        "open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Bartosz Golaszewski <bgolaszewski@...libre.com>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v12 4/4] gpio: xilinx: Utilize generic bitmap_get_value
 and _set_value

On Fri, Nov 20, 2020 at 02:26:35PM +0100, Arnd Bergmann wrote:
> On Fri, Nov 13, 2020 at 5:52 PM Syed Nayyar Waris <syednwaris@...il.com> wrote:
> > On Wed, Nov 11, 2020 at 3:30 AM Syed Nayyar Waris <syednwaris@...il.com> wrote:
> > > On Tue, Nov 10, 2020 at 12:43:16PM -0500, William Breathitt Gray wrote:
> > > > On Tue, Nov 10, 2020 at 10:52:42PM +0530, Syed Nayyar Waris wrote:
> > > > > On Tue, Nov 10, 2020 at 6:05 PM William Breathitt Gray
> > > > > <vilhelm.gray@...il.com> wrote:
> > > > > >
> > > > > > On Tue, Nov 10, 2020 at 11:02:43AM +0100, Michal Simek wrote:
> > > > > > >
> > > > > > >
> > > > > > > On 09. 11. 20 18:31, William Breathitt Gray wrote:
> > > > > > > > On Mon, Nov 09, 2020 at 07:22:20PM +0200, Andy Shevchenko wrote:
> > > > > > > >> On Mon, Nov 09, 2020 at 12:11:40PM -0500, William Breathitt Gray wrote:
> > > > > > > >>> On Mon, Nov 09, 2020 at 10:15:29PM +0530, Syed Nayyar Waris wrote:
> > > > > > > >>>> On Mon, Nov 09, 2020 at 03:41:53PM +0100, Arnd Bergmann wrote:
> > > > > > > >>
> > > > > > > >> ...
> > > > > > > >>
> > > > > > > >>>>  static inline void bitmap_set_value(unsigned long *map,
> > > > > > > >>>> -                                    unsigned long value,
> > > > > > > >>>> +                                    unsigned long value, const size_t length,
> > > > > > > >>>>                                      unsigned long start, unsigned long nbits)
> > > > > > > >>>>  {
> > > > > > > >>>>          const size_t index = BIT_WORD(start);
> > > > > > > >>>> @@ -15,6 +15,10 @@ static inline void bitmap_set_value(unsigned long *map,
> > > > > > > >>>>          } else {
> > > > > > > >>>>                  map[index + 0] &= ~BITMAP_FIRST_WORD_MASK(start);
> > > > > > > >>>>                  map[index + 0] |= value << offset;
> > > > > > > >>>> +
> > > > > > > >>>> +               if (index + 1 >= length)
> > > > > > > >>>> +                       __builtin_unreachable();
> > > > > > > >>>> +
> > > > > > > >>>>                  map[index + 1] &= ~BITMAP_LAST_WORD_MASK(start + nbits);
> > > > > > > >>>>                  map[index + 1] |= value >> space;
> > > > > > > >>>>          }
> > > > > > > >>>
> > > > > > > >>> Hi Syed,
> > > > > > > >>>
> > > > > > > >>> Let's rename 'length' to 'nbits' as Arnd suggested, and rename 'nbits'
> > > > > > > >>> to value_width.
> > > > > > > >>
> > > > > > > >> length here is in longs. I guess this is the point of entire patch.
> > > > > > > >
> > > > > > > > Ah yes, this should become 'const unsigned long nbits' and represent the
> > > > > > > > length of the bitmap in bits and not longs.
> > > > >
> > > > > Hi William, Andy and All,
> > > > >
> > > > > Thank You for reviewing. I was looking into the review comments and I
> > > > > have a question on the above.
> > > > >
> > > > > Actually, in bitmap_set_value(), the intended comparison is to be made
> > > > > between 'index + 1' and 'length' (which is now renamed as 'nbits').
> > > > > That is, the comparison would look-like as follows:
> > > > > if (index + 1 >= nbits)
> > > > >
> > > > > The 'index' is getting populated with BIT_WORD(start).
> > > > > The 'index' variable in above is the actual index of the bitmap array,
> > > > > while in previous mail it is suggested to use 'nbits' which represent
> > > > > the length of the bitmap in bits and not longs.
> > > > >
> > > > > Isn't it comparing two different things? index of array (not the
> > > > > bit-wise-length) on left hand side and nbits (bit-wise-length) on
> > > > > right hand side?
> > > > >
> > > > > Have I misunderstood something? If yes, request to clarify.
> > > > >
> > > > > Or do I have to first divide 'nbits' by BITS_PER_LONG and then compare
> > > > > it with 'index + 1'? Something like this?
> > > > >
> > > > > Regards
> > > > > Syed Nayyar Waris
> > > >
> > > > The array elements of the bitmap memory region are abstracted away for
> > > > the covenience of the users of the bitmap_* functions; the driver
> > > > authors are able to treat their bitmaps as just a set of contiguous bits
> > > > and not worry about where the division between array elements happen.
> > > >
> > > > So to match the interface of the other bitmap_* functions, you should
> > > > take in nbits and figure out the actual array length by dividing by
> > > > BITS_PER_LONG inside bitmap_set_value(). Then you can use your
> > > > conditional check (index + 1 >= length) like you have been doing so far.
> > > >
> > > > William Breathitt Gray
> > >
> > > Hi Arnd,
> > >
> > > Sharing a new version of bitmap_set_value(). Let me know if it looks
> > > good and whether it suppresses the compiler warning.
> > >
> > > The below patch is created against the v12 version of bitmap_set_value().
> > >
> > > -static inline void bitmap_set_value(unsigned long *map,
> > > -                                    unsigned long value,
> > > -                                    unsigned long start, unsigned long nbits)
> > > +static inline void bitmap_set_value(unsigned long *map, unsigned long nbits,
> > > +                                   unsigned long value, unsigned long value_width,
> > > +                                   unsigned long start)
> > >  {
> > > -        const size_t index = BIT_WORD(start);
> > > +        const unsigned long index = BIT_WORD(start);
> > > +        const unsigned long length = BIT_WORD(nbits);
> > >          const unsigned long offset = start % BITS_PER_LONG;
> > >          const unsigned long ceiling = round_up(start + 1, BITS_PER_LONG);
> > >          const unsigned long space = ceiling - start;
> > >
> > > -        value &= GENMASK(nbits - 1, 0);
> > > +        value &= GENMASK(value_width - 1, 0);
> > >
> > > -        if (space >= nbits) {
> > > -                map[index] &= ~(GENMASK(nbits - 1, 0) << offset);
> > > +        if (space >= value_width) {
> > > +                map[index] &= ~(GENMASK(value_width - 1, 0) << offset);
> > >                  map[index] |= value << offset;
> > >          } else {
> > >                  map[index + 0] &= ~BITMAP_FIRST_WORD_MASK(start);
> > >                  map[index + 0] |= value << offset;
> > > -                map[index + 1] &= ~BITMAP_LAST_WORD_MASK(start + nbits);
> > > +
> > > +               if (index + 1 >= length)
> > > +                       __builtin_unreachable();
> > > +
> > > +                map[index + 1] &= ~BITMAP_LAST_WORD_MASK(start + value_width);
> > >                  map[index + 1] |= value >> space;
> > >          }
> > >  }
> > >
> > >
> >
> > Hi Arnd,
> >
> > What do you think of the above solution ( new version of
> > bitmap_set_value() )? Does it look good?
> 
> Sorry for the late reply and thanks for continuing to look at solutions.
> 
> I don't really like the idea of having the __builtin_unreachable() in
> there, since that would lead to even worse undefined behavior
> (jumping to a random instruction) than the previous one (writing
> to a random location) when invalid data gets passed.
> 
> Isn't passing the length of the bitmap sufficient to suppress the
> warning (sorry I did not try myself)? If not, maybe this could
> be a "BUG_ON(index + 1 >= length)" instead of the
> __builtin_unreachable(). That way it would at least crash
> in a well-defined way.
> 
>      Arnd

Hi Arnd,

I don't think we need to worry about incorrect values being passed into
bitmap_set_value(). This condition should never be possible in the code
because the boundaries are required to be correct before the function is
called.

This is the same reason other bitmap_* functions such as bitmap_fill()
don't check the boundaries either: they are expected to be correct
before the function is called; the responsibility is on the caller for
ensuring the boundaries are correct.

Our motivation here is simply to silence the GCC warning messages
because GCC is not aware that the boundaries have already been checked.
As such, we're better off using __builtin_unreachable() here because we
can avoid the latency of the conditional check entirely, whereas
BUG_ON() would still have some amount -- albeit small given the
unlikely() within.

William Breathitt Gray

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ