[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20200715162457.mhoz2rgjbl4okx6d@treble>
Date: Wed, 15 Jul 2020 11:24:57 -0500
From: Josh Poimboeuf <jpoimboe@...hat.com>
To: Petr Mladek <pmladek@...e.com>
Cc: Miroslav Benes <mbenes@...e.cz>,
Randy Dunlap <rdunlap@...radead.org>,
Stephen Rothwell <sfr@...b.auug.org.au>,
Linux Next Mailing List <linux-next@...r.kernel.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Peter Zijlstra <peterz@...radead.org>,
live-patching@...r.kernel.org, Yannick Cote <ycote@...hat.com>
Subject: Re: linux-next: Tree for Jun 23 (objtool (2))
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
Powered by blists - more mailing lists