All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.