Messages in this thread | | | Date | Tue, 3 May 2022 12:56:13 +0300 | From | Andy Shevchenko <> | Subject | Re: [PATCH 2/5] lib: add bitmap_{from,to}_arr64 |
| |
On Mon, May 02, 2022 at 01:06:56PM -0700, Yury Norov wrote: > On Fri, Apr 29, 2022 at 08:45:35AM -0700, Yury Norov wrote: > > On Fri, Apr 29, 2022 at 03:59:25PM +0300, Andy Shevchenko wrote: > > > On Thu, Apr 28, 2022 at 01:51:13PM -0700, Yury Norov wrote:
...
> > > > +void bitmap_to_arr64(u64 *buf, const unsigned long *bitmap, unsigned int nbits) > > > > +{ > > > > + const unsigned long *end = bitmap + BITS_TO_LONGS(nbits); > > > > + > > > > + while (bitmap < end) { > > > > + *buf = *bitmap++; > > > > + if (bitmap < end) > > > > + *buf |= (u64)(*bitmap++) << 32; > > > > + buf++; > > > > + } > > > > > > > > + /* Clear tail bits in last element of array beyond nbits. */
in the last
> > > > + if (nbits % 64) > > > > + buf[-1] &= GENMASK_ULL(nbits, 0); > > > > > > Hmm... if nbits is > 0 and < 64, wouldn't be this problematic, since > > > end == bitmap? Or did I miss something? > > > > BITS_TO_LONGS(0) == 0 > > BITS_TO_LONGS(1..32) == 1 > > BITS_TO_LONGS(33..64) == 2 > > > > The only potential problem with buf[-1] is nbits == 0, but fortunately > > (0 % 64) == 0, and it doesn't happen.
I see, perhaps adding a small comment would be nice to have to explain that -1 index is safe.
> Are there any other concerns? If no, I'll fix formatting and append it to > bitmap-for-next.
Nope.
-- With Best Regards, Andy Shevchenko
| |