linux-kernel - Re: [PATCH v1 4/4] bitmap: Make bitmap_fill() and bitmap

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180110084938.ggb3x4pq5suprnne@yury-thinkpad>
Date:   Wed, 10 Jan 2018 11:49:38 +0300
From:   Yury Norov <ynorov@...iumnetworks.com>
To:     Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        linux-kernel@...r.kernel.org,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Randy Dunlap <rdunlap@...radead.org>
Subject: Re: [PATCH v1 4/4] bitmap: Make bitmap_fill() and bitmap_zero()
 consistent

On Tue, Jan 09, 2018 at 07:24:30PM +0200, Andy Shevchenko wrote:
> Behaviour of bitmap_fill() differs from bitmap_zero() in a way
> how bits behind bitmap are handed. bitmap_zero() clears entire bitmap
> by unsigned long boundary, while bitmap_fill() mimics bitmap_set().
> 
> Here we change bitmap_fill() behaviour to be consistent with bitmap_zero()
> and add a note to documentation.
> 
> The change might reveal some bugs in the code where unused bits handled
> differently and in such cases bitmap_set() has to be used.

There is only 51 users of bitmap_fill() in the kernel, including
tests. If you propose this change, I think you'd check them all
manually. Sorry that.

Also, there's tools/include/linux/bitmap.h which has a copy of
bitmap_fill(), and should be consistent with main kernel sources.

> Suggested-by: Rasmus Villemoes <linux@...musvillemoes.dk>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
> ---
>  include/linux/bitmap.h | 15 ++++++++++-----
>  1 file changed, 10 insertions(+), 5 deletions(-)
> 
> diff --git a/include/linux/bitmap.h b/include/linux/bitmap.h
> index a17b5121d4f5..49aea0b37994 100644
> --- a/include/linux/bitmap.h
> +++ b/include/linux/bitmap.h
> @@ -67,6 +67,11 @@
>   *  bitmap_from_arr32(dst, buf, nbits)          Copy nbits from u32[] buf to dst
>   *  bitmap_to_arr32(buf, src, nbits)            Copy nbits from buf to u32[] dst
>   *
> + * Note, bitmap_zero() and bitmap_fill() operate over the region of
> + * unsigned longs, that is, bits behind bitmap till the unsigned long
> + * boundary will be zeroed or filled as well. Consider to use
> + * bitmap_clear() or bitmap_set() to make explicit zeroing or filling
> + * respectively.
>   */
>  
>  /**
> @@ -206,12 +211,12 @@ static inline void bitmap_zero(unsigned long *dst, unsigned int nbits)
>  
>  static inline void bitmap_fill(unsigned long *dst, unsigned int nbits)
>  {
> -	unsigned int nlongs = BITS_TO_LONGS(nbits);
> -	if (!small_const_nbits(nbits)) {
> -		unsigned int len = (nlongs - 1) * sizeof(unsigned long);
> -		memset(dst, 0xff,  len);
> +	if (small_const_nbits(nbits))
> +		*dst = ~0UL;
> +	else {
> +		unsigned int len = BITS_TO_LONGS(nbits) * sizeof(unsigned long);
> +		memset(dst, 0xff, len);
>  	}
> -	dst[nlongs - 1] = BITMAP_LAST_WORD_MASK(nbits);
>  }
>  
>  static inline void bitmap_copy(unsigned long *dst, const unsigned long *src,
> -- 
> 2.15.1