lkml.org 
[lkml]   [2020]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
Subject[PATCH 5.8 035/177] Revert "kbuild: use -flive-patching when CONFIG_LIVEPATCH is enabled"
Date
From: Josh Poimboeuf <jpoimboe@redhat.com>

[ Upstream commit 318af7b80b6a6751520cf2b71edb8c45abb9d9d8 ]

Use of the new -flive-patching flag was introduced with the following
commit:

43bd3a95c98e ("kbuild: use -flive-patching when CONFIG_LIVEPATCH is enabled")

This flag has several drawbacks:

- It disables some optimizations, so it can have a negative effect on
performance.

- According to the GCC documentation it's not compatible with LTO, which
will become a compatibility issue as LTO support gets upstreamed in
the kernel.

- It was intended to be used for source-based patch generation tooling,
as opposed to binary-based patch generation tooling (e.g.,
kpatch-build). It probably should have at least been behind a
separate config option so as not to negatively affect other livepatch
users.

- Clang doesn't have the flag, so as far as I can tell, this method of
generating patches is incompatible with Clang, which like LTO is
becoming more mainstream.

- It breaks GCC's implicit noreturn detection for local functions. This
is the cause of several "unreachable instruction" objtool warnings.

- The broken noreturn detection is an obvious GCC regression, but we
haven't yet gotten GCC developers to acknowledge that, which doesn't
inspire confidence in their willingness to keep the feature working as
optimizations are added or changed going forward.

- While there *is* a distro which relies on this flag for their distro
livepatch module builds, there's not a publicly documented way to
create safe livepatch modules with it. Its use seems to be based on
tribal knowledge. It serves no benefit to those who don't know how to
use it.

(In fact, I believe the current livepatch documentation and samples
are misleading and dangerous, and should be corrected. Or at least
amended with a disclaimer. But I don't feel qualified to make such
changes.)

Also, we have an idea for using objtool to detect function changes,
which could potentially obsolete the need for this flag anyway.

At this point the flag has no benefits for upstream which would
counteract the above drawbacks. Revert it until it becomes more ready.

This reverts commit 43bd3a95c98e1a86b8b55d97f745c224ecff02b9.

Fixes: 43bd3a95c98e ("kbuild: use -flive-patching when CONFIG_LIVEPATCH is enabled")
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Acked-by: Miroslav Benes <mbenes@suse.cz>
Signed-off-by: Petr Mladek <pmladek@suse.com>
Link: https://lore.kernel.org/r/696262e997359666afa053fe7d1a9fb2bb373964.1595010490.git.jpoimboe@redhat.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
Makefile | 4 ----
1 file changed, 4 deletions(-)

diff --git a/Makefile b/Makefile
index 36eab48d1d4a6..3299cc45c1dd0 100644
--- a/Makefile
+++ b/Makefile
@@ -876,10 +876,6 @@ KBUILD_CFLAGS_KERNEL += -ffunction-sections -fdata-sections
LDFLAGS_vmlinux += --gc-sections
endif

-ifdef CONFIG_LIVEPATCH
-KBUILD_CFLAGS += $(call cc-option, -flive-patching=inline-clone)
-endif
-
ifdef CONFIG_SHADOW_CALL_STACK
CC_FLAGS_SCS := -fsanitize=shadow-call-stack
KBUILD_CFLAGS += $(CC_FLAGS_SCS)
--
2.25.1


\
 
 \ /
  Last update: 2020-09-16 01:44    [W:0.571 / U:5.408 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site