Re: [PATCH] arm: drop arch implementation for find_bit() functions

From: Linus Torvalds
Date: Tue Jul 26 2022 - 14:49:03 EST


On Tue, Jul 26, 2022 at 11:35 AM Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
>
> bitmap unit tests succeed, and the KFENCE report is no longer seen
> even after 65 retries (previously it reproduced easily with 5-15
> retries).
>
> Tested-by: Guenter Roeck <linux@xxxxxxxxxxxx>

Russell, how do you want to handle this?

It's not exactly super-critical, in that this whole issue with the
bitmap overrun probably not happening in real life outside of the
tests. And even when it does happen, it's probably just going to be a
read that nobody cares about (ie very unlikely to hit something like a
"next-page-is-not-mapped" situation).

But it *could* trigger those kinds of things, I guess.

I'll happily take the patch myself as-is, it seems very safe
(considering that all architectures except for 32-bit arm and m68k
already use the generic code).

But as you pointed out, the arm code does the byte-at-a-time thing,
which *could* hide some other arm code using unaligned bitmaps.

Of course, if you actually have unaligned bitmaps (and one of the arm
chips that don't handle unaligned accesses), you'd then probably have
been bitten by just the *regular* bitmap functions doing word accesses
anyway, so I don't really see that as being an issue - I don't expect
anybody would only use the find_bit() functions, and not use the
regular set/clear/test_bit() functions before/after.

Anyway, the patch looks very safe and fixes a known - but likely
*very* minor - issue.

Just let me know how you want to handle this:

(a) I'll take it directly on your say-so

(b) you have other things pending anyway and will apply it and send
me a pull request

(c) you are nervous enough that you prefer leaving this for the next
merge window

I don't personally really see (c) as an issue, but I don't feel
strongly enough about it to really mind one way or another, so
whatever you feel is simplest and works best for you...

Linus