[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHk-=wgLBjQZ1Xic9SDvtPOu3MNwRznZygZ35mqq4CpKmWdBtA@mail.gmail.com>
Date: Fri, 17 Mar 2023 14:00:09 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: Kees Cook <keescook@...omium.org>,
Nick Desaulniers <ndesaulniers@...gle.com>,
Jens Axboe <axboe@...nel.dk>,
Nathan Chancellor <nathan@...nel.org>,
"linux-block@...r.kernel.org" <linux-block@...r.kernel.org>,
clang-built-linux <llvm@...ts.linux.dev>,
linux-hardening@...r.kernel.org
Subject: Re: [GIT PULL] Block fixes for 6.3-rc3
On Fri, Mar 17, 2023 at 1:51 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> but I would *really* like clang to be fixed to not silently generate
> code that does insane things and would be basically impossible to
> debug if it ever triggers.
Side note: the key word here is "silently".
If clang notices that it generates crazy code, a warning at build-time
would be preferable to the "oh, we noticed the crazy code generation
because we do sanity checking that just happened to catch it".
If that "fall-through due to impossible third iteration" had happened
*inside* the function, rather than at the end, we'd have never
noticed.
So we were kind of lucky in just where things triggered this time.
Maybe that's always going to be true due to some random internal clang
logic ("dead code fallthrough is always at the end because of how we
sort basic blocks"), but I don't see why it would be in general.
Linus
Powered by blists - more mailing lists