Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: 2a98dc028f91 include/linux/bitmap.h: turn bitmap_set and
bitmap_clear into memset when possible.
The bot has also determined it's probably a bug fixing patch. (score: 65.4067)
On Mon, Apr 02, 2018 at 04:49:39PM -0700, Linus Torvalds wrote:
> On Mon, Apr 2, 2018 at 4:37 PM, Linus Torvalds
> wrote:
> >
> > We should probably have at least switched it to "unsigned long int"
>
> I meant just "unsigned int", of course.
>
> Right now we
On Mon, Apr 2, 2018 at 4:37 PM, Linus Torvalds
wrote:
>
> We should probably have at least switched it to "unsigned long int"
I meant just "unsigned int", of course.
Right now we occasionally have a silly 64-bit field just for a couple of flags.
Of course, we do
On Mon, Apr 2, 2018 at 3:58 PM, Omar Sandoval wrote:
>
> Commit 2a98dc028f91 introduced an optimization to bitmap_{set,clear}()
> which uses memset() when the start and length are constants aligned to a
> byte. This is wrong on big-endian systems;
Ugh, yes.
In retrospect, I
On Mon, Apr 02, 2018 at 03:58:31PM -0700, Omar Sandoval wrote:
> From: Omar Sandoval
>
> Commit 2a98dc028f91 introduced an optimization to bitmap_{set,clear}()
> which uses memset() when the start and length are constants aligned to a
> byte. This is wrong on big-endian systems;
From: Omar Sandoval
Commit 2a98dc028f91 introduced an optimization to bitmap_{set,clear}()
which uses memset() when the start and length are constants aligned to a
byte. This is wrong on big-endian systems; our bitmaps are arrays of
unsigned long, so bit n is not at byte n / 8 in