[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wivq+i2-xp3WagixzQMBXaD4etMDmiTp5f-mgsfwOjxtA@mail.gmail.com>
Date: Wed, 29 Jun 2022 09:08:20 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Josh Poimboeuf <jpoimboe@...hat.com>
Cc: Nick Desaulniers <ndesaulniers@...gle.com>,
Sudip Mukherjee <sudipm.mukherjee@...il.com>,
Nathan Chancellor <nathan@...nel.org>,
Kees Cook <keescook@...omium.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
clang-built-linux <llvm@...ts.linux.dev>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: mainline build failure due to 281d0c962752 ("fortify: Add Clang support")
On Tue, Jun 28, 2022 at 3:43 PM Josh Poimboeuf <jpoimboe@...hat.com> wrote:
>
> So, something like this:
No, clang should just be fixed.
These UBSAN reports should usually be WARN_ON_ONCE.
It's all the same issues we've had before: causing a panic will just
kill the machine, and gets us fewer reports.
Now, UBSAN is something that presumably normal people don't actually
run on real hardware, so it's probably less of a deal than some. But
hey, maybe somebody wants to actually run an UBSAN kernel on a real
load with a full accelerated graphical UI and real drivers: a panic
may end up killing the kernel, and there you sit, with a dead machine
and no idea what went wrong.
So the whole "panic if UBSAN reports something" is COMPLETE GARBAGE.
It actually makes the whole point of running UBSAN go away. You *lose*
coverage.
So please don't make the kernel worse because clang got something like
this wrong.
Just fix clang.
And fix your mindset.
Linus
Powered by blists - more mailing lists