From: Josh Poimboeuf <jpoimboe@redhat.com>
To: Petr Mladek <pmladek@suse.com>
Cc: Miroslav Benes <mbenes@suse.cz>,
Randy Dunlap <rdunlap@infradead.org>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Linux Next Mailing List <linux-next@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
live-patching@vger.kernel.org, Yannick Cote <ycote@redhat.com>
Subject: Re: linux-next: Tree for Jun 23 (objtool (2))
Date: Wed, 15 Jul 2020 11:24:57 -0500 [thread overview]
Message-ID: <20200715162457.mhoz2rgjbl4okx6d@treble> (raw)
In-Reply-To: <20200715134155.GI20226@alley>
On Wed, Jul 15, 2020 at 03:41:55PM +0200, Petr Mladek wrote:
> On Wed 2020-07-15 14:10:54, Petr Mladek wrote:
> > On Wed 2020-07-15 13:11:14, Miroslav Benes wrote:
> > > Petr, would you agree to revert -flive-patching.
> >
> > Yes, I agree.
>
> Or better to say that I will not block it.
>
> I see that it causes maintenance burden. There are questions about
> reliability and performance impact. I do not have a magic solution
> in the pocket.
>
> Anyway, we need a solution to know what functions need to get livepatched.
> I do not have experience with comparing the assembly, so I do not know
> how it is complicated and reliable.
Thanks Petr/Miroslav. I can do the revert patch. It doesn't have to be
a permanent revert. I'd certainly be willing to ACK it again in the
future if/when it becomes more ready.
Yannick has agreed to start looking at the objtool function diff
feature. It's purely theoretical at the moment, we'll see how it works
in practice. We already do something similar in kpatch-build -- it
differs from the objtool model, but it at least shows that something
similar is possible.
--
Josh
next prev parent reply other threads:[~2020-07-15 16:25 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200623162820.3f45feae@canb.auug.org.au>
[not found] ` <61df2e8f-75e8-d233-9c3c-5b4fa2b7fbdc@infradead.org>
[not found] ` <20200702123555.bjioosahrs5vjovu@treble>
2020-07-14 10:56 ` linux-next: Tree for Jun 23 (objtool (2)) Miroslav Benes
2020-07-14 13:57 ` Josh Poimboeuf
2020-07-15 11:11 ` Miroslav Benes
2020-07-15 12:10 ` Petr Mladek
2020-07-15 13:41 ` Petr Mladek
2020-07-15 16:24 ` Josh Poimboeuf [this message]
2020-07-16 11:20 ` Miroslav Benes
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=20200715162457.mhoz2rgjbl4okx6d@treble \
--to=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=live-patching@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=peterz@infradead.org \
--cc=pmladek@suse.com \
--cc=rdunlap@infradead.org \
--cc=sfr@canb.auug.org.au \
--cc=ycote@redhat.com \
/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;
as well as URLs for NNTP newsgroup(s).