From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
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>
Subject: Re: mainline build failure due to 281d0c962752 ("fortify: Add Clang support")
Date: Tue, 28 Jun 2022 15:42:55 -0700 [thread overview]
Message-ID: <20220628224255.w4lmzalkx3qejuyg@treble> (raw)
In-Reply-To: <CAKwvOdnfRnqBF8exO-Y1ooX=67TrO_8fSzgZwvUtidN_P31hzw@mail.gmail.com>
On Thu, Jun 23, 2022 at 04:33:35PM -0700, Nick Desaulniers wrote:
> 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.
FWIW, GCC does the same thing for calls to __noreturn functions. After
the call it just "falls off the face of the earth". So there's nothing
special about Clang here.
> 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/
As discussed with Nick on IRC, the problem highlighted by the
fallthrough warnings seems to be a mismatch in expectations as to
whether __ubsan_handle_divrem_overflow() is noreturn.
When Clang inserts calls to it, it assumes it's noreturn. But in fact
its kernel implementation can actually return, if !panic_on_warn.
So it needs to be changed to *never* return, otherwise hilarity will
ensue when it returns and "falls off the face of the earth".
And then objtool needs to be told that it's in fact noreturn.
So, something like this:
diff --git a/lib/ubsan.c b/lib/ubsan.c
index 36bd75e33426..d257baa62721 100644
--- a/lib/ubsan.c
+++ b/lib/ubsan.c
@@ -177,6 +177,7 @@ void __ubsan_handle_divrem_overflow(void *_data, void *lhs, void *rhs)
pr_err("division by zero\n");
ubsan_epilogue();
+ panic("can't return from __ubsan_handle_divrem_overflow()");
}
EXPORT_SYMBOL(__ubsan_handle_divrem_overflow);
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 864bb9dd3584..6f67d48fb3e4 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -187,6 +187,7 @@ static bool __dead_end_function(struct objtool_file *file, struct symbol *func,
"__invalid_creds",
"cpu_startup_entry",
"__ubsan_handle_builtin_unreachable",
+ "__ubsan_handle_divrem_overflow",
"ex_handler_msr_mce",
};
next prev parent reply other threads:[~2022-06-28 22:43 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-22 10:23 Sudip Mukherjee
2022-06-22 13:47 ` Linus Torvalds
2022-06-22 15:01 ` Nathan Chancellor
2022-06-22 16:21 ` Linus Torvalds
2022-06-22 17:26 ` Sudip Mukherjee
2022-06-22 17:48 ` Linus Torvalds
2022-06-22 22:40 ` Nick Desaulniers
2022-06-23 10:12 ` David Laight
2022-06-23 23:33 ` Nick Desaulniers
2022-06-28 22:42 ` Josh Poimboeuf [this message]
2022-06-29 16:08 ` Linus Torvalds
2022-06-29 16:34 ` Josh Poimboeuf
2022-06-29 21:21 ` Nick Desaulniers
2022-06-29 21:39 ` Linus Torvalds
2022-06-22 18:07 ` Jakub Kicinski
2022-06-22 15:08 ` Sudip Mukherjee
2022-06-22 15:19 ` Linus Torvalds
2022-06-22 16:00 ` Sudip Mukherjee
2022-06-22 16:07 ` Linus Torvalds
2022-06-22 16:16 ` Sudip Mukherjee
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220628224255.w4lmzalkx3qejuyg@treble \
--to=jpoimboe@redhat.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=peterz@infradead.org \
--cc=sudipm.mukherjee@gmail.com \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®