[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=whij5pwOkG5HhMRzrvc4BTzhgj9h=wHo=tMVGasKE+p1w@mail.gmail.com>
Date: Sun, 23 Oct 2022 15:19:24 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Yury Norov <yury.norov@...il.com>
Cc: "Russell King (Oracle)" <linux@...linux.org.uk>,
Catalin Marinas <catalin.marinas@....com>,
Mark Rutland <mark.rutland@....com>,
Will Deacon <will@...nel.org>,
linux-arm-kernel@...ts.infradead.org,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Alexey Klimov <klimov.linux@...il.com>,
Andy Shevchenko <andy.shevchenko@...il.com>,
Andy Whitcroft <apw@...onical.com>,
Dennis Zhou <dennis@...nel.org>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
Guenter Roeck <linux@...ck-us.net>,
Kees Cook <keescook@...omium.org>,
Rasmus Villemoes <linux@...musvillemoes.dk>
Subject: Re: [PATCH 1/2] bitmap: add sanity check function for find_bit()
On Wed, Oct 19, 2022 at 8:24 PM Yury Norov <yury.norov@...il.com> wrote:
>
> This patch adds runtime check for the pointers to be aligned.
No. Don't add pointless things like this. It only adds code, with no advantage.
The bitmap ops all operate on 'unsigned long', and if a bitmap isn't
aligned, we'll take a fault on the architectures that don't do
unaligned accesses natively.
And the find-bit functions simply aren't special enough to have this
kind of random testing, when the *basic* bitmap functions like
"set_bit()" and friends all do the accesses without any alignment
checks.
The fact that filesystem code often uses bitmap functions with a cast
from 'char *' is immaterial. Those things are already aligned
(typically they are a whole disk block). They just weren't an array of
'unsigned long'.
Linus
Powered by blists - more mailing lists