public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Yury Norov <ynorov@caviumnetworks.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	Rasmus Villemoes <linux@rasmusvillemoes.dk>,
	Randy Dunlap <rdunlap@infradead.org>
Subject: Re: [PATCH v1 4/4] bitmap: Make bitmap_fill() and bitmap_zero() consistent
Date: Wed, 10 Jan 2018 15:17:03 +0200	[thread overview]
Message-ID: <1515590223.7000.853.camel@linux.intel.com> (raw)
In-Reply-To: <20180110084938.ggb3x4pq5suprnne@yury-thinkpad>

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@linux.intel.com>
Intel Finland Oy

  reply	other threads:[~2018-01-10 13:21 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-09 17:24 [PATCH v1 1/4] bitmap: Add bitmap_zero()/bitmap_clear() test cases Andy Shevchenko
2018-01-09 17:24 ` [PATCH v1 2/4] bitmap: Add bitmap_fill()/bitmap_set() " Andy Shevchenko
2018-01-09 17:24 ` [PATCH v1 3/4] bitmap: Clean up test_zero_fill_copy() test case and rename Andy Shevchenko
2018-01-09 17:24 ` [PATCH v1 4/4] bitmap: Make bitmap_fill() and bitmap_zero() consistent Andy Shevchenko
2018-01-10  8:49   ` Yury Norov
2018-01-10 13:17     ` Andy Shevchenko [this message]
2018-01-11 11:57       ` Yury Norov
2018-01-11 12:46         ` Andy Shevchenko
2018-01-10  9:34 ` [PATCH v1 1/4] bitmap: Add bitmap_zero()/bitmap_clear() test cases Yury Norov
2018-01-10 13:11   ` Andy Shevchenko
2018-01-11 12:07     ` Yury Norov
2018-01-11 12:32       ` Andy Shevchenko

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=1515590223.7000.853.camel@linux.intel.com \
    --to=andriy.shevchenko@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@rasmusvillemoes.dk \
    --cc=rdunlap@infradead.org \
    --cc=ynorov@caviumnetworks.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox