summaryrefslogtreecommitdiff
path: root/tools/objtool
diff options
context:
space:
mode:
authorJosh Poimboeuf <jpoimboe@redhat.com>2021-01-14 16:32:42 -0600
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2021-02-07 15:37:17 +0100
commit9c8bb3eac07de8834d012e12ff0185a9dcc01331 (patch)
tree47be55776975f9af3bd6127dfc503584405d56ce /tools/objtool
parent4587cb6f27a6f3518aa5195e6a2676ac02dac5aa (diff)
objtool: Don't fail the kernel build on fatal errors
[ Upstream commit 655cf86548a3938538642a6df27dd359e13c86bd ] This is basically a revert of commit 644592d32837 ("objtool: Fail the kernel build on fatal errors"). That change turned out to be more trouble than it's worth. Failing the build is an extreme measure which sometimes gets too much attention and blocks CI build testing. These fatal-type warnings aren't yet as rare as we'd hope, due to the ever-increasing matrix of supported toolchains/plugins and their fast-changing nature as of late. Also, there are more people (and bots) looking for objtool warnings than ever before, so even non-fatal warnings aren't likely to be ignored for long. Suggested-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Miroslav Benes <mbenes@suse.cz> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
Diffstat (limited to 'tools/objtool')
-rw-r--r--tools/objtool/check.c14
1 files changed, 5 insertions, 9 deletions
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index c6ab44543c92..956383d5fa62 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -2921,14 +2921,10 @@ int check(struct objtool_file *file)
warnings += ret;
out:
- if (ret < 0) {
- /*
- * Fatal error. The binary is corrupt or otherwise broken in
- * some way, or objtool itself is broken. Fail the kernel
- * build.
- */
- return ret;
- }
-
+ /*
+ * For now, don't fail the kernel build on fatal warnings. These
+ * errors are still fairly common due to the growing matrix of
+ * supported toolchains and their recent pace of change.
+ */
return 0;
}