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: <1515590223.7000.853.camel@linux.intel.com>
Date:   Wed, 10 Jan 2018 15:17:03 +0200
From:   Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
To:     Yury Norov <ynorov@...iumnetworks.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 Wed, 2018-01-10 at 11:49 +0300, Yury Norov wrote:
> 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.

Some of them might require 5 minutes to check while others (especially
in the areas I don't know much about) 5+ hours. I rely on Rasmus
assumption that there _were_ bugs, though they assumed to be fixed by
now.

In any case I'm ready to take responsibility of possible breakage and
fully into provide fixes by demand.

>  Sorry that.

I lost your thought here. What did you mean by this?

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

tools is independent, although quite related, project to the kernel
itself. They will decide by themselves how to proceed, I suppose.

At least what I see in the history of changes in the tools/ they usually
follow the changes in main library after while.

Thanks for review!

-- 
Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Intel Finland Oy

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ