Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <YrLtpixBqWDmZT/V@debian> <CAHk-=wiN1ujyVTgyt1GuZiyWAPfpLwwg-FY1V-J56saMyiA1Lg@mail.gmail.com>
 <YrMu5bdhkPzkxv/X@dev-arch.thelio-3990X> <CAHk-=wjTS9OJzggD8=tqtj0DoRCKhjjhpYWoB=bPQAv3QMa+eA@mail.gmail.com>
 <YrNQrPNF/XfriP99@debian> <CAHk-=wjje8UdsQ_mjGVF4Bc_TcjAWRgOps7E_Cytg4xTbXfyig@mail.gmail.com>
 <CAKwvOdmQKo4tZRLWxK2tTvd+OEtUmKJM7XiijLAF8JWMeUzFMA@mail.gmail.com>
In-Reply-To: <CAKwvOdmQKo4tZRLWxK2tTvd+OEtUmKJM7XiijLAF8JWMeUzFMA@mail.gmail.com>
From:   Nick Desaulniers <ndesaulniers@google.com>
Date:   Thu, 23 Jun 2022 16:33:35 -0700
Message-ID: <CAKwvOdnfRnqBF8exO-Y1ooX=67TrO_8fSzgZwvUtidN_P31hzw@mail.gmail.com>
Subject: Re: mainline build failure due to 281d0c962752 ("fortify: Add Clang support")
To:     Linus Torvalds <torvalds@linux-foundation.org>,
        Josh Poimboeuf <jpoimboe@redhat.com>
Cc:     Sudip Mukherjee <sudipm.mukherjee@gmail.com>,
        Nathan Chancellor <nathan@kernel.org>,
        Kees Cook <keescook@chromium.org>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        clang-built-linux <llvm@lists.linux.dev>,
        Peter Zijlstra <peterz@infradead.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Wed, Jun 22, 2022 at 3:40 PM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> On Wed, Jun 22, 2022 at 10:49 AM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > On Wed, Jun 22, 2022 at 12:26 PM Sudip Mukherjee
> > <sudipm.mukherjee@gmail.com> wrote:
> > >
> > > Tried it after applying your patch. There was no build failure, but some warnings:
> >
> > So some of those objtool warnings are, I think, because clang does odd
> > and crazy things for when it decides "this is not reachable" code.
> >
> > I don't much like it, and neither does objtool, but it is what it is.
> > When clang decides "I'm calling a function that cannot return", it
> > will have a "call" instruction and then it will just fall off the face
> > of the earth after that.
> >
> > That includes falling through to the next function, or just to random
> > other labels after the function, and then objtool as a result
> > complains about a stack state mismatch (when the fallthrough is the
> > same function, but now the stack pointer is different in different
> > parts), or of the "falls through to next function".
> >
> > I think it's a clang misfeature in that if something goes wrong, you
> > basically execute random code. I'd much rather see clang insert a real
> > 'ud' instruction or 'int3' or whatever. But it doesn't.
>
> So adding `-mllvm -trap-unreachable` will turn these
> `__builtin_unreachable()`'s into trapping instructions.  I think we
> should just do that/enable that in the kernel.  The following patch
> eliminates ALL of the fallthrough warnings observed from objtool on
> x86_64 defconfig builds.
>
> ```
> diff --git a/scripts/Makefile.clang b/scripts/Makefile.clang
> index 87285b76adb2..1fbf8a8f3751 100644
> --- a/scripts/Makefile.clang
> +++ b/scripts/Makefile.clang
> @@ -36,6 +36,7 @@ endif
>  # so they can be implemented or wrapped in cc-option.
>  CLANG_FLAGS    += -Werror=unknown-warning-option
>  CLANG_FLAGS    += -Werror=ignored-optimization-argument
> +CLANG_FLAGS    += -mllvm -trap-unreachable
>  KBUILD_CFLAGS  += $(CLANG_FLAGS)
>  KBUILD_AFLAGS  += $(CLANG_FLAGS)
>  export CLANG_FLAGS
> ```
>
> There's more I need to do for LTO; `-mllvm` flags need to be passed to
> the linker in that case.  Let me do a few more builds, collect
> statistics on build size differences (guessing neglidgeable), then
> will send out a more formal patch.

Looks like these are actually from calls to
__ubsan_handle_divrem_overflow which is __noreturn when panic_on_warn
is set by the corresponding config.  I wonder if we should be
unconditionally adding __ubsan_handle_divrem_overflow to the allow
list `global_noreturns` in tools/objtool/check.c?  It seems like the
kconfig defines aren't passed through to the tools/ sources.

List of fallthrough warnings from allmodconfig for reference:
https://lore.kernel.org/lkml/YrNQrPNF%2FXfriP99@debian/

--
Thanks,
~Nick Desaulniers