From: Miroslav Benes <mbenes@suse.cz>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: live-patching@vger.kernel.org, linux-kernel@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Randy Dunlap <rdunlap@infradead.org>
Subject: Re: [PATCH] Revert "kbuild: use -flive-patching when CONFIG_LIVEPATCH is enabled"
Date: Tue, 21 Jul 2020 13:17:00 +0200 (CEST) [thread overview]
Message-ID: <alpine.LSU.2.21.2007211316410.31851@pobox.suse.cz> (raw)
In-Reply-To: <696262e997359666afa053fe7d1a9fb2bb373964.1595010490.git.jpoimboe@redhat.com>
On Fri, 17 Jul 2020, Josh Poimboeuf wrote:
> 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>
M
next prev parent reply other threads:[~2020-07-21 11:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-17 18:29 [PATCH] Revert "kbuild: use -flive-patching when CONFIG_LIVEPATCH is enabled" Josh Poimboeuf
2020-07-20 3:35 ` Joe Lawrence
2020-07-20 8:50 ` Kamalesh Babulal
2020-07-20 11:47 ` Joe Lawrence
2020-07-21 11:27 ` Miroslav Benes
2020-07-21 11:17 ` Miroslav Benes [this message]
2020-08-06 9:24 ` Petr Mladek
2020-09-01 17:24 ` Josh Poimboeuf
2020-09-03 10:02 ` Petr Mladek
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=alpine.LSU.2.21.2007211316410.31851@pobox.suse.cz \
--to=mbenes@suse.cz \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=rdunlap@infradead.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