Messages in this thread | | | From | Linus Torvalds <> | Date | Mon, 25 Jul 2022 11:49:09 -0700 | Subject | Re: Linux 5.19-rc8 |
| |
On Mon, Jul 25, 2022 at 10:55 AM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > I think the fix might be something like this:
Hmm. Maybe the fix is to just not have the arm architecture-specific version at all.
The generic code handles the "small constant size bitmap that fits in a word" case better than the ARM special case code does.
And the generic code handles the "scan large bitmap" case better than the ARM code does too, in that it does things a word at a time, while the ARM special case code does things one byte at a time.
The ARM code does have a few things going for it:
(a) it's simple
(b) it has separate routines for the little-endian case
Now, (a) is probably not too strong an argument, because it's arguably *too* simple, and buggy as a result. And having looked a bit more, it's not just _find_next_bit_le() that has this bug, it's all the "next" versions (zero-bit and big-endian).
But (b) is actively better than what the generic "find bit" code has. The generic code is kind of disgusting in this area, with code like
if (le) tmp = swab(tmp);
in lib/find_bit.c and this is nasty for two reasons:
(1) on little-endian, the "le" flag is mis-named: it's always zero, and it never should swab, but the code was taken from some big-endian generic case
(2) even on big-endian, that "le" flag is basically a compile-time constant, but the header file shenanigans have hidden that fact, so it ends up being a "pass a constant to a function that then has to test it dynamically" situation
So the generic code is in many ways better than the ARM special case code, but it has a couple of unfortunate warts too. At least those unfortunate warts aren't outright *bugs*, they are just ugly.
Linus
| |